- Sep 2022
-
jacksongl.github.io jacksongl.github.io
-
We propose building an infrastructure that makes it easy tocompile existing projects to JavaScript and optionally collectusage data. We plan to leverage existing tools to translateprograms into JavaScript. One such tool is Emscripten [15],which compiles C/C++ code and LLVM [14] bitcode toJavaScript.
It only occurred to me reading this now, and musing about the code size and relative performance of simple programs written first in a to-be-compiled-to-JS language and then in JS, that the folks associated with these pushes are taking the sufficiently smart compiler position. Connected to superinferiority?
-
- Aug 2022
-
scattered-thoughts.net scattered-thoughts.net
-
Of the two, the html version is the one where I've spent a bunch of time trying to understand and improve the performance. In the dear imgui version I've done the easiest possible thing at every step and the performance is still fine.
Tags
Annotators
URL
-
-
news.ycombinator.com news.ycombinator.com
-
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.
If the thesis is sound, then logically we should expect the instances where people have decided to "use terribly slow scripting and techniques" to produce better programs; the not-slow (non-"scripting") stuff to be worse.
You can only pick one:
- software is worse because hardware improvements mean that what were previously noticeable inefficiencies are no longer noticeable
- programs that are written in low-level languages and don't as much incur runtime overheads are better on average because they're written in low-level languages that aren't as wasteful
-
-
www.joelonsoftware.com www.joelonsoftware.com
-
Corollary: Spolsky (at least at the time of this article) didn't really understand types, having about the same grasp on computing fundamentals as your average C programmer.
-
-
wiki.arnaudcys.com wiki.arnaudcys.com
-
It should be dead simple to distribute content (eg. static content).It should be easy to build apps.It should be not too hard to build a platform.
The thing that gets me about takes like this is that it's all the stuff below the Web content layer that accounts for what makes all this stuff harder than it needs to be.
What's the hard part about distributing content (static or not, but let's go with static for simplicity)? It's registering a domain, updating DNS, and keeping a Web server up—all systems that have nothing to do with the "infernal" trio and also generally programmed in what are typically described as saner languages and their traditions. It's either that, or it's relying on somebody else, like GitHub Pages, and integrating the implementation details/design decisions for their value-add into your workflow.
To "build a platform" is ambiguous, but it sounds a lot like "creating a server-side application to serve non-static content and handle associated requests". Is the infernal trio to blame for the difficulties of that, too?
-