$ npm install firstname.lastname@example.org
Sara demands some attention from her mom. Alissa continues fighting her computer…
This release was made possible thanks to the contributions of @rpearce, @boris-marinov, @justin-calleja, @sotojuan, @degroote22, @RossJHagan, @syaiful6, @diasbruno, @baranovxyz, @floriansimon1, @jreut, and @framp. Really, y’all’re great, and your contributions are greatly appreciated :)
- A standard library for FP
- Release strategy
- API stability
- The roadmap for Folktale
- Functional programming beyond Folktale
A standard library for FP
This release gets at the heart of some of the problems we had with Folktale 1, chiefly the lack of documentation. Sadly, we’re still limited by tooling, so while documentation now exists, there are no cross-references, and it’s hard to navigate. In terms of functionality, the 2.0 release addresses a major pain point of Tasks in the previous version, fixing race problems in the model, and making them easier to use.
The move to a monolithic repo is an attempt to fix some of the consistency problems that the previous libraries had, but also to build a better community around the libraries, and make it easier to use these tools and get help related to them. There’s now a central place to track the evolution and problems of Folktale, and a Twitter account for news on the project. The gitter chat will continue to be used as an additional support channel for the community.
The old Folktale libraries had no release strategy (besides following semver), and the pre-releases of Folktale often broke many features. The new release strategy tries to address these, while allowing experimental releases.
Folktale 2 and beyond will always properly follow semantic versioning. This means that you can always update within a major release (e.g.: from
2.1.0) without having any of the APIs break. Major release updates (e.g.: from
3.0.0) will have a migration guide so you know what you need to change in your code for it to work.
As far as npm releases go, we’ll have two channels:
The stable channel (
@latest) will contain only releases that have been tested for a while. The stable channel updates slowly, but updates are less likely to break things. Stable is the default in npm, so if you run
npm install folktale, that’s what you’re getting.
The experimental channel (
@next) will contain releases directly from the master branch. Because features are developed in feature branches and merged back on master only after they’re finished, this code is relatively stable. The major difference is that these versions will not have been tested on actual production code, by actual users. You can install from the experimental channel by using
npm install folktale@next.
If you install a particular version (
npm install email@example.com), you’ll get that package independently of what channel it’s in.
Along with the different channels, APIs will also have different states of stability. We adopt the same stability index as Node, so APIs may be one of:
experimental— The design of the API is still in the process of being refined and tested. Changes to the API may occur during this proccess. If they happen, the old API will be deprecated, and removed in the next major release. In general you shouldn’t rely on experimental APIs for production code, as the release cycles for major releases may not give you enough time to update your code.
stable— The design of the API was considered good and is finished. Changes to the API are unlikely to happen. If any change happens, the old API will be deprecated, but supported for one year after that. After this period, it’ll be removed from the library.
deprecated— The design of the API was considered bad, and the feature will be removed in the future. Deprecated features should not be used for any new code, and code using deprecated APIs should upgrade as soon as possible (using one of the migration guides that will be provided).
The roadmap for Folktale
There’s a roadmap in the repository that outlines some high-level goals for the next releases. The first thing that will be worked on after this release is moving the library to TypeScript.
With the new additions to the TypeScript type system, most contructs in Folktale can be given reasonable types. The 2.4 release also includes some enhancements on the type inference which are greatly appreciated. All in all, moving to TypeScript means that types can now be used to check if the composition of functional components are correct in your code, with no runtime overhead, and give you useful errors if they’re wrong. Types also help in design and discoverability from a text editor like Visual Studio Code, and better tooling is always a nice thing.
Constructs that can’t be typed in TypeScript right now will end up with a
Once the current features are moved to TypeScript, we’ll add more concurrency structures (CSP channels and Observable streams), and persistent collections (Range, Linked list, Vector, Map, and Set), as well as other common structures for programming in general, and Racket-ish style higher-order contracts.
Functional programming beyond Folktale
You might have noticed the drawing at the top of this blog post. Why, that’s Announcement Number 2!
I have been doing research for a little big project for the past year. The focus is on making resources and tools for CS education more accessible. There’s still a lot that needs to be done, and a lot of challenges to tackle (for example, supporting live programming for a large amount of different programming languages that have not been designed with that in mind).
Besides the technical aspects of Codeland (the
Caneles framework for writing multi-language systems, and the
Pastries image-based IDE), there’s also a social side to it. The materials will feature illustrations and stories from a diverse set of people, including but not limited to race, gender, sexuality, and abilities. That said, my presently limited knowledge of accessible learning materials means there’s a lot of research to be done still.
Anyway! While other characters will be revealed soon (and some of these appear in Folktale’s documentation), here’s the first one.
After graduating from her fashion course things didn’t go very well, and at times she and her wife, Natalie, would struggle to make the ends meet. A situation that wasn’t much improved when their daughter, Sara, was born. A few years later Alissa would end up in one of of those introductory workshops on programming aimed at women, and now that she’s landed a junior developer position on a web development company things are starting to get more stable. Well, at least on the time-and-money side of things.