Hacker News Reader

Comment by johnfn | Hacker News Reader

As soon as Blow and others start pontificating about how modern software is terrible, I get frustrated; my viewpoint differs with theirs so drastically that I don't even know where to begin.

I might start somewhere around here: I think the fact that modern software is "terrible" is actually a sign of the dramatic success, not failure, of programming.

The reasons that Blow et all normally cite as why software is terrible are usually that, 20 and 30 years ago, engineers were able to pull off superhuman feats compared to the engineers of today. I accept this unquestionably. They wrote software that ran quicker and was more space-efficient than modern software. But running software that fit in kilobytes of RAM was never the goal of software engineering. The goal was providing value to your users.

Blow et. al. seem to think that efficient software is the goal. I couldn't disagree more. The goal is always to produce things that users can actually use. And if that means doing hideously inefficient things, like running your app inside a chrome shell, so be it, if that means you delivered value faster.

And the amount of engineering effort per unit of value created has gone down so much today compared to 30 years ago.

In the past, engineers could squander days or weeks trying to make code more memory efficient, or finding the exact right sequence of ASM instructions to waste less CPU cycles. These are issues I don't even have to think about. Heck, I can do extremely stupid and inefficient things, like use a garbage collector, or electron, and for the most part, users don't even care[1]. What an incredible success!

Essentially, I think what Blow is seeing when he cites the demise of modern software engineering is in fact that the bar to writing usable software has dropped immensely. I can understand why this is a frustrating thing for him, because it effectively means that his skillset is not as valuable as it used to be. But I just can't agree at all. How amazing that we can be so wasteful and yet still produce such great software, and furthermore what an incredible success that engineers like me don't need to even think about ASM and RAM efficiency.

[1] Yes, some users do care, and I think that a disproportionate majority of them hang out on Hacker News. :P

View on HN

I too find his presentation pretentious and his claims suspect. He has released two games in his career so far and an as-yet-to-be-released compiler that he’s been toying with for years: and he calls modern software developers unproductive!

However I think efficiency still matters depending on the use case and to his credit I don’t think he says that everyone has to care about efficiency.

I think the point he makes is that we might be losing the ability to produce efficient code because we’re not teaching these techniques. And that is perhaps why we buy $3000 Facebook browsing machines that don’t feel any faster than computers 20 years ago. Often they are slower.

If we only teach folks how to script Unity and Unreal how are we supposed to get the next generation of engine developers to build the foundations of the technology?

Well, I wouldn't go that far. Blow is a smart guy, and games are hard to make. Two mainstream successes are more than I have. :P

> If we only teach folks how to script Unity and Unreal how are we supposed to get the next generation of engine developers to build the foundations of the technology?

Why can't we have both? Lowering the bar to allow less-experienced engineers to create things doesn't mean that we've prevented engineers with more experience from continuing to exist and thrive. We've just created a richer stratification of skill levels than previously existed.

Fair, I was being a bit harsh with his credentials. He’s also freely streaming and posting how bad modern software is.

And again I don’t think he said, in the talk mentioned in tfa, that we can’t have both. His primary concern seems to be that the scales have tipped too far one way.

I think there is some merit to that. Go to any game dev forum and ask about programming and 9 times out of 10 you will be guided towards using a game engine. The common wisdom is: don’t learn to program, just make the game.

And that is 100% fine advice and Blow admits that in the talk.

But knowledge transfer is the key here and if we’re not making enough space in the education of future programmers for that lower level part of the stack then maybe one day we (as in society) could forget how.

I still think that’s highly unlikely to be happening today but it’s an interesting thing to think about.

I find myself often frustrated by how much gobs of memory, fast drives, and cores we throw into modern machines and yet my browser can still stutter while scrolling a page.

I'm not really so worried about this knowledge transfer thing. I think programming knowledge is being transferred just fine. It's hard to see it, though, because there are several orders of magnitude more programmers now than there were 20 years ago. You don't need a constant X% of programmers to know how to build a game engine. You just need a couple hundred of them, or so, and as long as that knowledge is passed to a couple hundred of the next generation of programmers, that's fine. And if only a couple hundred -- or even a thousand -- programmers know how to build a game engine, it's easy to see how it might feel hard to find those people among the millions of programmers out there. But they're there, and they're mostly probably doing useful work and are propagating their knowledge appropriately.

I also think that many many many more people know how to write efficient programs than Blow or other doomsayers might fear. It's just that most of us have better things to do than micro-optimize or write our own engines or toolkits or whatever for everything, and the state of modern computing means that we don't have to bother -- even while many of us decry the inefficiency of things like Electron, or in attempting to write a high-scale distributed system in Python or Ruby. And I agree with you that it's dumb that we can throw an 8-core 4GHz CPU and 32GB of RAM at a web browser, and it can still stutter while scrolling down a page. We clearly haven't always found the best balance here. But that doesn't mean we've lost the ability to do so.

