Posted on

Integrating Google diff-match-patch with AutoMerge.Text

This post outlines the use of Google’s diff-match-patch library to generate patches that can be translated to operations against an AutoMerge.Text CRDT for situations when deriving the operations directly from user interactions is cumbersome.
Continue reading Integrating Google diff-match-patch with AutoMerge.Text

Posted on

Getting productive with selection and navigation in Emacs

This post is intended to primarily benefit people coming from other, so called “modern” editors to Emacs. Emacs veterans are likely to find most of the tips here very elementary.

I have observed that many programmers habituated to newer editors have many implicit assumptions about editing workflows which simply don’t hold true within Emacs environment and this prevents them from being productive to the fullest extent.

This post primarily focusses on how getting familiar with the concept of marks and regions in Emacs can result in productive workflows. These concepts, coupled with a few extensions can enable much more pleasurable code-editing workflows not easily achievable in more prevalent “modern” editors.

Continue reading Getting productive with selection and navigation in Emacs

Posted on

ReasonML vs TypeScript – First impressions

This post summarizes preliminary observations while comparing ReasonML and TypeScript during selection of a reasonably (pun-intended) type safe language for frontend development. The observations here are somewhat biased in favor of experienced javascript developers and focusses primarily on frontend development workflow and does not take into account the (primary) native backend of Reason.

While this post primarily compares Reason and TypeScript, much of what is outlined about TypeScript equally applies to flow as well.

Continue reading ReasonML vs TypeScript – First impressions

Posted on

Typescript and validations at runtime boundaries

Typescript team has explicitly stated that they don’t intend to extend typescript’s static type checking to the runtime.

Typescript Design Goals lists the following in the section on Non-goals:

Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.

While on one hand this design goal is advantageous in that the output generated by typescript is very close to what hand written javascript would have looked like. And the runtime cost of typescript remains close to zero, therefore adoption of typescript does not alter performance characteristics of an application.

However, this also implies that for cases when static typing cannot help us we need to separately write validators using a validation library (eg. Joi) which has to be kept in sync with the typescript types.

This post outlines an approach to eliminate this redundancy using the io-ts library by Giulio Canti. This approach has also been adopted by some other libraries like MobX State Tree and Runtypes.

Continue reading Typescript and validations at runtime boundaries