shortercode

My brother had his plates nicked a few years back. Apparently they had lightly modified his plate so that it appeared differently ( can’t recall if it was marker or tape )

I used to work on the Construct 3 game engine. It’s great for doing small games. You can do a lot by just dropping images in and adding “behaviours” like “platformer movement” and “solid”. Which is enough to build a simple platform game without any coding.

It scales pretty well from that, allowing you to build logic trees in a scratch like environment or go full code with JS.

Trial version is free, and browser based so no install. Loads of examples and demos in the editor to try as well.

This book is intended to be a cover to cover job. I tackled it about 2 or 3 chapters at a time while building alongside. But after the midway point where it swaps to a C based byte code compiler I just read it instead.

There are books like the dragon book which cover PL design in a more reference book style. But I don’t recommend them.

If you’re looking for a lighter alternative then “writing an Interpreter in Go” is worth a look.

Also Bob Nystrum has some other good material on his blog, and a chapter in game programming patterns about PL stuff.

It hasn’t been useful for some while sadly. Moderation is so aggressive that they seemed to have forgotten the purpose of the site is to help people.

Quite a lot of the existing content is outdated or unclear. Also good luck writing a question that is both acceptable and there’s someone who knows an answer…

It's "mature". So it's well understood, documented, used in libraries, has guides all over the place and relatively few bugs.

It unlocks a number of nice to haves over WebGL 1 which improve usability, quality and performance. As Safari was the last stand out developers can now rely on these things being there.

It's here now. WebGPU has been on the horizon for many years, and probably will be for several more before you can actually expect it to work on users browsers. Presuming we don't end up with a repeat of WebGL 2 on Safari.

It's simpler. Much like DX12, WebGPU is intended to be lower level and have better control over hardware. Which makes it more complex and harder to use Vs WebGL.

It has plenty of community knowledge from OpenGL ES peeps, which makes it quite easy to find examples that can be used.

For anyone actually building this style of content today, this is huge news.

As someone who spends a lot of time looking at ASTs it feels slightly naive to write off type keys completely. They are particularly useful in TS because it uses flow analysis to isolate the correct interface pattern from a union of types. Although I will generally encourage using conditional flow to direct to variant specific functions instead of mixing types in the function body.

I would heartily support the refractors given in the examples if they reached me in an MR. But chances are that a type key is introduced in 1 location, and then acted on in 6 different locations with a large temporal distance. Without the type key you are likely to need some way to infer the type, which may be error prone and hard to maintain.

On a micro scale a common example is where you have to pass over a list of statements to declare the functions, and a second time to define them. So that they can be self referential. Preferably without N scale memory allocations caused by things such as filtering the list.

Not all smart motorways have the hard shoulder thing, the ones that do have semi frequent "stopping bays". However, stopping in one without contacting the support staff(there are intercoms) or a good reason is an offence.

They all feature per lane adjustable speed limits, as well as linked speed cameras at frequent intervals. This is supposed to help ease congestion by adjusting flow in certain areas.

In practice random signs are often left on the wrong setting, so you get a speed reduction to 40mph for 250m. Or a lane is closed for 6 miles with no reason.

I've no doubt that in the scenario where there is congestion that it greatly aids safety, as approaching traffic can be slowed before they reach the affected area

In an ideal world it probably would!

WebAssembly only provides very minimal capabilities, anything more complicated than basic arithmetic and linear memory access require the features to be built. malloc, closures, arrays, error throwing, GC etc. all must be implemented. Some language features like console logs and visual output physically aren't possible, and must call out to the host ( normally JS ). Requiring the compiler to emit 2 languages.

In comparison JS has analogues to many common language features, making it easy to transpile to. There are other advantages to JS as well, but probably not worth listing.

It's complicated, and emitting JS is easier.

Codepen uses a system that measures loop duration, and it's a giant pain. Having done some pens that do ray tracing and image transforms which can have long running loops. Given the variable execution time of JS it can be quite random. It just exits the loop without warning, causing weird failures in your code.

2 theoretical solutions ( with significant overhead ) are:

Run the code in a VM ( maybe quick.js compiled to WASM would work ) that suspends code execution periodically if it exceeds a certain duration. This has the advantage that long running code in general won't block rendering, not just loops.

Transform the AST to use async generator that yields once per loop. This would allow the loop to be suspended and resumed. But it would require a lot of modification to the AST, making effectively the entire call tree async.

Interestingly quite similar to my own progression. I think working in modern typed languages ( Rust, Swift, Typescript ) is what primarily changed my viewpoint in a way that C and Java just couldn't.