I think plenty of people have all this tribal programming knowledge, and they're doing just fine passing it along to the next generation of programmers. It's just that most people don't need to actually make use of that knowledge in their day-to-day work. Yes, I do believe that lack of use causes some atrophy, but I don't think that's the big problem that some would make it out to be.

> I think the point he makes is that we might be losing the ability to produce efficient code because we’re not teaching these techniques.

Is this true though? It honestly seems to me that it's more like we teach a lot more people to do those techniques than will ever need to use them, and that this results in a lot of frustration and / or time spent prematurely optimizing.

I don’t know if there’s ever been a comprehensive survey on the subject. But it does seem like a rare skill some times. And it’s not like we’re lacking examples of bloated, slow, and error prone software these days.

Is it getting worse? I don’t know. My impression has been that it’s a marvel it works so well when it sometimes seems like the whole enterprise is too complicated to work at all.

But maybe we have simply been conditioned to not want better. Errors are fine, leaking memory happens, security vulnerabilities are inevitable. What can you do?

Is it worse than it was 20 years ago? I don’t know. I’m not much younger than Blow and grew up programming on an Amiga. I do enjoy fond memories of programming a machine that I had a manual for and knew well. It is very different today… but also much easier and more inclusive of folks with different skill levels.

I don't know if we should necessarily use slow/buggy software as examples. IMO it's very conceivable that it's written by devs who know better, but they're not optimizing for those metrics. I've certainly been in situations where I've thought "well, I can reduce latency here by 100ms, but is that worth delaying the project by 2 days?"

I think we'd have to define "efficient code." Like, not doing something big-O stupid? That's covered in computer science classes and as a science it is pretty human-understandable and timeless. Micro-optimizations? Perhaps between optimizing compilers and massive reorder buffers/massive caches/clever branch predictors, there's not as much need for that sort of thing.

College programs teach both things. Then you go into the working world and it's just not what most people spend much of their time doing, not because of some oversight or deterioration in society or something, but simply because there are more important things to do. And this frustrates a lot of people (especially young people) who loved that part of school and maybe even got into the whole thing because they loved this part of it. Then sometimes those frustrated people (or in order to avoid becoming frustrated), people spend a lot of time on it, even though it's really not the most important thing to work on. And that's fine and all, there are definitely worse things to spend time on, but it also makes sense that a lot of other people spend all their time on the higher priority things.

> I think the point he makes is that we might be losing the ability to produce efficient code because we’re not teaching these techniques. And that is perhaps why we buy $3000 Facebook browsing machines that don’t feel any faster than computers 20 years ago. Often they are slower.

I think you are just paraphrasing his point, so don't take this as a shot in your direction, but anybody who remembers computers 20 years ago being faster either has some serious rose tinted glasses, or was not using computers 20 years ago. They were incredibly buggy and slow. Basic users crashed their Windows boxes often enough that "blue screen of death" was a common phrase (which is to say, we're advanced users here -- we can even get Linux to crash -- but normal computers are pretty good nowadays if you just use them like a normal person).

If they felt faster, that's because we were using a text editors rather than office suites, because we didn't want to wait minutes for an office suite to start up (and then crash). You can still use a text editor and vim at least is still pretty snappy.

Like surely we can all remember the first solid state drives we installed, right? The feeling of not waiting for programs to load was remarkable. Now we're just used to having programs start instantly.

Things are actually quite good, we're just used to it.

I mean, the internet is kind of a mixed bag. Javascript is annoying and everywhere. But on the other hand, remember when Java applets were a thing?

There came the trend of leaving your computer on instead of powering it off just because starting up was so slow.

So much has improved that Blow’s arguments about how much better computers used to be has an air of Old Man Yelling at Clouds to me.

Booting into Workbench off a floppy is fun and all but my current machine boots up so fast now it’s ridiculous.

> I think you are just paraphrasing his point, so don't take this as a shot in your direction, but anybody who remembers computers 20 years ago being faster either has some serious rose tinted glasses, or was not using computers 20 years ago... You can still use a text editor and vim at least is still pretty snappy.

This is a single analysis from a single person, but if you look at empiric data for latency in terminal text input, there is a pretty significant negative trend over time: https://danluu.com/input-lag/

See https://news.ycombinator.com/item?id=32616485

That article is talking about a very narrow aspect of latency, things like "if I press a letter on my keyboard, how quickly does it show up on my screen?" And most computer users care much more about throughput than latency, within reason, anyway.

But 20 years ago, starting applications was slow, because spinning-rust hard drives were slow, CPUs were slow, and we didn't have as much RAM. Yes, applications executed fewer instructions to start up, and used less RAM back then, but today I type on a 13" laptop with 64GB of RAM, so much that my OS doesn't know what to do with most of it, to the point where the OS filesystem buffer cache is "only" using up 12GB, and 44GB is just sitting completely unused for anything. Yes, maybe it's absurd that running a desktop environment with a browser (granted, with over a thousand tabs open), some terminal emulator instances, and the one annoying Electron app I can't get rid of, consumes 8GB of RAM, which alone is three orders of magnitude more RAM than I had 20 years ago.

