Curiosity Driven

I've seen that previously on https://curiosity-driven.org/ (the main page is a feed file) but I'm not sure if XSLT support won't get deprecated and/or removed in browsers (since it's quite an old tech).

Contracts page on Bitcoin Wiki [0] is classic, unfortunately to understand most of it one has to know how script and various extensions (lock time etc.) work. Generally I'd advise reverse engineering how Bitcoin works, something like this [1] in JavaScript. There is also high level description of some contract types [2] but it's basically the same content as on Bitcoin Wiki. [0]: https://en.bitcoin.it/wiki/Contract [1]: https://curiosity-driven.org/low-level-bitcoin [2]: https://curiosity-driven.org/bitcoin-contracts

Very nice! It reminds me of these two loader experiments: https://curiosity-driven.org/amd-loader-with-promises https://curiosity-driven.org/minimal-loader But for production builds I highly recommend Almond: https://github.com/jrburke/almond

I love creating programming languages! They're powerful tools of abstraction - designed well they make complex concepts look simple. Couple of examples - a language that compiles to Bitcoin script opcodes [0]. Although the Bitcoin script engine is stack based (easier to follow) I couldn't resist designing a small, simple language that could be used to write transaction output scripts. This way it's easy to understand what are the conditions of moving funds to the next owner. Another language has first-class functions, operators as functions, optional lazy computations, but more importantly a small runtime that supports tail-calls and capturing execution as a value (callcc) [1]. I've also written parser and interpreter for Prolog [2], just to get the feeling of logic programming. Writing a small language can make you understand the paradigm (functional, imperative etc.) better and it takes a great deal of effort to decide how should the syntax look like, how will the runtime work (usually with toy languages you provide runtime too...). Edit: Just noticed the "except toy languages" part... :-/ [0]: https://curiosity-driven.org/bitcoin-contracts [1]: https://curiosity-driven.org/continuations [2]: https://curiosity-driven.org/prolog-interpreter

Not only backtracking but also other control flow structures: https://curiosity-driven.org/continuations#flow-structures

This paper [0] (from 2013) linked from this article [1] was also executed on chain, see date here [2] and the actual script via API here [3]. [0]: https://eprint.iacr.org/2013/784 [1]: https://curiosity-driven.org/bitcoin-contracts [2]: https://blockexplorer.com/tx/7ae5760af2105a5ba54a914f188686e2743ead50c… [3]: https://blockexplorer.com/api/tx/7ae5760af2105a5ba54a914f188686e2743ea…

I don't see how this reply addresses the core point, it just argues that async await is useful (that's fine but not novel by itself). It is possible to work around the "color" by using generators [0], that way one algorithm can be used in synchronous and asynchronous way. Async await tightly bind to underlying Promises. [0]: https://curiosity-driven.org/promises-and-generators#decoupling

Here is monads in JavaScript https://curiosity-driven.org/monads-in-javascript

Wow, this is superb educational content.[1] Is the author anonymous? 1. also https://curiosity-driven.org/low-level-bitcoin

I didn't grok anything at first actually. I had familiarity with Prolog and wanted a refresher, so I decided to take a look at implementation attempts done in other languages. I found one which did it in a few lines of Javascript, and you can find the full read and implementation here: https://curiosity-driven.org/prolog-interpreter . My apologies if I didn't make it clear that this is a port of the original write up - I did include this in the first paragraph of the README though, so maybe I should have been clearer? Originally, I was trying to learn Kotlin along with wanting a refresher in Prolog, so I attempted to do the port using Kotlin and gave up half way though. I didn't have the patience to try to grok too many things at once, so I decided to go with Python due to it's simplicity, popularity, as well as the fact that I'm a lot more fluent in it than I am in Kotlin. Anyways - sorry if I'm going off track. To answer your question, I grokked the implementation details through porting / refactoring the original code. The concepts / unification I was already familiar with from taking a university course which involved Prolog and from using it in a large AI project. From what I remember, it took me quite a long time to grasp the language and its power!!