In the last year I've transitioned from full time JS development to full time TS development and have been pleasantly surprised how easy the transition was for my personal projects. Previously I had been quite adamantly against TypeScript; seeing the type system as an unnecessary level of complexity given I already structured my code in quite strict ways. In most it helped me find 1 or 2 small errors, but it certainly helps reduce the amount of time I spend verifying the behaviour of code. It definitely has its flaws, but most of them are linked to its compatibility with JS and I don't think they can be resolved unfortunately.

The largest issue with concrete is that we misuse it. As a building material it has great thermal mass ( aiding temperature stability ) and longevity. But all too often buildings are poorly designed for renovation, and hence end up being torn down after a couple of decades. A small fraction of the useful lifetime of the structure. Any building using concrete for a structure should be aiming to last at least 100 years.

For those who didn't read the article: the chemistry of Portland cement works against it. Production requires heating the calcium carbonate to a high temperature to extract carbon dioxide from it. Which obviously produces large amounts of CO2 proportional to concrete production. However, concrete also absorbs carbon dioxide from the air over its lifetime. So the measured emissions aren't the entire story.

Perhaps in future we will consider this an excellent source of carbon dioxide for the production of various hydrocarbons. I've heard of several efforts to create octane using carbon dioxide from the air, but you need a large amount of energy to extract a useful amount of CO2. Well this would be a good source of high concentration CO2. Perhaps not for octane ( we should really be moving away from combustion engines ) but perhaps plastics and other products that are currently derived from crude oil.

Atomics is part of the threading APIs, I'm guessing your browser doesn't support it. Although I feel like you should get a better error message...

While not quite the same the V8 team has a blog that discusses various improvements they are making. Such as the Orinoco GC project. Which typically contains some details on the implementation.

It's a fairly fascinating window into the inner workings, and quite detailed.

https://v8.dev/blog

This seems particularly unhelpful for bug reporting systems. Being able to see a specific bug is only happening on Chromium 78 for Linux can save a lot of time and frustration. In theory the user can fill in the details on a bug report themselves, but it's hard enough to persuade them to copy paste the crash message we generate for them at the moment.

Some companies in the UK offer health insurance for private healthcare. The main advantage of private being you can get appointments much faster. I'm not really sure what the relative pricing is for private healthcare in the UK vs the states, so it might be the insurance costs reflect that.

Sad to hear WebSQL is finally going away. I used it a number of years ago for a mobile only project. At the time indexeddb was effectively unusable on iOS, and the data we had was too large and complex to store in localstorage. WebSQL was perfect for the role, and worked really well.

The only issues I had with it are the lack of documentation and the fact IE, Edge and Firefox didn't support it. Perhaps it's not surprising that the MDN documentation was lacking, but I made do. Browser support on mobile was actually really good, so that didn't cause any issues.

Nowadays I'm relatively familiar with indexeddb, but I'm convinced the same project would be harder to implement with it.

There's currently a proposal called "KVStorage" to add a localforage style inbuilt module to browsers.

https://developers.google.com/web/updates/2019/03/kv-storage

I'm not totally agreed with the idea of inbuilt modules, but the API is very pleasant.

I work on a fairly large project that relied on localforage for a long time. However, we have since moved to our own library to resolve a number of small issues we had with localforage.

Writing an Interpreter in Go and it's sequel Writing a Compiler in Go by Thorstan Ball are both excellent reads.

Also enjoyed Game programming patterns by Bob again, but that has already been mentioned.

The possible syntax for Object literals is a lot more complicated than what JSON can contain. Hence the JSON parser is faster than the JS parser for the same object.

JS object literals allow such fun things as:

  {
    "foo": "bar",
    foo1: function () { return "bar" },
    foo2: () => "bar",
    foo3 () { return "bar" },
    get foo4 () { return "bar" },
    ["foo5"]: () => "bar"
  }

If the objects are not guaranteed to be in order, I would always consider them unordered. You could if both the producer and consumer are ordered, but as the OP noted this can cause problems later on and for no good reason. I'd use an array of key-value tuples if I wanted it to be ordered.

Last time I tried keeping a collection of simple DOM nodes to "recycle" my perf tests showed it was slower than just creating new nodes. So I wouldn't necessarily consider this an optimisation, although memory use might be better.

As someone who has tried to do make a Minecraft clone in JavaScript perhaps I can shine a light on why I tried it. I guess first and foremost I'm fond of Minecraft and I'm primarily a JS developer. So when I wanted to improve my game development and webGL/openGL capabilities it was quite a natural choice. Jumping into the actual project there's a few attempts around on the web, probably by people with similar mindsets. This means there some references on roughly how the game works. There's some quite interesting little things I learnt from it: implementing perlin noise, procedural generation techniques, triangulation of voxels, various boilerplate stuff for webGL and webGL 2, voxel optimised ray casting, deferred rendering, shadow mapping and world chunking.