But the bottom line is that I, as a user, just don't need to care about resource utilization. I don't need to close my word processor when I want to play a game or watch a video. Oh, speaking of that -- in 2000, my CPU didn't have the ability to decode DVD-quality MPEG2 video in real time! If I tried, CPU usage would be pegged at 100%, and the video would still stutter and be unwatchable. (I'm not saying that there weren't CPUs in 2000 that could do this, just that mine could not, and I couldn't afford one that could.) Today I can stream 4k video from some storage location tens or hundreds of miles away, and decode it (on GPU or CPU) and play it back on a machine that sits on my lap (the aforementioned 2000-era CPU of course lived in a big tower case).

"Computers were faster 20 years ago" -- yeah, right.

> but anybody who remembers computers 20 years ago being faster either has some serious rose tinted glasses, or was not using computers 20 years ago.

Or they're using something like the grade book in Canvas, a very popular LMS, and finding that it is in fact slower than GeoCalc on a C-64.

I find https://danluu.com/input-lag/ to be quite convincing and a direct contradiction to your point. He has some analyses of various other elements of computing, too. We certainly haven't gotten faster across the board and I'm still amazed at how slowly many of the programs I use today actually load.

I tried to follow his advice for a while but didn't ever notice a perceivable difference between, say, st and alacrity. I think the justification for why we care about latency, there, is a bit fuzzy -- the examples he provides are about stylus inputs, the feedback loop there is more direct and there's more physical experience. I can't tell you what you feel of course. Currently I use kitty. Perhaps I'm blessed by unusual latency insensitivity....

I remember reading that piece, and found it to be interesting and accurate, but somewhat irrelevant. Most people just don't care about latency that much. If we go back to an ancestor high up in this thread, "low latency input and display" is not a goal of computing. "Enabling people to do things they find useful and/or have value" is the goal. And it just turns out that, for most tasks -- even most gaming tasks (or other things where you might say "low latency is important") -- low latency just is nowhere near as important as just being able to do these things at all.

Sure, we might sometimes notice the latency and find it vaguely annoying, but we put up with it because modern computing (with all the attendant "complexity" or whatever that makes low-latency hard) enables us to do things that computers of 20 or 30 or 40 years ago were just completely incapable of doing.

And for the people who really do care about low latency, they can usually build something custom that gets them where they want to be -- as Dan Luu points out in his piece.

I disagree, Microsoft Word on a Mac in the 90s was lightning fast and rock solid.

Few apps start up instantly in 2022. Many require a good network connection and/or a half a gigabyte of RAM, for no good reason.

Fwiw I would say he has been highly productive compared to most engineers. Two complete games of that quality nothing to sneeze at. But he does seem to take certain ideas much further than I would

> He has released two games in his career so far and an as-yet-to-be-released compiler that he’s been toying with for years: and he calls modern software developers unproductive!

In fairness he's been juggling multiple projects at the same time over the "for years" period that you mention: the new programming language, one major engine and game in said language, new releases for Witness and Braid, a secret game project, plus managing a game studio on top.

Also the two games he released "so far" are pretty popular and pretty well received by the critics _and_ they're programmed from scratch.

I think you're being a little uncharitable to someone that probably spends 75% of their waking life doing work (or ranting).

I don't think it's uncharitable at all. The point of writing software is to get it into the hands of users so they can use it.

I have a lot of respect for him for doing such high quality game work, mostly or entirely on his own. But let's not pretend he's some highly-productive programmer who churns out groundbreaking software at some amazing pace. I reserve such praise for people like Fabrice Bellard, who not only builds amazing things, but has built a lot of amazing things.

Tinkering around with a new language is cool and impressive, but it doesn't make you a "productive" programmer. Managing a game studio is useful work, but it's not "productive programming". I agree that his two games are great, and it's impressive how they were built, but... so what? He spent three years on Braid and seven years on The Witness. Is it "productive" to spend ten years writing two games? Not saying he was wrong to spend his time as he did; that's entirely his choice, and I know I personally have appreciated the output of those ten years. But I think many programmers have done much more productive things than building two games in ten years. I'm honestly not trying to shit on Jonathan Blow, but I think the hero worship I see over him is just a bit much.

I'd highlight the handmade.network software community, who superficiality side with Blow, but if you read their manifesto on their website, it puts a lot of emphasis on the end user's experience.

They cite Casey (of Handmade Hero), and I recall watching a casual lecture of his on a case study of Performant Software. In his conclusion he proposed that as innovative greenfield projects claim thr low hanging fruit of developing software markets, those markets will increasing reward competitors who can undercut on the basis of intentionally (or deeply) crafted software architectures and the associated benefits to users (stability and performance). This is could be refuted by the suggestion that early market participants can establish strong enough monopolies to overcome their technical debt, but still shows another source of motivation for the Handmade community's ideals.

They will get to relearn about first mover advantage and switching costs

