The rules of the game are pattern matched onto the state of the game. A single rule defines a pattern, and a modification. "If the player is adjacent to a crate and has movement in the direction of the crate, add movement to the crate."
I'm talking about stuff like putting your code in classes, initializing with constructors, or using your language's standard library instead of writing your own stuff.
Perhaps idiomatic was the wrong word. I mean that the code isn't supposed to be fighting the language.
What were your observations when you were contributing? Which problems were you working on? Any chance you still have the code?
This criticism is flawed. The fact that the code is imperfect or sub optimal actually makes their conclusions strong and more useful for real world comparisons.
The code guidelines in their benchmarks represent real programming practices in those languages. They promote "idiomatic" code because it is meant to represent the typical quality of code in the real world. Obviously many of the examples could be made more performant, but in doing so you would made the code less representative of the real world. Example: the typescript code outputs wanky ES6 features that are slower than their old plain js counterparts (classes, arrow functions, let, etc). You could abuse the ts code until its output is identical to js, but you would have a pointless benchmark now.
What would the benchmark honestly represent if the code looked nothing like code in the real world? The theoretical speed of the language just doesn't matter.
In fact, JS engines have been optimizing their performance around numerical benchmarks for decades. The benchmark problems (nbody, etc) are actually highly unrepresentative of real javascript performance because real world javascript is touching strings and awful DOM apis and messing with dictionaries all day.
Your 'real-world workload' should be stuff like text editor operations, a domain where JS's alleged 6x slowdown compared to C has not been remotely approached by current editors.
And he has come to the conclusion that he is making an optimizing compiler.
Perhaps the reason he thinks web frameworks will help us 'approach native performance' is because he doesn't know what native performance is? Could you really understand web performance if you don't understand native performance?
> When it comes to eking performance out of hand-authored JavaScript and accompanying runtime libraries, we’ve reached the point of diminishing returns.
Are you saying that web developers are writing the best code that they can? That future gains are going to come from more advanced js preprocessors instead of more informed developers? I strongly disagree that we have reached any sort of diminishing returns when it comes to the quality of hand written code.
> Between WebAssembly, SharedArrayBuffer and Atomics, and maybe even threads in JavaScript, the building blocks for the next generation of web applications are falling into place.
Read the specs for one of these. Read the specs for any of these. Read the specs for js functions you call every day, and image what the native implementation looks like. The web will never approach native performance because w3 has been sabotaging it for a decade.
> time to learn how compilers work.
I think the author would benefit from learning about how web frameworks work, or perhaps how web specs mandate that your browser works.
https://www.puzzlescript.net/play.html?p=6860122 https://www.puzzlescript.net/play.html?p=6910207 https://www.puzzlescript.net/play.html?p=7072276