Hacker News Reader

Comment by falcolas | Hacker News Reader

I found this to be a great reminder of how far we've come in 16 years, but it's also a reminder of how little some of the basics have changed.

We still advocate going down to A lower language for the fast boys, but we can more or less forget about having to write ASM for all but the most complicated algorithms.

We still fight platform differences, and DirectX is still one of the most powerful and developer friendly frameworks.

Low level knowledge is still mocked by some individuals, yet C++ is still the God of graphics and video games.

View on HN

In that 16 years, we got new (and mostly unnecessary) layers of abstraction on what existed previously. Whole single-page-application crowd (eg. Sencha, React...) is busy reinventing things that already exists three layers of abstraction down from the level on which they code.

DirectX was interesting in that age because of exactly the thing in article: you can allocate sound buffer and one surface and view that two COM objects as hardware and not care much about performance implications of the abstraction in between. Once you start drawing to (to borrow X11 terms, as I'm not too familiar with GDI/DirectX) IndexColor surface that is shown on TrueColor display, you get slowdowns in the abstraction layer on the order of "2005 highend Windows NT workstation renders at 2FPS what random office computer from '94 on DOS rendered at 60FPS" (see OpenTTD for example of exactly this performance regression).

For last 25 years hardware acceleration for graphics is readily available for all performance tiers but still, you need to have quite low-level understanding of how the hardware works to get reasonable performance (and as for working-around hardware and driver bugs, we are currently in mostly same situation as 25 years ago and it was better in the meantime).

>> Whole single-page-application crowd (eg. Sencha, React...) is busy reinventing things that already exists three layers of abstraction down from the level on which they code.

Except, you know, that part about running on the open web. The web is a deployment platform. Developers want to write the least amount of code to be able to support the most users possible. That was supposed to be Java, but it didn't work out that way. Deployment is still a platform-specific issue in Java, because users--for whatever reason--hate WebStart and its ilk. Add to that the fact that smartphones just plain don't support Java in that way and suddenly the browser makes for the only pragmatic cross-platform toolkit for building applications.

Yeah, JS sucks. Yeah, DOM sucks. Objectively, they are terrible. But for as bad as they are, there aren't any good alternatives. And no, building from source is not an alternative.

Building from source is happening anyway. The browser is pretty much a js logic/html+css view compiler. It just JITs it when the page loads instead of creating a downloadable binary.

With node/io and Go, servers have been build-from-source for a while.

Given the snarly mess of frameworks/tools/languages/abstractions used in web dev, it's not obvious you'd get worse performance or inferior code using JIT LLVM and some newly minted update of Visual Basic or Swift with component/object/view caching.

That's not what I meant by "building from source" and you know it.

Huh? I was just pointing out that the distance between building a binary from a mess of source files and building a web app from - er - a mess of source files is not that huge.

And the trend is for it to get less huge.

E.g. Bootstrap already uses the words "custom build" for a rebuild, and js-world has gulp and grunt for "building".

There's already been serious talk about either throwing out the DOM or abstracting it with something closer to a native code model.

Honestly, I'll be surprised if this doesn't happen within the next few years.

And that has nothing to do with users using the software. My point was that you can make even C code "cross platform", with a lot of effort, if you make the user build the program from source. But that is just about the worst possible experience for the user. Building cross platform applications as browser SPAs is easier on both the developer and the user.

> Given the snarly mess of frameworks/tools/languages/abstractions used in web dev, it's not obvious you'd get worse performance or inferior code using JIT LLVM and some newly minted update of Visual Basic or Swift with component/object/view caching.

What is obvious, however, is that more users have a Web browser on whatever device they want to use to use your software than have a virtual machine environment for any language besides JavaScript.

> In that 16 years, we got new (and mostly unnecessary) layers of abstraction on what existed previously.

I don't know about you, but I'd much rather write a simple web service application in python than in assembly.

That's a totally different domain, where abstractions are most likely for the better. The bad part is the abstractions at places where they're not wanted e.g. graphics and other high performance systems programming. Abstractions are fine if you can opt out, but don't take away the control from those who need it.

The same fundamental equation applies to both domains: Software engineering hours are expensive and hardware is cheap.

I just ordered a video card with 24 gig of ram. Well, calling it a video card is not quite right as it's a K80 Nvidia HPC cards, but as a software engineer working on a team of 5 computer vision/R&D guys and two software engineers, I can tell you that I do not want to live in a world where I have to fix code written by researchers that's juggling around vram and managing 4,992 threads. I'd much rather have that abstracted and have a clean API that hides the complexity.

And in terms of performance, you do not have to spend many man-days trying to debug some horrendous pile of code brought on by the complexity of exposing every tweakable bit of a architecture in order to exceed the cost of X addition $5000 HPC cards running less performant but far less complex code.

Is it not the case that many/most games now are some smaller C++ components being scripted by something higher-level?

That was the case in second half of 90's and 00's, today most engines got back to C++ plugins (or plugins in same language as engine itself) and simple declarative logic in game data.

(this has to do with both performance as with various walled gardens that do not allow general purpose scripting)

The Apple App Store has allowed scripts for some time for this exact scenario. I'm not sure which other walled gardens you mean though.

Reply on news.ycombinator.com