I want them to be correct, but I agree with the sibling poster that getting to market first and developing network effects tends to win.

Perfect truly is the enemy of the good. "Good enough", by definition, is good enough, and perfection is rarely rewarded. Unless such perfection provides a huge leap ahead for users, which is rarely the case.

I think you're correct in this assessment. I've recently switched from many years of low-level programming, doing real time animation/graphics into the large scale SaaS world.

The things these two camps of software engineers care about are completely different. In the SaaS world it's all about interfacing between systems and managing complex business processes. There's often a lot of organization/political problems, along with auditing and legal requirements. There seems to be a lot more emphasis on developer productivity than end user performance.

Not that these engineers don't care about performance, but their tolerances are much higher. For example 100-200ms turn around is entirely acceptable, or even fast, in the SaaS world. While in my previous job that was absurdly slow, and unacceptable.

I think another under appreciated thing is that the scale and complexity is truly larger today than yesteryear. Even in real time graphics, Unreal Engine incorporates literally decades of cutting edge research into a framework that a new game programmer can start running with in hours. There's the various platforms like mobile, PC/Mac/Linux, graphics APIs like DX12, Metal, Vulcan, multiplayer syncing, animation, model importing, etc etc. There's just so many more things to support these days that there's going to be some slippage.

And each of these new tools and platforms were made with the intention of doing something better than a previous one, but then the real world creeps in and here we are.

It would be great to see more effort and research into rethinking from the base level, maybe even hardware, of how we can simplify this entire software stack and have our cake and eat it too.

I don't think inefficiency is his only point.

If it could be written with all the inefficiencies and deliver value faster without bugs, that's one thing. But the problem is, software is consistently buggy, and you run into them every day. It's now hard to notice because it happens so often, we're inured. That's why he challenges you to write down all the bugs you run into everyday, to make yourself more aware. You can see his list here. https://youtu.be/pW-SOdj4Kkk?t=1347

I've also done this exercise, and it's surprising how many you notice when you're looking for it and write it down.

Modern software is terrible in the sense that it's still buggy and hard to use despite access to immense power of modern computers--not merely that it's inefficient.

Jonathan does indeed complain about bugs, but as is typical for this type of programmer he's sure these are somehow being introduced by "Bad" programmers who are incompetent or lazy, not by "Good" programmers like Jonathan.

You get stuff like: "The Jai philosophy is, if you don’t want idiots writing bad code for your project, then don’t hire any idiots." which probably feels good to say to yourself, but of course it's not going to result in fewer bugs.

Jonathan doesn't like Exceptions, which, fine, I agree control flow and error reporting shouldn't be bundled together, but if you're serious about preventing bugs and you don't want exceptions, you need to actually write a lot of error handling, which means error handling needs to be ergonomic in your language. In Jai there might be error flags, you might be expected to check them but if you don't it won't complain because you undoubtedly know best. Pressing on regardless becomes ergonomic like in C.

And so Jai certainly isn't going to do anything about how buggy software is.

> Jai certainly isn't going to do anything about how buggy software is.

Nothing is going to do that, except the competence of the developer.

That's certainly Jonathan's contention. I would argue that it's already obviously wrong.

Sure, but... so what? The market has -- unfortunately -- shown us that it's better to put an inefficient, perpetually-buggy product in front of users, than it is to wait until you've micro-optimized everything and fixed most of the bugs.

The exact same argument we can use to describe why inefficient software tends to win can be used to describe why buggy software tends to win.

Of course users hate bugs. But even more they hate not having software to solve their problems. Hands down I would choose to have something with bugs today, than wait for something bug-free 6 or 12 months from now.

And unfortunately, once you put something with bugs in front of users, you're going to be pushed to work on new features for the next version, rather than fixing the bugs of the previous version. But arguably that's irrelevant! Users would rather have those future new features in 3 months, over having all their bugs fixed in 6 months, and then getting those new features in 12 months.

It still feels incredibly annoying and lame to me that this is the state of things. And I think that's why people like Jonathan Blow (and many, many others) just don't get it. Working software in users' hands trumps everything else. It almost doesn't matter how inefficient or buggy or $OTHER_NEGATIVE_TRAIT it is. If it solves unsolved problems, then it wins.