All in all it was quite profitable; several of those things have come in useful for my day job since then. Of course it didn't much improve your game design skills, as I was just copying another game.

I never finished it, and looking around most of these copies are in a similar state. I'm proud of what I achieved and each problem I overcame but I can't even claim mine competes with the original or even the best clones out there. It's fairly easy to reason why most of these clones were never finished. It's a huge amount of work and the goal has already been reached by someone else. So motivation after the initial "oh hey I built something a little like Minecraft" is hard to find.

These sorts of project serve 3 purposes: - inspire others to try something similar ( hopefully for the same reasons ) - improve your own abilities - show appreciation to the developers of Minecraft

As for why this project is "hacker news worthy" I expect it's just because it looks more polished than most. But as I said above, most of the value of the project is to the developer, not anyone else.

I consider it a must that code should be correctly indented, no matter the language. What I have issue with is relying on whitespace to represent scope etc. With .sass files I've had too many occasions where moving the content around between editors has completely borked the file, and without braces it's tedious to correct the indentation. This is mostly the fault of text editors trying to be "smart" about indentation, and failing miserably, but it's a pain I'd rather not exist.

I know this doesn't match up entirely with what you want syntax wise, but the following works and I consider it quite elegant.

  {
    let row;
    if (row = await db.findOne()) {
      //
    }
    else {
      //
    }
  }

I always assumed it was to protect against: accidental naming errors, confusion of what a declaration is and copy/paste issues. When I first started writing rust and saw it was a thing I thought it was a terrible idea. I'm a more open towards it now, the strong static analysis Rust does help and it can improve code quality if used in small amounts. However, it still can be quite confusing.

Given that JS doesn't restrict the type of a declaration you can just assign a new value to it, place it in a small scope or use a chain.

Looking forward to seeing it complete! I got into programming languages after reading Game programming patterns, and I'm absolutely hooked. When I saw you were working on this book I worked through the first half of it in a week using JS, loved it.

I started the second half in Rust about a week ago, I don't have enough vacation days to work through it at the pace I did the first half. Finding it a bit harder so far, but I think that's just because I'm still new at Rust.

You may have already mentioned this but will you be publishing a physical copy when your done? I'd love to get one for the shelf.

I haven't tried other diary alternatives but recently tried Oatly and was pleasantly surprised. By itself it tastes remarkably similar to diary milk with oats in, minus the bits!

If the current event loop task ( you may need to read up on the JS event loop ) was spawned by something like a click event then it is marked as a "user interaction". These tasks can do things like opening a popup window, start audio playback etc. whereas normal tasks are normally blocked from doing this.

It's a clever mechanism but malicious sites tend to just attach a click listener to the page and trigger everything when the user clicks for the first time.

On the other hand it can also be a pain to program around this if you need it. Say you have a webapp that allowed you render an image then display it in a popup. But the rendering is time consuming, so you do asynchronously in the background. The user clicks the button and you start the render. When the render is complete you try and open the popup, but your now in a different task where the popup is blocked. The best way to work around this is to display a modal dialog, saying that the render is complete. Then when the user hits "ok" you can use the task that the event created to display the popup. But it might confuse the user why they need to confirm the render is complete.

The Java edition is the only one that supports mods. Development is parallel between it and the bedrock edition. The windows 10, android, iOS, Xbox one, PS4 and switch versions all use the bedrock edition.

I would recommend starting with a premade mod pack and a YouTube series that's currently using it. Direwolf20 authors his own packs and creates videos using those packs. The twitch client allows you to install various modpacks for Minecraft, including Direwolf20's

I completed the "Tree walking interpreter" section of this book about a month ago, I used modern JS to write it and I found it a really good experience and learned a fair bit. A lot of the content is obviously about implementing the interpreter so there's probably quite a bit that doesn't apply to your project, but

If your looking to make your lexer as simple as possible I would recommend looking at (http://journal.stuffwithstuff.com/2011/03/19/pratt-parsers-e...). It's written by the same guy, and gives a short look on pratt parsers, which is one of the simplest ways to write a parser. There's also a simple language he wrote that uses the method as an example available on GitHub. At a top level you end up with declarations like:

infix(token: "plus", parselet: BinaryOperator, precedence: 13);

Having done a fair bit of prototyping parsers and reading about it the hardest parts of parsing JS are regex literals and automatic semi-colon insertion.