[Yes, I know, there are limits to what users will tolerate. But most inefficient, buggy software doesn't hit those limits too often. Software that does... well, yep, they tend to fail. But they're quickly replaced by other inefficient, buggy software that users will tolerate. They're not replaced by super-efficient, nearly-bug-free software, because building that software will always take much longer than building the software that users will tolerate. And users want to get shit done, not wait around while you tell them how much better the efficient, nearly-bug-free software will be.

I agree that one major contributor to these problems that he doesn't (fully) address in the talk are the unit economics and market forces that help along these decisions.

He does allude to it about faster software (slow being equated with buggy), and I think there are market indications that for specific markets, fast (efficient software) does win--though it is the exception seemingly, rather than the rule. The rule seems to be quick-to-market software wins.

However, I think his point has a wider scope, and I don't think it's irrelevant. Yes, in the short term, market forces push us to put software in front of people quickly, even if it's buggy. But is that beneficial in the long term? What would be the consequences of making short term optimal choices here?

Would we (as a society) forget how to build the things we rely upon in our society because the complexity is too overwhelming, and at every step, we never went back to clean things up and focus on transferring inter-generational knowledge, because we were too busy putting out features?

Just like in the Innovator's Dilemma, the incumbent at every step makes the optimal decision, but ends up getting trounced because a series of local optimized choices is not a globally optimized choice. And Blow here is saying (strongly), that we're doing something similar with how we build software.

And I'm inclined to agree with him, even though I fully recognize the market forces as being strong. Would we keep making short-term optimal choices because we have no choice? Or is there a way out?

Alan Kay has talked about this in some of his talks. He has some neat ideas, wrapped up in unintelligible slides. I've always thought he needs a graphic designer for his slides. Anyway, his thesis is that we build software today much like how Egyptians built buildings: stacking things wide in order to build high--evident by code bases millions of lines long. We have very few equivalent of arches in software. Once we had arches, we could build higher with less materials.

So perhaps there's a way out. We've been searching for it for a long time (in software years, but we're still a young field), ever since before the Mythical Man Month. And Blow, I think, is saying, there are real consequences to this software mess we find ourselves in, the worst of which is the collapse of civ itself, esp if we don't find a way to reign in the complexity and the bugginess.

Or we can pray for AGI to get done and do it all for us. finger guns

>The goal is always to produce things that users can actually use.

consumer software exists downstream from advancements created by people who care about performance and correctness. You can only do extremely stupid things because someone else did non-stupid things to enable that kind of waste.

That sort of works as long as the wasteful people don't outnumber and outrun the few people who keep everything glued together, but if they don't then at some point this arrangement breaks down.

Maybe let's try to convince developers and consumers to be smarter rather than try to make software dumber. We should take a page out of the semiconductor industry's book which is run by engineers and builds towards engineering and scientific targets, not consumer demands. Those are a byproduct afforded by increases in performance. That's why chips, unlike software, get faster.

I kinda said the same thing in another reply, but why can't we have both? We can have experienced engineers working on low-level perf and correctness, and then we can have normal, less experienced engineers who just need to glue together a CRUD app to save some people some time.

> That's why chips, unlike software, get faster.

The difference is that perf is a feature of chips. It's not necessarily a feature of software.

> Maybe let's try to convince developers and consumers to be smarter rather than try to make software dumber.

I don't get this. What would it mean for consumers to be "smarter"? Smarter in what way?

We taught the world how to read a century ago, surely we can teach every human how to navigate interfaces more complex than Twitter? Its just that today we expect interfaces to have zero learning time, that doesn't seem to be a very efficient use of software.

Like, imagine how much better many interfaces could be if we taught basic regular expressions in schools? Things like searching and filtering could be much more expressive everywhere. Regular expressions are so simple that anyone could learn them in a few hours.

> surely we can teach every human how to navigate interfaces more complex than Twitter?

Of course people can learn how to navigate more complex interfaces than Twitter, but why? For what? Certainly not for the purpose of social entertainment like Twitter et. al. What a waste of time that would be!

> Like, imagine how much better many interfaces could be if we taught basic regular expressions in schools?

Ok I've imagined it and I think the answer is "not much better". Pretty much all of us here know regular expressions and we all use interfaces purpose-built for people like us who know regular expressions, but beyond searching and replacing, this isn't a particularly powerful interface element. Like, it's fine and all, it's just not revolutionary. Searching could be made a bit better with widespread understanding and use of regular expressions, but little else would change.

I really think you're underestimating the extent to which interfaces are already really useful to the people using them. We have endless scrolls in social media, which is what people want for the mindless entertainment they're seeking. We have Photoshop for photographers, Ableton for people making music, really good CAD software, tons of good film creation and editing software, the Bloomberg terminal for financiers, really good editors and IDEs for people making software, etc. etc.

Of course there are exceptions, places where there is real room for improvement (I think streaming video interfaces are pretty bad, for instance), but for the most part interfaces are what they are because they serve their purpose well, and not because people are lacking education in their use.

I think the language you use in this post is telling. Under a certain interpretation it's not exactly incorrect, but that framing doesn't really tell the full story.

Your main dichotomy is people doing stupid things vs people doing non-stupid things. But if you consider that "stupid" only makes sense with respect to a particular set of objectives, you may find that other terms are more suitable for characterizing the general situation.

I think you can roughly describe how many resources should be devoted to performance and correctness* as a function of 1. how many other systems will depend on the system in question, and 2. how much departing from the ideals in performance/correctness will impact individual users.

As both 1 and 2 decrease, an ideal development resource allocator would decrease the amount allocated to performance/correctness.

I would argue that making sacrifices in performance and correctness is not necessarily stupid behavior at all; departing from an ideal resource allocator would be the less smart thing to do.

*Assuming you're working with a resource pool smaller than what would be required to produce an Ideal product, as is typical.

> We should take a page out of the semiconductor industry's book

I see this sentiment by programmers often. Programmers often have a naive/romantic view of what the semiconductor industry is like. If you've experienced how inefficient the meatspace operations alone are regarding what goes on to bring semiconductors into existence, even by meatspace standards, you'd wish you were surrounded by the kinds of peers who were dumping bloaty-by-nature Electron apps on the world. (That's before we even get to the software that those engineering orgs are cobbling together themselves, for a more direct comparison.)

> The goal is always to produce things that users can actually use. And if that means doing hideously inefficient things, like running your app inside a chrome shell, so be it, if that means you delivered value faster.

I guess core issue to me is this value delivered to whom. So far the value I see it is for framework users who could pull a 100K lines CRUD app in one month, of which 99% is just framework glue/code.

However as end user I am getting rather bad user experience, my computer fan is running at full speed, Loading webpages or filling online forms so slow, endless error popups come and disappear and I can't do anything about it. It is not even about efficiency, just plain unreliable/unusable software delivered in name of "empowering" me.

If I weren't software engineer I wouldn't even know that this crap is pulled by software engineers. Non-technical person would simply assume computer is bad/old, internet is slow and so on.

He's also claimed that our computers are 2+ orders of magnitude off the productivity that should be achievable while reaching his goals. It's not so much that all software of old was amazing, it's that we really have lost something when RemeDyBG is 1000x faster than Visual Studio, with Visual Studio having hundreds of years of development effort and RemeDyBG has a couple years of development effort.

His philosophy is that if we built software differently, we could build it faster and it would be faster. The emphasis on garbage collection and borrow checkers and everything else related to memory management misses the point (memory arenas are way better for the vast majority of use cases). The emphasis on Object-Oriented code is awful. The paradigm of RAII is completely counterproductive. There are very specific issues that Blow takes on, not just a general feeling of malaise.

Kinda think that you celebrating being wasteful is proving his point.

In my mind writing performant, somewhat efficient code does nothing but improve the UX, and if you actually care about your users having a good experience using your software then you shouldn't be celebrating wastefulness.

Wasteful is relative. By focusing on optimization you are being wasteful with programmer's time.

Making a better product is not wasteful of anyone's time.

Better for who?

What you consider good and I consider good for a product can, but doesn't have to be the same. And there is an opportunity cost in doing one or the other.

I think it is important to have at least some software as efficient as possible, especially server software, because huge data centers eat a lot of electricity and we cannot always take cheap electricity for granted.

(The recent price spikes in Europe are crazy.)

That said, such improvements may well be canceled out by other activities such as Bitcoin mining.

One of his point is that software engineering techniques did not improve at all, and even regressed, but all of that is/was hidden by the fact that hardware got us a free ride for several decades.

You can use terribly slow scripting and techniques and get something working, not because the tooling is genius, but because the hardware is so incredibly fast.

I think the most steelman version is that he argues efficient software does in fact provide value to users. Whether or not they know it. And perhaps not always in terms of the application they have running right in front of them, but at a systemic or societal level. Little things add up, especially since software has eaten nearly every crumb.

I very much disagree with JBlow because I came from games, I had similar opinions, and then I worked on "real software" (Chrome) and I had my thinking corrected. The problems JBlow and similar game devs are solving are not the same problems being solved elsewhere if you they really tried to solve the *same* problems I strongly believe they'd change their minds.

IIRC one example he once brought up was a text editor written with a small amount of code. Yea sure, I also had a word process that fit in 16k (https://en.wikipedia.org/wiki/AtariWriter) but we're not on ASCII based computers with only text mode. Just a full unicode font takes 10s of megs of space. We're asking our software to draw fonts in any size, in several styles, in any language, and with emoji. That alone would break most of his assumptions because you can't just put them all in memory as pre-rendered glyphs, your user's don't have enough memory. Yet in games, most game devs would just basically say "F-that, you only get ASCII" or "F that, we're only supporting EFIGS + Katanana" and we only need 1 style.

Two good articles on the issues of text that games never deal with

https://gankra.github.io/blah/text-hates-you/

https://lord.io/text-editing-hates-you-too/

The point being, it's the same all the way down in all areas. Game networking is not nearly as complicated as say the networking in a browser, that has to be able to run N video streams + M audio streams + X WebRTC video chats + Y Websockets, and video capture + audio capture and sending that data over the net, etc vs some game which if it ever plays video (many don't) only ever plays one video at a time, in known sizes and formats, and usually not streamed over the net but read directly from storage, etc...

Or take just displaying images. Most games know up front how many images will be displayed. You might even give your artists a budget, no area of the game can use more than XX megs of image data. A browser can't run with those limits. Go look at imgur.com or scrolldit.com or pinterest. Situations games never deal with.

And on top that there's just getting shit done. If I can write an app in a high-level system and ship on iOS, Android, Windows, Mac, iPadOS, I'm going to. I don't care that it's more bloated than if I hand coded assembly language for each one and neither do my customers. Sure they care if my app is buggy or the UX sucks but that's got nothing to do with whether I squeezed out every last byte and cycle out out of it. HNers like to rant about apps that use some kind of less than native framework but nearly all them are using well made apps that use those frameworks, they're just not aware of it because the people making them did a good job.

I do not want emoji on my computer, and I hate Unicode. I also think that bitmap fonts are less fuzzy, and can be better at the proper size.

I write software avoiding Unicode as much as possible; if you need international text then you can specify which code page numbers to use. But, that still would be possibility of text directions, Chinese/Japanese (without Han unification), etc, but using a simpler way.

(Even, this is as someone writing a game engine, I add possibility to specify code page numbers, and use fonts for those code pages. Currently only 8-bit characters but in future possibly also EUC (and/or other multibyte character sets) so that Chinese/Japanese text, etc is also possible.)

GTK is terrible (I prefer Xaw). Use of Unicode is one problem, but then although there is a menu to insert Unicode control characters, they are not visible even while editing (making it difficult to edit), and I also do not like the use of kerning during editing.

> I do not want emoji on my computer, and I hate Unicode.

Ok well good for you but that’s akin to saying “I don’t want other languages than English on my computer and I hate the color Green”. It’s completely irrelevant what you prefer, the point of general computing is that it’s not for you, it’s for everybody. If you are writing software for everybody then I’m sorry but xenophobic assumptions just don’t hold.

Because really, what’s hidden in the meaning behind your post is “I don’t want people who speak languages other than English to be able to communicate as easily as me”. I’m sure that’s not your intent but it is the direct result of your actions.

It is not true. I do want people who write in other languages to be able to communicate (better than me, not worse), using better encodings than Unicode. I do intend to support other languages writing, including international text (text directions, multibyte encodings, etc). However, Unicode is too messy and isn't good (and has problems such as the Han unification, ambiguous widths, changes in versions of Unicode which complicate the specification, etc). Some people think that TRON code would be better, although TRON has its own problems (for example, its design means that character sets other than JIS don't fit properly), even though there are some advantages, especially for writing in Japanese. My opinion is that it is better to not use a single character set for everything; instead, different ones are useful for different purposes.

(And if needed, program to convert encodings is possible, although this can result in incorrect characters sometimes, depending on the context. It is an approximation if you have no other choice, but it would be better to use proper fonts and text handling for the appropriate code pages.)

Think really carefully about it though. Going back to separate charsets for everything would mean losing the ability to communicate multiple languages as part of the same text.

This might not matter to you, but it matters to… for example… anybody learning a language. Например, я провел последние месяцы, изучая русский язык. Как бы я написал это, если бы мой пост был в ASCII?

I have thought about it, and considered many things, and I had concluded that Unicode isn't better. Different applications require different capabilities, and Unicode has problems with mixing languages (including Han unification, and others such as Turkish letter "I"), ambiguous widths, character equivalences, homoglyphs, and other problems. (Which things are desired and undesired, and which things are missing, or are incorrect for the specific use, depends on the application.)

You can still include, in some formats (such as document formats), codes for code page switching. This has some advantages including Chinese/Japanese together in the same document, as well as being a cleaner way to implement mixed text directions, etc.

Also, sometimes the character set does not have all of the Chinese characters. Cangjie can make many more possible Chinese characters, but maybe an extended with up to six parts might allow more combinations; I do not know for sure.

And these considerations are not even close to everything. Different sets of encodings are useful in different uses, I think. TRON code has its own advantages and disadvantages compared with Unicode, but I think that switching encodings also has some advantages (and also disadvantages), too. (There are also some things that I do not know of TRON, due to the documentation being difficult to find.)

One idea that I have seen is having a separate language and glyph field, to allow displaying approximation of characters that you do not have in your computer. Whether or not this is appropriate depends on what you are making, though. I had thought how to do something similar with a "output-only encoding" which has several fields and is also linked to the text in originally whatever encoding it might be, which also allows approximated display of fonts that you do not have in your computer, but it is only used for display and only as a fallback mechanism.

(My opinion is that mixing text directions within a paragraph should not use line breaking in the middle of a quotation that is not in that paragraph's main text direction (for text in the opposite direction, only short quotations should be inline); use a block quotation instead if needed.)

Maybe, I should need to make up ICNU (International Components for Non-Unicode), to properly deal with international text. I have dealt with such things so I know what some of the considerations are, in making an interface with the needed capabilities. (One capability I intend to include is possibility of using TRON character codes too, although you can also use other character sets, including Unicode in some cases (such as existing files and fonts that are using Unicode). However, usually extra data files would be needed for many purposes, but you can specify how to find these files. Furthermore, the ability to disable specified encodings (especially Unicode) also is important.)

My own designs of programs, file formats, protocols, etc are avoiding Unicode as much as possible, since I think that other way is better. However, in some cases you can specify any code page number anyways, so you can still specify code page 1209 for UTF-8 if wanted. In other cases, this does not work (since it is not appropriate for that specific use).

> write software avoiding Unicode as much as possible; if you need international text then you can specify which code page numbers to use.

For the sake of humanity, please don’t say we should consider bringing back code pages. My European language alone has 3 different ones (or was it 4?), and you can still see some places where code pages keep causing problems posthumously because they mojibake quite readily into other encodings and screw everything up. I was an infant when codepages were all the rage, and it’s still causing problems to this day even though I never had to contend with them in day to day use.

Unicode is not perfect, but it’s here and it provides a unified character namespace for the whole planet. That’s certainly something I don’t want to leave behind.

And the new James Webb telescope runs Javascript! It must have power and CPU cycles to burn.

I'm genuinely curious why you think they chose to have it run javascript.

I just spent a few minutes looking into their actual usage of it and, ime, it has all the indications of being a reasonable decision.

Here's a bit more info from [0]:

> It is my opinion that NASA settled on the Nombas engine, after extensive research of their own into all the options available at the time, not so much because of the JavaScript language itself (although the familiarity of the language was a bonus), but because of the solid and robust nature of the ScriptEase engine and the tools that went with it.

[0]: http://brent-noorda.com/nombas/us/index.htm

Can't wish away the power, memory, and speed issues JavaScript has, meaning the telescope must have all three to burn.

I've written a Javascript engine back in 2000. I came away from that with a distaste for dynamic typing. It seems easier to write code with dynamic typing, but I wouldn't give it many points for robustness. JS has many odd behaviors if an unexpected type was passed to a seemingly simple function.

You've sidestepped my question though :) Why do you think NASA made the decision to use it? Is it not possible there were legitimate reasons?

The implications you're suggesting about power, memory, and speed, or even predictability in semantics, depend on the particular language spec they implemented (it was not standard ecmascript), how they implemented, and how that implementation was used within the larger system.

It seems to me like just knowing it was javascript (for some definition of javascript) is not enough.

> Why do you think NASA made the decision to use it?

Probably because they couldn't find low level programmers, it isn't easy to find people with good professional experience in C today, especially if you pay NASA wages.

This is certainly not the case. For more details do a little exploring in the link I provided above. For one, the bulk of their code is low-level, just not this particular system where it wouldn't have made sense; for two, they did this in 2002 when it was almost certainly easier to find C programmers than javascript programmers; for three, the people writing this javascript were domain experts, not professional programmers.

Some people would kill for the ability to put a 1/2-year NASA stint on the resume, if for no other reason than the idea that they contributed to the scientific research and exploration of space.

Javascript in those days was far slower and needed much more memory and power than native languages. Nothing in your link suggested otherwise.

I'm not entirely sure JavaScript itself is horribly worse option than anything else available.

Now the ecosystem currently build around it...

> But running software that fit in kilobytes of RAM was never the goal of software engineering. The goal was providing value to your users.

By this definition of the goal you are indeed obviously right. So it's pretty clear that Blow and others don't agree with this goal. I'll try to map out two different povs on the goal of engineering: imho the goal you are describing, talking about "value" etc is associated with a world-view based of economic exchanges, on the idea of markets. In this world-view, engineering will have as goal to sell something to a third-party and be profitable to you, thus you will minimize your costs and do the minimum you can get away with. This is the pov of current hegemonic the economic sphere.

What Blow defends, ie an engineering goal of using minimal resources for a given concrete objective, is much more in line with a world-view based on commons, on basic infrastructure for common needs. In this world, the most natural setting for doing the engineering work is not one of economic exchange, but one of cooperative, where the people that need the thing get organized somehow to get the thing done. In this setting, it is clear that the goal is not to do the minimal thing they will be ok with, the goal is to create a durable tool that will be practical to use and use minimal resources. In particular the investment (in human planning) can be very high, it doesn't really matter. This world is also close to the concepts of lowtech (basically favoring simplicity and robustness).

> Yes, some users do care, and I think that a disproportionate majority of them hang out on Hacker News. :P

A disproportionate majority of what? This is a classical hn fallacy: yes apparently hn likes to defend things being done "nicely" (at a good technical/resource tradeoff point) and not just "well enough" (at a short term profitable tradeoff point). But the silent majority that doesn't care you are talking about is very much restricted to the people that can afford paying for ever changing computing devices. Old people (cannot change fast), young people (get old family devices), people in less geopolitically gifted areas (less globalized purchase power), .. they all have almost obsolete technologies because they are constrained in several ways. You are talking about the majority of people that are visible to your economic world, but a lot of people are not inside of it, or on its outskirts (and if you say "but the economic sphere must be more inclusive and expand" then you are again pushing a particular view, which is not the only one and is debatable).

One can also make the case that with the current state of affairs regarding fossil energy and limits to growth, going further more and more people are going to have these big constraints. This second view is very popular with people thinking seriously about ecology and crisis.

Reply on news.ycombinator.com