1. Don't Die

Almost everything else you can come back from except death. I'm using "death" both literally and figuratively to mean the point of no return. First, know the death boundaries, and obsess over the extreme downside scenarios and prioritize survival. Visualize all the ways you could die—all the time. In that way I'm very careful, almost paranoid. I ran Replit for eight years with little commercial success, but at no point did we ever get to the red zone when it came to runway—we always had plenty of cash on hand. You'd be surprised by the number of brilliant founders that reach out to me for advice when they're three months from death.

Once you're deeply familiar with the death conditions, you can take extreme risks because you know you'll always come back when things go sideways. Especially in America, and especially in Silicon Valley, people are forgiving of failure. You can come back from almost anything.

At Replit, there were many times when the business sort of worked and any rational founder would have decided to scale it. For example, we had a decently growing business in education and recruiting, but both markets felt unexciting to me—we couldn't build a big company or achieve our mission that way. So we pivoted. The most recent pivot was from being primarily a coding editor to becoming a natural-language creation interface (vibe coding). Some employees and customers were upset and left (some have since returned), but I knew I had to align with the biggest revolution the world has seen since the internet. When you eventually make it, people won't just forgive you, they'll join you.

2. Never Quit

Everything takes time. Some startups explode from day one and some prodigies play piano at three, but those are rare—and often fleeting. Most sharp rises end in sharper declines. If you've set your mind to something, then why ever quit? If you're not dead, then you're still in the game.

When you talk to entrepreneurs who quit on their dreams, even when they still get massively rich through investing, they always have a look of immense pain in their faces when they tell you that they timed it wrong. That they were too early.

Well, you're only "too early" if you actually quit (or died). They had all the right ideas but stopped short of striking gold. Often, gold is only two strikes away. Don't let that be you.

When you consider quitting, try to find a different scoreboard. Score yourself on something else: on how many times you dust yourself off and get up, or how much incremental progress you make. Almost always, in your business or life, there are things you can make daily progress on that can make you feel like you're still winning. Start compounding.

Some of the best businesses started off slow and just compounded all the way to heaven. One of my favorite charts is Amazon's growth because it's consistent over many years—and it's still compounding. It's really hard to stop companies like this. It's impossible to stop founders like this. So maybe you're not winning on some external scoreboard, but you always have your internal scoreboard to measure yourself and your team on. Have patience.

3. Lock In

I remember doing a spelling bee when I was maybe in third grade, standing in line waiting to get called on to spell the next word. I looked around me and all the other kids were talking and joking around. I thought that was strange. How could you ever win if you're not in the mindset of winning. If you're not locked in?

For me, I would stand there and keep reciting difficult words. And although I was slightly dyslexic, I still won every freaking spelling bee. With this simple trick, I dominated it so much to the point that my teachers, who loathed me for being a slacker, once tried to rig it in favor of their obedient A-students (I still won).

On a day I have to perform, I'm impossible to be around. I'm in the winning mindset. If I can observe how others are doing, I will study their every move. I recently participated and won a timed car race. While waiting, I watched everyone's mistakes and learned from them. By the time I went to do my trial, I knew exactly the bare minimum I needed to do to put myself in a winning position. After you eliminate risk, it's all upside from there.

4. Do Hard Things

Most people do the obvious thing. They don't want to look weird or different—but winning is weird and different. You're definitionally different because you stand apart from everyone else as the ultimate winner.

I used to be a pro gamer, and when my friends and I picked up a new video game, everyone would follow the game's instructions and do the obvious thing. On the other hand, I would explore the edges of the game. I'd explore every weird build, every different weapon, and frankly look like a noob for a long time. That's good. They'll underestimate you. But you're compounding. And eventually, you'll go vertical, creating a massive distance between you and the next participant before they know what hit them.

People by nature take the path of least resistance. If it's working, they'll keep going. Doing hard things means you're going on an untraveled path. It's risky.

When I started working on Replit many years ago, venture capitalists would look at our competitors and see that they were growing faster or making superficially more progress, and they'd ask us "why not just do this or that?" But it was never that simple. I wanted to build real technological depth. Something lasting. If it's easy, then there is no real lasting advantage. It's easy to create the surface thing, but the right (hard) infrastructure technology compounds.

In building a technology company, you're often faced with a strategic decision of whether to build or buy. Every build-or-buy decision should be treated with care, but what's certain is that buying tech is strategically fraught because once you run into the limits of the technology, you can't fundamentally change it. But when you build, you'll be able to adapt a lot faster and find ways to win on the tail events—e.g. valuable yet rare use-cases—that are impossible to handle with an outsourced platform.

For example, at Replit we built a distributed file system to solve the problem of collaborative coding. The easy solution was to buy any one of those services that give you an API to do collaborative editing. Instead, we took the problem one level deeper and built a powerful abstraction. A filesystem where any operation can be reversed, where it can be forked in a fraction of a second, and can be easily stored and backed up. When coding AI agents became possible, we quickly adapted the technology, and now we use this tech to do parallel agents—and as a side effect of concurrency features we were able to build a time-travel feature that's important for reversing destructive agent actions.

5. Play by the Rules

You might think that maximizing risk means you can break the law or do unethical or immoral things. But in my opinion, there's something about the universe that really doesn't reward that. Yes, there are exceptions—there are slimebags that make it really big, and evil companies that maintain a winning position—but those are either the exceptions or their time will come. For the most part, if your competitors are lying, deceiving, or taking unethical shortcuts, it'll only help them in the short term. Don't be tempted to do the same. Stay focused.

Playing by the rules is hard. It's doing the hard thing, and that has the side effect of forcing you to innovate your way out of problems. Those innovations might compound in interesting and weird ways resulting in longterm moats. Think of Apple and how taking privacy and security seriously—despite competing against Microsoft, which didn't care about either at the time—created a lasting consumer trust advantage.

6. Put Something Back

Steve Jobs talked about "putting something back in the pool of human experience." He said that putting something back was "extremely neat"—I agree!

But it's not just neat. It's not just an ethical good, it might also benefit you in the future. Karma seems real. When you put something back into that pool, your reputation will grow, people will be familiar with your work, and they will want to be around you and work for you. Winning can compound by giving back. Win and give to win more later.

I always liked open-sourcing software, sharing my experience, and talking publicly about how I'm building things—in some cases an entire roadmap. For example, Replit Agent was the first fully generative software creator on the market that's accessible to anyone. I shared the roadmap for that in its entirety in a TED talk almost a full year before launch. Our roadmap was public—it still is—but I can't remember a time where that was a disadvantage. Ideas are important, but what's precious is the generating function. The well from which those ideas spring.

With the industrial revolution, we needed ways to coordinate in larger numbers and a more decentralized manner. The assembly line emerged as the basic civilizational primitive of this era. Every node — be it a person, a company, or a nation — was hyper-specialized and produced one thing with a standard interface to handle transactions between nodes. While the hierarchy never disappeared, many aspects of society were remade in the shape of the assembly line. Children go through school one grade at a time, the economy is made of supply chains and consumer-producer pairs, money is printed by the Fed and filtered to the economy through a chain of financial institutions. Even software is built by layering on components on a stack going through different stages and pipelines.

Today, I believe we are going through another major transition: The Information Revolution. While it’s become out of fashion to point this out, it’s undeniable that civilization is being rebuilt. So what is this era’s civilizational primitive? It seems clear to me it’s the network. Unlike the pyramid and the supply chain, the network topology requires less coordination; it’s emergent, self-improving, and self-organizing. The radio, telephone, and the internet are straightforward examples of networks. But if you look deeply, you’ll see that networks are infecting almost everything else: money flows through payment networks (and Bitcoin is bootstrapping money on the network), startups and open-source proved that flatter network-like structures could be a superior way to work, and even software is changing to be built through networks of packages, APIs, and cloud computing. And while schools remain stubbornly unchanged, innovation at the edges resembles a network: kids learn to code and make on networks like Scratch and Replit, and they learn how to solve problems on networks like Synthesis. How will networks change government and politics? Arguably politics is already changed. Today policy is made not top-down but through a decentralized network of universities, think tanks, donors, and politicians. The Network State is an attempt to describe the future of governance.

While the network, like its predecessors, is a neutral tool, I believe it creates a slightly more free world. Strict hierarchies meant that people were stuck in castes and bad luck. The assembly line reduced people to cogs in a giant machine. While the network affords people more freedom to self organize and choose which networks to affiliate with.

• Access to the tool
• Education in the complex skills necessary to use it
• Education in the problem-solving skills necessary to maximize the potential for human progress

At Replit, we’re making computer programming accessible and learnable for anyone, no matter their background, location, or socio-economic status. That covers points 1 and 2, but what about point 3? We need a way to offer any kid from anywhere the opportunity to learn collaboration, critical thinking, and problem-solving so they can capitalize on the promise of computers.

For this reason, I’m pleased to announce that I’m leading along with Balaji Srinivasan a new $12M investment in Synthesis, the innovative education program where kids learn to solve complex problems by playing team games.

I first met Joshua Dahn, the co-founder of Synthesis, when I visited the Ad Astra school on the campus of SpaceX. I had heard they were using Replit to learn to code and build projects, so I visited expecting a regular school. But what I saw was radical. Elon Musk hired Josh to build a lab school for his kids and SpaceX engineers–and what Josh created blew me away. Now, Synthesis is taking the most popular class from that school and scaling it up for kids from across the globe. They designed Synthesis to train supercollaborators, who can work together to solve complex problems to advance human civilization.

Last month, I was hanging out with Chrisman Frank, the CEO of Synthesis. He shared their progress with me, and I couldn’t believe what they had accomplished. They’re teaching thousands of kids the skills needed to move civilization forward. I spoke with Balaji, and we both agreed that we needed to do whatever we could to help Synthesis succeed.

Balaji notes six features that make Synthesis a particular company in his announcement. They bear repeating here:

1. First digital, then physical. A full replacement for the education system will eventually require physical locations. Too many parents depend on state-run schools for childcare. However, it’s important to go digital first, then physical. Synthesis is building a networked community online and then, later, creating physical infrastructure as needed be.
2. Scale what can be scaled. Today’s K-12 instruction can be decoupled into (a) curricula, (b) small group tutoring and (c) de facto childcare. While the tutoring and childcare components will continue requiring hands-on attention for each student, the curricula can be created by world class instructors and cost-effectively scaled to millions of children. That means one could have the polish of a Hollywood movie or an AAA-quality game for educational content, which is what Synthesis is working on.
3. Go direct. Legacy media is incentivized to protect legacy systems. Therefore, companies offering an exit must go direct to customers and build their own distribution. Otherwise, they’ll either get politically attacked or forced to fold back into the values of the incumbent system. And so Synthesis is reaching parents entirely through social media and eschewing legacy media corporations.
4. Make exit easy. Our education systems won’t reform from within. The necessary improvements require too much change. The only real solution is to create something better from the ground up that’s so attractive users can’t help but exit the old system. Something like that doesn't arise overnight - it's proved out in stages, by people gradually opting out of the current system, providing feedback and driving features, till the parallel system is better in all respects and ready for broad adoption. This, too, is part of the Synthesis strategy.
5. Win and help win. Finally, the aim of education should be to train kids to grow the global pie for humanity so all can benefit. In other words, kids need to learn how to work together and succeed in a competitive environment so that they can contribute to the common good. And Synthesis believes that teaching values like this is as important as teaching calculus.

I believe that Replit + Synthesis could become the educational stack for millions of kids worldwide. In the past, kids had to go through K-12 then university education before contributing to the real world, but things are changing fast for a few reasons:

First, the traditional track isn’t available to many people simply because of where they were born. Second, the few who graduate often end up with loads of debt and little to no hirable skills. Third, and most importantly, it seals them off in school for 14+ years and then expects them to offer something productive to society.

Together, Synthesis and Replit are fixing this problem. Synthesis lets any kid anywhere collaborate with peers to practice solving humanity’s toughest challenges, like managing wildfires and colonizing space. Replit empowers these kids to learn code, turn their ideas into real solutions, and build businesses around them online.

No barriers to entry. No unnecessary debt. No more waiting.

In essence, Synthesis is the complement of Replit. To build the future, the next generation needs two critically essential skills. They need to know how to think with computers and collaborate with humans. Replit lets anyone learn the first. Synthesis allows anyone to learn the second. I can’t think of two higher leverage ways to move society forward.

If you have kids ages 8-14, you can sign them up for Synthesis here.

If you’d like to join their team, view their open positions here.

A most fun sandbox

Because the most basic compiler architecture is standard, you have limited boundaries and degrees of freedom when designing one. This might sound restricting, but actually, it's freeing because you get to play in a predictable sandbox.

And because compilers are largely deterministic closed-system problems -- for each input, there is one and only output -- it makes it really fun to iterate on a program without having to worry about external dependencies or a complicated setup. This lends itself nicely to test-driven development -- you can unit-test the component parts and write end-to-end tests for the compiler as a whole.

Writing the test & debugging framework around compilers can also be really fun. To test a parser, for example, you need to run assertions on massive syntax trees, and you need to output helpful failure messages. You can go as far as writing a Domain-Specific testing language to make testing more pleasant.

A most magical flow experience

The most fun I had coding was when I led the JavaScript infrastructure team at Facebook. We were tasked with replacing JSTransform, a string-manipulation-based JavaScript transpiler. Honestly, it's amazing it worked at all, but it didn't work very well. I resided in NYC but went up to our office in Cambridge to work with one other engineer there. However, I ended up mainly working alone, coming in every day for two weeks and writing code for 10 hours a day. I was in a state of flow.

The leading expert on "flow," Csikszentmihályi, identified that for a human to enter a this state, they need to be able to get direct and immediate feedback, for the problem to be well-defined, to have a balance between one's ability level and the challenge, and have a sense of control over the situation. I can't think of a better programming task that hits all those points than writing a compiler.

Useful skills

I joined Yahoo! for my first job out of college, who'd just acquired a company in my hometown. As part of the acquisition, we were tasked with moving to the Yahoo! stack, and they were adamant about us using YUI instead of jQuery. The task fell on my lap, which felt like a crushing mountain of repetitive work.

Like any good (read: lazy) programmer, I decided to automate the task. The task was more intricate than simply a massive search and replace because you had to deal with many variations of names, formatting, and patterns. I'd been learning about compilers and ASTs, and I figured this was an excellent time to deploy my newfound skills.

First, I backfilled into YUI some jQuery-like to make the transition easier. Then I wrote a transformer that took in jQuery code and automatically translated the calls into YUI code.

A many-month project turned into a week project. My colleagues were dumbfounded when they saw the volume of patches flying out of my desk. This is the kind of leverage that compiler technology can give you.

Do it for the art

What do compilers have to do with art? Surprisingly I've found them a great source of inspiration for art projects.

When you look at a program in your editor, you're often able to deduce what the program does from its shape or pattern. Programs have a visual identity; many are beautiful. So if they have a form, wouldn't it make sense to also have a sound?

So how do you make code audible? One way, I thought, is to make running a program sound like something. It wasn't clear how I would do that. A more straightforward idea was to give the syntax tree sound. What does a code block sound like? A statement? A conditional?

I decided to map the sounds from an 808 drum machine to AST node types. Take a listen here, and if you listen to enough programs, I believe you'll be able to identify them in the same way we recognize the shape of a program. You can also toy with the mappings themselves and make them sound differently.

Another art project that I had the pleasure to play a small part in was Qalb, the Arabic programming language. The most fun aspect of the project was not the language or the tooling to which I contributed, but it was the fact that Ramzi, the artist behind the project, showed that you could print programs as Arabic calligraphy tiles.

Finally, I can't talk about compiler art without mentioning DOMQL, a satrical project that add a SQL-like language to the browser and claims it's a better frontend programming experience than JavaScript.

A better coding UX

In my Computers Doing The Right Thing essay, I talked about how we can build more delightful software by detecting user intent. I gave the example of deducing the software packages the programmer wanted to install by from the code, and installing them for the user. This is of course, done by parsing import statements in the respective language. The code for this is open-source -- here is, for example, the Go-based JavaScript parser for that.

To build delightful coding experiences, it helps to master parsers.I'm incredibly excited about the work we're doing with our live game programming environment: Kaboomjs.

Preview of upcoming creative coding magic (and like everything we do, multiplayer). pic.twitter.com/7i4KakNpeW

— Amjad Masad ⠕ (@amasad) December 24, 2021

What Is It Like to Be a Compiler?

As a programmer, you spend much of your day conversing with your compiler. If you're not happy at work, there's a good chance it's because you have a bad relationship with your compiler. Maybe it's too slow, taking you out of the flow state. Perhaps it's giving you inscrutable errors. Or maybe the language has undefined edge-cases, and you don't know what kind of code the compiler is emitting.

All those are reasons to get in and understand how compilers work. Once you do, you'll have a whole new appreciation of programming and how languages are constructed. You'll be able to reason about your programs in new ways, and you can predict how it could go wrong.

I hope this inspires you to design a toy programming language or compiler. Last year, at Replit, we ran a massive programming language jam, and it turned out to be one of the funniest hackathons we ran. It introduced many people to the joy of language design and compiler construction, and I hope to repeat this again in the future.

I think if software designers embraced some of the ideas I'm going to talk about here, computers will be much more delightful to use. We won't need endless pages of menus and buttons. And humans can be free to think about their task as opposed to the software that's doing the task.

DWIM

Interlisp is one of the most fascinating could-have-been computer systems in history. It shipped with one of the first from-the-ground-up interactive programming environments, structured editor, and many other innovations. Most impressive was the concept of Do What I Mean (DWIM).

The most basic DWIM feature is one of spell-correction, but it goes way further than that. It can fix some basic logic errors and even lets the programmer define their own DWIM logic.

From correction to intention

DWIM and other contemporary examples (like Google's "did you mean?") are about correcting user errors. A more advanced and fascinating idea is for the computer to detect intention and act on it. Humans do it all the time; we see the intention in other people and act on it. Like for example making way for someone who's walking towards you.

Software too can and should do basic intention-detection and I'm surprised I don't see it much in the wild. Let's look at examples of how we used it at work.

Intent-based development environment

At Replit, we're really passionate about making a simple yet powerful programming environment. The environment needs to be very intuitive for newbies and should be enjoyable for experts.

The environment always starts with 3-columns, something we've tested and made sure that newbies intuitively get: files, editor, console. That's great, but now what if you want to do web development?

You simply write the code, and the environment will open a new pane to show you the output.

So how does it work? We hook into the Linux Audit system and watch for any new open sockets. In other words, if you start a server we'll assume you want to see the output from it. And in the vast majority of cases, we're right.

Web development is not the only thing people want to do on Replit, many would also like to build games, plot, or boot up old operating systems for fun. In this case, if you wrote the code, or invoked the program that wants to do graphics, we will detect that and stream VNC down to your browser. So how do we do it? Initially, we relied on LD_PRELOAD which allows you to override arbitrary function calls and inject your own logic. Pretty neat and works for other intent-based functionality. However, we decided to move away from that, here is the new approach:

In order to avoid using the LD_PRELOAD trick, we took a page out of systemd's socket activation feature, so that we detect the intent of a repl wanting to communicate with X by opening the socket to the X server, and launch the server + Window Manager at that point in time.

Finally, much of software development today involves open-source packages. However, package manager can be a bit of pain to use, and honestly they can take out of the flow of coding. So while we do have native UI for package management, we also built a system to detect your intent to install an OSS package and simply do it for you.

Intent detection is hard but worth it

As you can see intent-detection required system-level knowledge and hacking. At Replit, we're completely obsessed with creating delightful experiences so we go the extra mile to make it happen. But it's worth recognizing that it's not perfect. Sometimes we get it wrong, and the user can get into a pretty messed-up state.

While complete detection of intent is an AI-complete problem, there are a lot of heuristics that we can apply. Including using modern AI techniques. And software can and should get smarter as more people use it.

I hope this inspires someone to make their software Do The Right Things.

Running a growing business is thrilling. Serving customers is incredible, and growing revenue feels great. But there is only so much excitement in running your average — say b2b — startup.

But suppose your company is doing something so radical it changes culture. In that case, you have to be ready to be surprised, delighted, horrified, and viscously attacked.

In prior eras, a b2b startup founder might've been a skilled trader. Whereas a successful culture-changing founder would've started a revolution or a religion.

When you're challenging norms, you have to be ready to fight the gatekeepers, the useful idiots, and the final boss — the priesthood — those who maintain the status quo.

It's essential to cultivate your community. Provide protected spaces to assemble because existing spaces are hostile to change. Build tools for collective action and encourage solidarity. Build allies wherever you can find them — the outsiders, the weirdos, and the radical thinkers are your best friends.

As a leader, build up stress tolerance. Find habits that clear the mind. Learn how to function with little sleep but take sleep seriously.

In quiet times don't let your guard down. Use those times to train for the next battle. But also celebrate good times and reflect on your victories and losses.

Understand the political milieu. Try not to swim upstream unless it's essential for your mission. Better to ride or entirely circumvent it.

Tell your story. Don't rely on the media machine to tell it for you because, ultimately, they're part of the gatekeeping class. Many are owned by the priesthood.

When building your crew, prefer zealots. It's too risky to have skeptics in your midst. But prize truth, and allow criticism. Build an organization that is both rooted in and unsatisfied with reality.

Enjoy yourself. And remember that quitting is never an option. When it's darkest and most intense, you're closest to victory.

For something to be fake, it can't produce the intended result. It should be counterfeit. But hyperreal is the opposite. To make a hyperreal object from a real one, take only the details that excite the mind — like getting praise — intensify them, and drop everything else. When you reduce food to its most intense elements — sweet & salt — you get hyperreal (junk) food. That is the formula for hyperreality.

Hyperreality is exciting, but too much of it is destructive to humans. It takes us out of our natural flow and makes us into addicts. Now you might object with something like "everything in moderation," which is trite and true. But be prepared to fight the modern technological system optimized to produce hyperreality.

You might blame "capitalism" for working against our better angels. It is, after all, very efficient at producing hyperreality. But you'd be wrong because humans have been making hyperreality since cave drawings.

Communism produces hyperreality too. It is hyperreality. It takes a naturally occurring thing — family and community — and intensifies its most attractive elements. It's an intoxicating hyperreal vision.

Are we doomed to eternal hyperreality addiction? It is a potential answer to Fermi's Paradox. Intelligent life evolves until all it does is produce and consume hyperreality at the expense of exploring the stars.

I don't think we're doomed though. And I don't think regulation is the answer either. Religions have dealt with the destructive nature of hyperreality. Why do you think you can't draw pictures of people or animals in Islam? A restriction that generated an art culture rooted in abstract (unreal) shapes.

The secular West is especially vulnerable to hyperrealism because societal norms that could protect us are considered oppressive. I love the West's renegade aspect. It resulted in innovative art, science, and technology. But it left us unprotected against hyperreality.

Whatever comes next — may be a techno-futurist religion — needs to address this issue.

This idea is not too far from how we used to make websites in the 90s and early 2000s. You wrote your code and FTP'd it into remote server and restart the webserver process to pick up the changes. Today, most people do it by git-pushing to a PaaS provider. I've been hosting apps, sites, bots, and microservices from my editor for the last two years, and in this post, I'll share my experience. While I've been doing in Replit, where it collapses your entire workflow into your code -- a code-first environment -- the following applies to anyone who's hosting code directly from where they wrote it.

When writing code, the development environment feels closest to you. It's where you are making the changes and seeing your creation come to life. After coding, in a typical workflow, you push up your code for storage and sharing (to something like GitHub). If your changes are ready to release, you'll also push them to a hosting provider (say Heroku). Here is a diagram of it:

The moment you send your code to a remote environment, you've created distance between you and your creation. It's living in a different environment where it's not easy to inspect and update. You've fragmented your workflow and now have two other locations where your code lives, and while git is great and maintaining copies of code, you've introduced multiple potential sources of truth.

This destroys momentum especially for early-stage startups, side-projects, and those who are learning to code. Sadly, the "industry standard" often gets applied indiscriminately, robbing people of a superior mode of creation and all the fun and reward that comes with it.

The alternative:

When hosting from your editor, you're moving fast, updating the site and seeing crashes and debugging issues in realtime. For example, in Replit, I can enter the production repl and see active connections, inspect, and even hot-update live objects.

I was wondering if the app is already getting usage and one of the wonderful things about hosting on @Replit is getting a live repl on the hosted app.

Here I just got a reference to the db and listed the entries. pic.twitter.com/UIoERFc50D

— Amjad Masad ⠕ (@amasad) November 26, 2020

Having a production repl is super valuable. Paul Graham recounts how he used the Hacker News prod repl to react to an issue from his phone:

I once had to write code on a phone, after HN mistook investor usage on Demo Day for a DDoS attempt and started ignoring the venue's IP address. I had to log into HN on a phone and paste a fix into the repl. This looks a lot more civilized.

— Paul Graham (@paulg) April 28, 2020

Another issue I've run into with today's standard workflow is projects going stale. After leaving a project for a few months the barrier to going back to hacking feels high: I'd have to pull, set up the dev environment again, and figure out how the hosting provider is configured. However, when hosting from my editor, I open up the project, and I'm right there hacking and "deploying."

Because the distance from creation is reduced, I also start (and complete) many more projects. I'm quick to spin up something or to automate a piece of work. At work, because Replit feels close and fast, we spin up many bots to automate tedious tasks or introduce fun and serendipity.

Finally, in cases of emergency, it also helps to be able to code live. We've been able to respond to emergencies at breakneck speed. For example, a few months ago PyPi quitely deprecated their package search API which we use in our packager UI. Luckily, we found a package that searches PyPi via scraping the site. We spun up an alternative on Replit in 30 minutes:

Multiplayer @replit story:

3rd party service deprecated w/ no warning 😱

I spun up a repl with and prototyped replacement ⚡️

Single-threaded couldn't handle 1 rps 😢

Someone jumps in w/ uwsgi now we're at 3 rps 💆🏽‍♀️

Dropped in LRU and now we're up to 50 rps 📈

Good—Shipit!

— Amjad Masad ⠕ (@amasad) December 19, 2020

I'd like to see the dev community introduce more fun and interactivity back into building, especially when teaching new devs how to code. Most bootcamps today spend their first weeks teaching people git. But their students have no mental model for version control to be able to grok git, so it just starts on the wrong foot with people feeling inadequate or dumb for not "getting it."

Seymour Papert called this the "project/problem inversion". The natural way to acquire knowledge of new tools is to have the use-case for them; today new developers are taught to cargo-cult advanced development techniques before they've even finished learning how to code.

Across all my work -- the millions of developers we helped mint, the CS teachers we empowered, and the entrepreneurs we enabled -- I've probably had a significant impact on the world economy, perhaps even meaningfully increased productivity.

Reflecting on this, first, I'm grateful to be able to be useful on such a large scale. After all, just ten years ago, I was a kid in Amman who'd just graduated from university and was interviewing at random companies (including a cigarette factory for VB6 work that comes with a free carton of cigarettes a week).

Second, and more importantly, I think it's time to be more ambitious. With every project, I stopped short of what was possible. I let haters & doubters change my plans and assumed a sense of fake humility because that's what people expected.

The culmination of my work is Replit, where we're working to give people computer superpowers. We want to nudge the world away from rampant digital consumption to one where there are more creators and entrepreneurs. Anyone anywhere can participate in the digital economy and build and leverage software to better themselves and their communities.

Now that I've seen what's possible in a decade while starting from nothing, in this decade, I'd like to create trillions of dollars in value for the world in the form of better access to technology and tools.

My only regret is my mum is not here to see all this.

Replit gets its name from "REPL", the Read Eval Print Loop, a basic language tool found in most modern programming languages and environments -- a tool that allows you to interact with a program by reading, evaluating, and printing data.

If you imagine development environments as a continuum from REPL to IDE, you can see how Replit is located closer to the REPL end. A tool for rapidly validating concepts and exploring ideas.

Replit is a ultimately a reaction to the modern software development grind, where many developers spend their time waiting for builds, running tests, fighting with linters, and configuring frameworks. It's an attempt to get back to the basics of programming -- to make coding fun again.

We aim to collapse the entire development lifecycle into a simple interface: write the code, 1-click, and it's live! With Multiplayer, you can even do all this with other people in real-time.

[1]: It's unfortunately how we currently describe Replit on the marketing pages, which was necessary when Replit was unknown. However, this will change soon.

At Tiny we're scaling really quickly. Our platform allows tens of thousands of developers to instantly provision a running test environment in a few clicks. This creates a huge amount of data which is stored on a MongoDB cluster hosted on Google Compute Engine.

A few months ago we started noticing some serious performance problems. The database was not able to handle the query load. We had all of our database configuration on auto-pilot so it took us a while to realize we had a problem. After a few weeks of investigation it became obvious that MongoDB was not the right choice for us and we decided to make the switch to Postgres.

Why We Chose Postgres

Postgres has been around since the dawn of the web, and is more battle tested than any other database. It has very fast performance, is open source, and runs on a wide range of platforms.

MongoDB has very flexible schema and is a great choice for dynamic applications. When we initially started developing our service, the schema was very flexible. Since we allow users to provision an environment in a few clicks, the data model changed from one environment to the next. This was not a problem for MongoDB. With time we became more strict in our schema and users started having a more consistent data structure, but this was now against MongoDB's strengths and caused us a lot of performance problems.

Postgres on the other hand has a more rigid schema. There is no auto-sharding. The database servers have to be the right size. And the sharding is much more involved to setup. There are however many open source tools that can help you monitor, optimize and scale your Postgres cluster. There are also more resources online to help you migrate from one database to another.

Moving to Postgres was actually very easy. All we had to do was install a few packages.

apt-get install postgresql postgresql-contrib postgresql-client

We had to make a few changes to our code so that it would work with Postgres' strict schema.

We added a schema field to every model. This is important since Postgres cannot automatically detect the structure of the data.

class DataContainer < ActiveRecord::Base attribute :schema , :string attribute :data , :text , default: "" end

We have to explicitly define the length and format of each text field.

class DataContainer < ActiveRecord::Base attribute :data , :text , default: "" attribute :content , :text , default: "text" , size: 25 .chars end

Some Mongoid extensions won't work with Postgres. To convert these fields we used the ruby2ruby gem.

"Postgres extension for mongoid/mongo_mapper" .split( "::" ).each do |component| mongo_model = component.split( "::" ).first module Mongo end Mongoid::Document.extensions.each do |extension| if extension.start_with?( "Mongoid::Extension::" ) mongo_model_ext = extension.split( "::" ).first mongo_ext = module Mongoid::Document module Extension mongo_model_ext.split( "::" ).each do |component| mongo_ext.split( "::" ).each do |component| mongo_ext.split( "::" ).each do |component| mongo_ext.split( "::" ).each do |component| mongo_ext.split( "::" ).each do |component| if component.include?( '-is-extended-type' ) && component.split( "-" ).last == "ruby2ruby" include component.split( "-" ).last else puts "Ignoring #{component} in mongo_extension" end end end end end end end end end end end end end end end

Adding indexes to a Postgres database is also very easy. We use data containers which contain several documents. We needed to index them by schema and id. Here's how you can create a partial index.

rails g index add_to_container_data_schema_id

class AddToContainerIndex < ActiveRecord::Migration def up add_index :containers, :schema, :unique: true add_index :containers, :id, :unique: true end def down remove_index :containers, :id remove_index :containers, :schema end end

We also need to initialize the connection with the database, otherwise Rails will try to connect to the production database.

# config/database.yml production: adapter: postgresql encoding: unicode database: <%= ENV['TINY_APP_DB_NAME'] %> # db/structure.sql # <% db_name = ENV['TINY_APP_DB_NAME'] %> # db/seeds.rb class AddToContainerData < ActiveRecord::Migration def up execute <<-SQL CREATE TEMP TABLE containers ( id SERIAL PRIMARY KEY , schema VARCHAR( 100 ) NOT NULL , content TEXT NOT NULL , FOREIGN KEY (schema) REFERENCES schema_fields(schema) ); SQL execute <<-SQL CREATE UNIQUE INDEX containers_schema_id ON containers(schema); CREATE INDEX containers_id ON containers(id); SQL end def down execute <<-SQL DROP TEMP TABLE containers; SQL execute <<-SQL DROP INDEX containers_schema_id; DROP INDEX containers_id; SQL end end

Don't forget to add the migrations to the git repository.

$ git add db/migrate 
$ git commit -m "Adding Postgres support to the containers"
$ git push

Running our tests on Postgres took a little bit more time than running on MongoDB. It's not a lot more though. I believe this is because our test environment has to process more requests. The performance on the production server was also better than Mongo.

The last step we took was to set up monitoring for our Postgres cluster. We set up simple scripts that runs inside a cron job to collect data and store it in a database.

We're looking for smart developers. Hackers apply here!

Life is also a form of self storytelling. We're continually retelling ourselves our life story, but very few people think of themselves as authors of their story, not mere subjects. People with extraordinary high-agency realize this early in life and start maximizing the interestingness of their life story.

Having a fascinating life story is not just an exercise in vanity -- it has a real impact on your success in life. You'll have an easier time attracting friends as well as life and business partners. It'll also make it much easier to sell yourself or your products. It has a kind of compounding halo effect.

Startups also have to be good stories. A good business idea or market is not enough to endure the pain and have the motivation to get a startup off the ground. Without an interesting story about the founding of the company and the vision, you'll have a hard time attracting talent and money. Notice how the most successful startups in the world all have remarkable genesis stories.

So next time you're faced with a tough decision, consider the path that makes a more interesting story. If it turned out to be the wrong decision to have made, you'd at least be fun at dinner parties.

Most of the commentary on his work is focused on the technical achievements and the impressive feats of engineering that's genuinely 50 years ahead of its time. Just this week we, at Repl.it, we introduced Multiplayer -- the ability to code together with anyone in the world -- and although we have the benefits of modern tooling and infrastructure it was still hard work

A more interesting question to ask would be: "What's Douglas Englebart's generation function?" In other words, what ideas, themes, and philosophies that have inspired his groundbreaking work?

I didn't have much time to work with, so I had to go mostly of off memory -- this question requires a more in-depth examination. However, I've identified three themes that are worth studying.

Computers as mind extenders

Engelbart and his contemporaries saw computers as first and foremost tools for mind extension. Something we can use to augment our intellect to take on more and do more.

"By augmenting human intellect we mean increasing the capability of man to approach complex problem situation to gain comprehension to suit his particular needs and to derive solutions to problems. Increased capability in this respect is taken to mean mixture of the following: more rapid comprehension, better comprehension, the possibility of gaining useful degree of comprehension in situation that previously was too complex, speedier solutions, better solutions and the possibility of finding solutions to problems that before seemed insoluble." -- Augmenting Human Intellect

This sits in stark contrast to today's computers as the driver for the attention economy. Where computers as seen as entertainment devices at best. A more cynical reading of the way governments and ad-based businesses use computers would lead you to believe they're devices of control.

Evolutionary design

To understand Engelbart it's important to not view him as a lone inventor genius a la Tesla that predicted what computers could do 50 years ahead of his time. In his own words you can see that they took a much more exciting approach to discovery:

"We're pursuing this monstrous goal by building and trying empirically -- we approach evolutionary-wise because we feel it's a whole system problem [...] it's much more than these computer tools"

Bootstrapping

"Bootstrapping" is another recurring theme in Engelbart's work. I think of it as "increasing returns":

• You build tools, and then the tools you built helps you create better tools.
• Tools make you smarter, and you make better tools that make you smarter... ad nauseam.
• Tools increase productivity which makes us wealthier which in turn allows us to invest in more and better tools.

Conclusion

It's worth noting that what seemed to drive Engelbart was his concern for the unique challenges an exponentially changing world brings. He believed that "boosting Collective IQ" is imperative for the flourishing of humanity.

In Silicon Valley, at least in my circles, there's a general feeling that we need to return to the thinking of computers as "bicycles for the mind." And I hope we do.

Thanks to Figma and Dylan Field for inviting me to reflect on this awesome day.

The classic example of this is the astonishing adoption of mobile in Africa especially relative to landline:

Sometime last year we discovered that some users use Repl.it -- an online REPL and development platform -- as their primary programming tool. This seems surprising at first: other than for learning, why would anyone use a more limited tool over a more mature and flexible one?

It turns out this was the wrong question to ask. A better one would be: "if someone had already learned to code on an online REPL and it serves their needs then why would they want to invest in a local setup?". Because they'd started with Repl.it, they need a compelling reason to install an IDE locally and possibly have to invest in buying a more expensive device (say from a Chromebook to a Mac).

In fact, this is the exact question our users are asking: why do I have to switch?

This way of formulating questions better explains the leapfrogging phenomenon in general: "why do I have to invest in a PC if my tablet/mobile handles all my computing needs?," "why do I need a credit-card if I can just use my mobile payment wallet?" etc.

In our experience, even the people that make the switch are often dissatisfied with the result -- wishing VSCode worked just like Repl.it:

With programmers growing up today being used to instant, interactive, globally accessible programming tools like Repl.it, Jupyter Notebooks, serverless (pay-as-you-go) compute, and others, it doesn't seem so outlandish to imagine a post-IDE world.

_This blog is built and hosted with Repl.it: amasad.me/__repl

The more abstract a subject is, the easier it is to reason about and therefore make progress on. That's why we've made a lot more progress in math and physics than any other subject. The problem became more salient recently as some of the perceived scientific progress made in the less pure sciences -- psychology, medicine, economics -- is being nullified in a widespread "replication crisis" where many scientific studies are failing to reproduce.

One way to get more abstract is to take the meta view of a subject. Programming Language Theory (PLT), for example, is the study of programming languages and their features and characteristics. While a lot of progress has been made in PLT, rarely does this translates into features in languages used in the real world. There's often decades-long gap for some form of a PLT idea to make to the industry because programming is messy and complicated and full of human problems that PLT researchers don't bother studying.

I have a lot more respect for people who stick to the base game, avoiding getting sucked into the much more comfortable metagame. While we need researchers and scientists to go meta, they should remain tethered to the base-game and work closely with practitioners.

I've first noticed this problem in the startup world where you see famous people that sell books, talk at conferences, and tweet advice to founders, but when you take a closer look, they've never done much founding themselves. They're like the "entrepreneurship" professor that never built a business. They're experts in the metagame -- they're polished speakers, engaging writers, and thought-leadering tweeters. The problem, though, is that they're not judged by customers, the market, or nature, instead they're judged by their peers. I call them metapreneurs.

This is an instance of what Nassim Taleb calls "The Expert Problem" -- when other experts and meta-experts judge experts. Eventually the lack of contact with reality will corrupt the field. In the sciences, that lead to the replication crisis and the absurdities of the humanities.

If you find yourself going to a lot of conferences, opining too much on the latest fad in your field, and talking more about doing the thing than doing the job itself, then you, my friend, are getting sucked into the metagame.

When my father came back to Jordan, he worked for the government as an engineer. There, he faced discrimination because government jobs were typically reserved for natives. Despite all this, he rose in the ranks for years until he became the city manager of Amman, the capital of Jordan. My father's journey taught me that as someone who's underprivileged or discriminated against you need to work ten times harder than the next person to get ahead. You need to leverage whatever tool you have to signal that you're great at your job. For him, it was his reputation. In a country ravaged by corruption my father had a reputation for being so straight it baffled people (but it also meant that we wouldn't get to see any of that corruption money, and we had to grow up on a measly government salary).

Which brings me to the recent debate in the developer community on using GitHub as a résumé. While I try to stay away from debating hot topics because it takes time to form an informed opinion, this was a subject that's near and dear to my heart, so I had to write about it.

It all started with this tweet claiming that GitHub is the only way that employers can validate talent.

10/ GitHub is the de facto source for validating top talent the world over.

Résumé or CV?

Please.

Show me your GitHub profile, commits you've landed, projects you've forked, code you've released.

— Joe McCann (@joemccann) June 7, 2018

While I disagree with this statement, I found myself also disagreeing with people on the other side of the debate which, in my opinion, are also staking out an extreme position. They're saying that GitHub is not only a "useless signal" but is also discriminatory by nature. (I found myself agreeing more with moderate positions like Kim's here saying that basically, employers are shooting themselves in the foot by excluding people with no GitHub profiles).

Starting with the assumption that employers would want to hire the best candidates for the job[1], we can observe that they're merely trying to navigate the problem of "adverse selection," which occurs in any market where there exists an asymmetry of information. Because candidates can deceptively spruce up their resumes and maybe even rise in the corporate ladder by being gifted at office politics, and because most good programmers are not in the job market (they either have a job or get headhunted before they enter the market), this leaves employers in a tricky position with an insufficient set of tools to evaluate candidates (see The Market for Lemons for an interesting discussion on adverse selection). GitHub, on the other hand, cuts through the bullshit (for the most part).

You can fake a resume, or end up with a good one simply as a function of your privilege. For example, if you're born into wealth, your parents can probably call in favors to get you jobs at prestigious companies. But can you really fake GitHub profile? It's tough to do so, and that's because the "screening", as it were, is done by OSS maintainers. You can't bullshit your way into getting pull requests landed. And no matter your parent's standing in society, if your code stinks, you can't contribute. This makes GitHub a precious tool for recruiters.

Because open-source is good at cutting through the bullshit, it also makes it an equalizer. If you come from an underprivileged background, you should absolutely use GitHub to get ahead. That's exactly what I did. I owe my entire career to open-source.

Back in college, I didn't have a personal computer, and I was always on the move -- from campus to the office, to home. Which made it tough to code on projects, or solve homework because every time I got my hands on a computer, I needed to setup the development environment. So I started dreaming about a world where I can open a browser tab and start coding, in any language, anywhere. Which started a multi-year project to build an in-browser repl. The first thing I did was put a textarea with a button that evald JavaScript. I was able to program on my Nokia phone and work on problems on the go. But I wanted this experience to be better and to work for more languages.

Long story short, years after I had the idea for an online repl was I able, with help from friends, to build the first polyglot in-browser repl along with a web terminal implementation. I tried to start a company around this idea, but nobody would fund me. Luckily, everything was open-source on GitHub and soon after we released the project I saw that not only one, or two, but more than a dozen companies in Silicon Valley started using our software.

Although I had applied so many times to work at Google, Facebook, and many others, I never got a response back, let alone an interview. Open-source became my ticket there. I joined Codecademy as the #1 employee and helped 10s of millions of people to learn how to code.

Afterward, I joined Facebook to try and work at the team behind React.js. But I was stuck working on the photos product (which I couldn't care less for) because the React team was one of the hottest teams at the company. So I started contributing to their open-source projects. I know it sounds crazy and roundabout, but I was able to prove myself more via my GitHub contributions than my day job. I think that played a big part in letting me in the team where I worked on React Native.

Today, I'm trying to pay it forward. At my new company, Repl.it, we believe that programming is a great equalizer. We've seen our product used by refugees to learn how to code. By people to upgrade their careers and land tech jobs and to teach low-income high-achieving children how to code. Or by homeless people who only have access to computers at the public library. At this point, we've heard enough "rags to riches" stories in programming that it becomes difficult to dismiss this as simply "survivorship bias".

To conclude: if you come from an underprivileged background then the unfortunate reality of the situation is that you're going to have to work harder than everyone else. And you're going to want to use any tool at your disposal, like Github, to signal that you're you going to be great at your job so you can land great jobs.

If you need advice, I'd be happy to help, my DM are open on twitter.

[1]: It's still a safe assumption to start with, even if it's not entirely accurate. Even if you believe that bigotry (or unconscious bias) plays a big part in excluding people, I think that from a first-person point of view, you can't control that. For example, it's hard for me as an individual Muslim to change the fact that some people hate Muslims, so it's better for me to focus my energy on things that I can control. This, however, doesn't mean that as a society we shouldn't discuss issues of discrimination.

"We are going to die, and that makes us the lucky ones" said Richard Dawkins, talking about how lucky we are to be the ones that got to live for "the potential people who could have been here in my place but who will in fact never see the light of day outnumber the sand grains of Arabia". Meditate on that, and when you feel those words, no matter what your misfortune is, you'll know that you're damn lucky to be alive.

In the story, Candide: Optimism, a philosopher named Pangloss believed that we live in the best of all possible worlds. And despite the deep misfortune visited upon him–enslavement, torture, earthquakes, and more–Pangloss maintained his belief that he lives in the best of all possible worlds. While the story is ridiculing this type of thinking, I think there's something to be learned from Pangloss. We may not be living in the best of all possible worlds, but I can certainly imagine far worse worlds than I can imagine better ones. Maybe that's because we humans are wired to fear the worst so we can survive the world. But the flipside is that you can be deeply grateful for living in a world where your deepest fears are not reality.

So I'm thankful. Starting with my peaceful upbringing, I'm beholden to my parents and my grandparents who left war-ravaged countries to move to an island of peace among total and utter nihilistic destruction. I grew up in an intellectually and physically stimulating environment. And for that, I'm grateful to my friends, teachers, and peers. I'm thankful for my hometown, the place where I found love–a woman that believed in me and pushed me to my limits and beyond.

However, I chose to leave to follow in the footsteps of my heroes. To the place where pioneers, inventors, and visionaries imagined and built a world where humans can transcend their limitations. Extended by technology, we're evolving into something new and beautiful. I'm grateful to the country that took me in, the industry that let me follow my dreams, and the people that took a bet on me.

Yes, I know I'm lucky, and that's precisely why I'm thankful. But I also believe in progress. I think that we–all of us, all of humanity–are going somewhere, somewhere beautiful. So be thankful; be thankful for every moment you're alive. And if you're also one of the lucky ones, you have a responsibility to make the world a little better for everyone else.

Thank you for reading this.

Would you pay $5 to participate in a lottery that offers a 10% chance to win $100 and a 90% chance to win nothing?

Chances are the second proposition sounded more appealing to you. But look again, both these propositions are identical. The second version attracts more positive answers[1] because it's framed as cost whereas the first version is framed as a loss and who wants to lose?

This is called "framing effects," how something is presented colors how we think about it. Similarly how we interpret the world around us and our situation in it would affect how we feel and act. In fact, there are whole branches of psychotherapy that focus on the art of viewing things differently: "positive reframing", "cognitive reframing", and "cognitive restructuring". However, what I'd like to focus on is dealing with specific set issues, issues that have to do with creating something new in the world, building a business, and all the turmoil that brings.

When you're a startup founder, it's almost like your mood is tied to your metrics. When your company is doing well, you feel great. When your company isn't doing so hot, you're feeling bad. This, in turn, will affect your productivity and may set you on a vicious cycle of doom where your company isn't doing well, and you don't have the energy to fix it.

So how do you escape this, deal with the stress, take action on it, and have some fun doing it? Well, we can exploit the mental bug that is "framing effects" to bring about a better state of mind. I'll introduce what I call "mental frames"[2] -- I'm not sure if that's a real technical term, but it sounded good to my ears -- that has helped and continues to help me get through tough times.

Before I start, I want to acknowledge that it feels kind of silly that we have to trick ourselves and tell ourselves stories to act the way that we want to act. The reason we have to do this is that more and more we're discovering that we're not just one self, we're multiple ones. Scientists and philosophers, in different contexts, have proposed various theories on the division of the self. There is the momentary vs. the narrating self; there is System 1 vs. System 2; there is the left vs. the right hemisphere; there is the lizard brain vs. the neocortex. All that goes to show that although there is a part of your self that wants to get better at managing your mental states -- the one that's reading this, hi! -- it doesn't automatically mean that all your selves are onboard. So join me on a journey to trick these bastards to do what you want.

Also, I'm not a mental health specialist, see one if you need to.

"Life is a game" mental frame

Once a motherfucker get an understandin' on the game, and what the levels and the rules of the game is, then the world ain't no trick no more, the world is a game to be played.

-- 2Pac in "Starin' Through My Rear View"

Part of the startup game is taking risks, in fact, it's almost the only game in town. If you're not taking risks, then your startup already exists, and you're just copying something else. But if you are creating something new in the world there wouldn't be a week that goes by without feeling anxiety about all the risk that you're taking. Be it your career, other people's times and money, or with your product, users, etc.

The risk anxiety can paralyze you and unless you act you're just making your situation worse. One handy mental frame to adopt in this case is "life is a game, and I'm playing it." If life is a game, then you're there to play it. When you're, for example, playing a video game, although you stop to weigh the pros and cons of every decision you make, in the end, you have to act. Otherwise, nothing will happen, and it's no fun. You'll happily jump from place to place, explore different areas, try different combinations of keys or moves. You're never standing still, always making decisions and executing, learning, failing, restarting and going again.

The "life is a game" mental frame puts you in a fun frame of mind. You just can't wait to see what happens next. Maybe you'll lose, perhaps you'll win -- who cares! As long as it's interesting, keeps you amused, engaged, and learning.

"Time keeps moving forward" mental frame

I was a little bit of a procrastinator and I would be faced with this seemingly insurmountable task. I have final exams, I have massive amounts of work, papers -- there is no way to make it through. At that time -- and this is served me well -- I would say 'well, one way or another time keeps moving forward so even though I'm just three weeks away, whatever happens in three weeks from now I'll be on the other side'. So it seems like a wall that I can't get through but actually time is marching ahead and I will get to that point past that thing automatically and that was helpful to me.

-- Siri, Change.org, and Viv founder Adam Cheyer on the "Finding Mastery" podcast.

When you have an upcoming deadline or a significant date of somesort -- be it a product launch, scoring a deal, hiring someone, or the end of your runway -- there is no real rational reason to feel anxious. All you have to do is perform your best, and the rest is outside your control.

In situations where it's painful, you have to remember that time will go by, nothing lasts forever, and that you'll eventually be on the other side. What's important now is to execute!

"Worst-case scenario" mental frame

You might've used this one before; it's kind of a cliche that's often used out of place: "order the pizza, worst-case scenario we'll eat it in the car" or some such thing.

When correctly used, it can be compelling. Right now, think about a difficult situation in your life, or a tough decision you're pondering, or a risky move you're considering. Now think about the absolute worst thing that can happen as a result of your actions -- like literally the worst thing:

1. Will someone die?
2. Will someone get seriously injured?
3. Will you become homeless and starve on the streets?
4. Will you lose your house/job/car?
5. Will you tarnish your reputation?
6. Will you fail at the startup thing and go back a to a cushy job where they feed and do your laundry?

Etc. Barring #1, #2, and #3 I think everything else can be tolerated. Honestly for most decisions at Silicon Valley startups that may lead to ruin, it's probably going to be #5 that ends up being the worst-case scenario, and you know it's not all that bad.

A excellent technique to couple with the worst-case scenario mental frame is what's called "negative visualization". An age-old technique invented by the Stoics in ancient Greece, you visualize or meditate on the worst. Like, actually imagine it happening. If it does happen, you're already at peace with it, and if good or neutral thing happens then it's ecstatic!

"You're not your job" mental frame

"Founder of [insert sexy startup name]" is what you have on your twitter bio. It seems like this thing is intricately intertwined with your identity. But in reality, you're a lot more than that. You might be a good husband/father/son. You might be a good thinker, writer, or educator. Or you might have hobbies that you're good at.

When failure strikes, you might feel that you, personally you, are a failure -- which is basically depression. When that happens, remind yourself that you're much more than your job -- that you contain multitudes.

It's good to cultivate other interests, hobbies, or anything that you can get good at. Have people that rely on you outside of your work. Mentor someone. Learn a new skill. Find a hobby. Whatever you do try to link it to your identity.

For me, I try to always have someone that I'm mentoring. I read, discuss, and dabble in doing philosophy. I'm currently obsessed with weight-lifting. I also like to get better at writing, public speaking, and storytelling. I love to optimize my health. This year I spent a lot of time enhancing my sleep. Going from an average 5 hours a night to 7.5 hours a night. I also increased my REM sleep, going from less than an hour to 1.5-2.5 hours.

"What did I learn" mental frame

If you're the kind of type A personality that would choose the entrepreneurial path then chances are, you like self-improvement, and chances are, you love learning. So when failure does catch up with you then do yourself a favor and think about everything that you've learned from your experience. Maybe even write about it but, at all costs, avoid titling your post "our wonderful journey."

There is a lot more to this, and I'll try to keep this as a live document. But for now, I need to get back to playing the life game because time won't wait for me, and really, what's the worst that can happen? I want you to remember though, that I'm not only my job, it's true that I learn a lot from it, but I contain multitudes!

[1] Kahneman, Daniel. Thinking, Fast and Slow (p. 364). Farrar, Straus and Giroux. Kindle Edition.

But how does progress happen in programming? Sometimes it looks like it's an arbitrary walk in the space of possible languages, frameworks and architectures. I'd like to propose an answer: programming progresses in dialectical fashion. Meaning what usually follows the current best practices and technologies is an opposite in many ways. However, this is usually followed by a synthesis of these two opposites. In other words, a compromise or a best of both worlds.

We can think of this as a thesis, antithesis, synthesis:

(1) a beginning proposition called a thesis, (2) a negation of that thesis called the antithesis, and (3) a synthesis whereby the two conflicting ideas are reconciled to form a new proposition.

Let's look at some examples.

Languages: industrial strength vs developer friendliness

1. Thesis: industrial strength programming languages. Languages like Java and C++ are type-safe, efficient and work well with large systems. But they're also hard, boring, noisy, and take a long time to compile.

2. Antithesis: developer friendly languages. Languages like JavaScript, Python, and Ruby are dynamically typed so the syntax is clean and less noisy. They're interpreted so there is no compiler to wait for. And they're fun and arguably more productive to work with.

3. Synthesis: developer friendly and suitable for large scale programming. Languages like Go, Rust, and TypeScript are both type-safe, efficient and work well at large scales.

Web rendering: server-rendered vs client-rendered pages

1. Thesis: server-rendered pages. Languages and frameworks powering Web 2.0 like PHP and Ruby on Rails can get you to market quickly, with predictable performance, and works well with the rest of the web infrastructure (links, search engines etc).

2. Antithesis: client-side rendered pages. Frameworks like Backbone, React, and Angular can create delightful user experiences. But they break the web's protocol (hypertext over TCP) and can be slow to boot up.

3. Synthesis: universal rendering. Frameworks like Next.js bring us the best of both worlds: a great user experience, great initial render time, and great support for search engines and other web infrastructure.

Mobile apps: native vs web

1. Thesis: web applications. Web 2.0 unleashed the power of the internet and brought us amazing applications like social networking and YouTube. But when mobile came around, using web tech to build mobile apps created monstrosities like the first Facebook HTML5 app.

2. Antithesis: native applications. Native applications brought much better user-experience with gesture support, smooth scrolling, and access to APIs like location and notifications. However, a lot of progress that we made in engineering (e.g. continuous deployment, cross-platform development) or in application distribution (just visit a URL) had to be thrown away.

3. Synthesis: progressive web apps and web tech adapted to native. PWAs and frameworks like React Native bring us the best of both worlds. Access to native (or native-like) APIs and a great user experience but also cross-platform development, continues deployment and better application distribution strategies.

Conclusion

This framework of thinking about progress in programming seems to apply to a lot of what I see happening in programming. There are ongoing developments that I look forward to seeing the synthesis of:

• Web development build tools: we started out writing and loading scripts in the browser verbatim but applications getting more complicated lead us to build better languages and frameworks which lead us to introduce ever more complicated build-steps to our web developement and deployment pipelines. However, with browser vendors moving faster on supporting language features and with framework authors acknowledging the problem I think we're going to see a synthesis soon.
• IDEs: when I first started programming it seemed unquestionable that you needed to use an IDE. However, they were slow and bloated. And with the shift towards more dynamic languages there was also a shift towards pure text editors like Textmate and Sublime and a return to Vim and Emacs. However, with editors like Atom that has a richer-than-ever plugin ecosystems it seems like we're headed in a synthesis direction where we use lightweight editors while plugging in static analysis, autocompletion, and other automation tools.

There are a lot more industry trends that can be described and understood using the dialectical framework of progress. I'd be curious to hear your thoughts on this and if you think if this framework applies to trends in your programming community. I'm best reachable on twitter. Thanks for reading.

It's never been better for programmers, a team of 5 today can build projects and companies that required hundreds if not thousands of engineers just a few decades ago. So although Fred Brooks was right in that there was "no silver bullet" which "by itself promises even an order of magnitude improvement in productivity" I'd argue that there was a million silver arrows that collectively got us those improvements.

Much of this came through open source software, development tools and open source development tools.

However, this happened as a wave of distributed innovation. There was no central planning and no vision — it all happened organically. Which explains why a lot of our day-to-day development tools overlap, compete, and require a ton of compatibility code just to make them work with each other.

Let's take an example. Say you're a JavaScript developer and you use the latest and greatest tools. You write your code in ES2017. But before you ship it to your users you use a compiler like Babel which has to parse your code to compile it to ES5. And you also want to bundle your code so you use a bundler like Webpack which parses your ES5 code, collect the require/import statements, and bundles your code. Finally, you also use a minifer like Uglify which has to also parse and then minify your code.

You may have noticed that there is only 3 parse steps in this pipeline, that's because I ran out of slide space. The browser still needs to parse the code before it executes it.

Ok, so what? Well, there is a good chance you're reading this article to kill time while Webpack is recompiling. Everything is slow. There is also a question of how many parsers, as a community, do we have to write and maintain. Furthermore, there is lot of information loss as we go down the pipeline — you might've had Flow type annotations but those will not be accessible for the minifier to emit optimized code because they're compiled away at an earlier step.

(This is only one branch of the development pipeline, there is also the IDE/static analysis and code generation that contains similar duplication of work and incompatibilities).

Roughly speaking, we separate our tools by development life-cycle stage: authoring, executing, testing, building, and deployment. Which limits how much sharing of information and work can happen between tools.

Ok, then what if we imagined we live in a different world where we've taken a more holistic approach to development environments where we layer tools on top of each other. My IDE knows where and how my code executes and can show me inline information about function calls, error rates, and type information — heck, why won't production crashes translate into local development breakpoints? What if my repo on Github could pull from the same code intelligence service and have a click-to-symbol feature. Etc.

Alan Kay tells us that computing is "pop culture" because we have "disdain for history". Well, I'd like to do better. So in looking at this problem I decided to construct a historical narrative to help us understand how we got here.

Worse Is Better

In March 1990 Gaberial stood in front of crowd of Lisp developers and told them that "Worse is Better". The Lisp community's who's who were in the audience and they weren't very happy with the talk. After the talk, Gerry Sussman was the first to stand up and claim nonsense. Followed by Carl Hewitt, and there was Gaberial defending a position that, had the Lisp community understood, maybe the world of software engineering today would've been very different.

See the Lisp community practiced the Right Thing software philosophy which was also know as "The MIT Approach" and they were also known as "LISP Hackers".

The larger research community that the Lisp community was part of was operating under a vision of computing that Alan Kay recently mentioned in a Quora answer: “The destiny of computers is to become interactive intellectual amplifiers for everyone in the world pervasively networked worldwide”.

They were building amazing technology. Take for example Interlisp, a bootstrapped end-to-end Lisp programming environment that featured a structure editor (picture editing AST nodes instead of text), a REPL (with undo, which right now is coming back as "time-traveling debugger") and among many other things automatic error correction.

Meanwhile in New Jersey the "Worse is Better" folks, also known as "New Jersey Style", also known as "C hackers" were hacking on the C programming language and the Unix operating system. They had a much more pragmatic approach than the MIT approach — they valued, above anything else, a simplicity of implementation. Almost exactly the opposite of what the MIT folks valued, which is simplicity of interface, completeness, and correctness.

(I like to imagine a late-night stoner-like conversation between Dennis Ritchie and Ken Thompson:

"Dude, what if, like, everything was made of files?"

"Everything?"

"Yeah, like eeverrryyything"

"Whoaa")

Back to Richard Gabriel. After he was lambasted by everyone at the conference he went home, hid his essay, and vowed never to talk about it again. See he knew that in the wrong hands Worse is Better — which although the New Jersey folks were practicing they weren't preaching — could do a lot of damage.

A couple of years later Richard hired a young hacker by the name of Jamie Zawinski (later of Netscape fame — and can be found running a nightclub somewhere in the SoMa district of SF). Like most hackers Jamie believed that information should be free so when he found the Worse is Better paper he decided, without asking Richard, to send it to all his friend. It then spread like wildfire across the industry.

What was supposed to be a wake up call became a self-fulfilling prophecy. Richard talks about how "Large companies (with 3-letter names)" (hint: IBM) used the Worse is Better paper a reference for training employees on how to design software.

Later in his career Richard — realizing that he was responsible for the final nail in the coffin that killed the Right Thing approach to software development — began writing against Worse is Better under a pseudonym. Legend has it that he became so confused about this subject that he was once invited to talk about it and both argued for and against Worse is Better.

Now that I understand our place in history I can't help but wonder what would've happened if the Right Thing philosophy had won out. If our development environment resembled something like Interlisp instead of Unix. I think maybe since the main feature of Worse is Better is that — in the words of Richard — "it spreads like virus" it had been better for computing to adopt this approach to achieve scale. But now what? I think we should be more ambitious and bring back the Right Thing.

(In the talk which this is based on I talk a bit about what I'm doing about the problem. I've written briefly about this elsewhere: "Building Towards a Holistic Development Service")

In Silicon Valley, where your company feeds you, washes your clothes, and supply your social life, are you a minimalist for not having a kitchen, a washer, or friends outside of work? Defined this way, a baby is the ultimate minimalist, after all it has zero possessions and relies on the mother for everything.

I think self-sufficiency needs to be taken into account when evaluating minimalism -- even if it's at the cost of having more material possessions. For instance, buying a hair clipper and spending a bit of time learning how to cut my own hair is definitely more minimal than relying on a barber that I have to schedule with, pay to, and go to (that can get sick, go on vacation, or move away).

A similar thing happens in software all the time -- is it more minimal:

• to use a service than it is implement your own?
• to take on a software package dependency than it is to write your own library?
• to have users always augment your app with some other app for a missing feature than it is to add it?

A Fake Minimalist will go with the former for every case.

In his "Spec-ulation" talk, Rich Hickey brought this point home by defining software growth as (my emphasis):

• Accretion: to provide more functionality.
• Relaxation: to require less (dependencies, inputs, etc).
• Fixation: to fix bugs.

This will be roughly chronological going through the big events that took place last year, and will conclude with some books, lectures, and ideas that had a big impact on my thinking and worldview.

Leaving Facebook

At the beginning of the year it seemed like I finally arrived at job happiness. In 2015 I helped start the JS Infra team at Facebook. The motivation for building this team came from my experience building the React Native Packager where I noticed that the infrastructure that we're basing our development toolkit on was poorly maintained, bug-ridden and in some cases poorly designed with no hope without a full rewrite (or replacement).

So we assembled an amazing team of engineers to build out the basic building blocks that would power Facebook's JavaScript development (and hopefully the JS community at large).

JS Infra sailing off-site. Not in the photo: Christoph Pojer (which was taking the photos). And our manager Tom Occhino

Although the JS infra team was deeply technical and in some cases working on problems a few layers removed from the developer experience, we always thought it's best to start from the user experience and work our way backwards. For instance, I remember talking to someone from the Parse team who told me about a metric they used to make sure their tools are easy to get started with: TTH, time till hello world. So when the time came to think about how people would get started with React Native, it was obvious that the CLI needs to be robust enough to guide the user all the way through to see something on the screen within 5 minutes of installation!

react-native init AwesomeProject
cd AwesomeProject
react-native run

Although our team wasn't perfect, we had immediate impact starting with the first half in our existence. We worked on and released Babel 6, which took Babel from being merely a transpiler to being a platform and a compiler toolkit. We switched over Facebook's entire JS infrastructure to use it. And not only used it for transpiling it was now being used by teams throughout the company for things like i18n, accessibility, optimization and so much more! We fixed Jest and it became a few order of magnitudes faster. We continued improving on the React Native packager which became a central piece of infrastructure at the company (both as a development tool and as a build system).

Unfortunately, not everyone at the company believed that our team's existence is justified. There was a big push to work on performance (which I thought was justified since the website was very slow). So there was a lot of pressure on us to dump everything that we're working on and focus a 100% on performance.

I didn't agree that what we're doing and the performance goal weren't aligned. But in the end I lost the office politics game and our team was all but dismantled. Luckily, I had a great manager, and great support from many other people at the company. So I was given a chance to find something I could be as passionate about. But to be honest, my passion had already drifted towards an old but growing side project of mine.

(A new and improved version of the team has now reassembled and are building amazing things for the JS community -- like the Yarn package manager!)

Starting Repl.it (the company)

In 2015 Haya Odeh and I planned to give an old side project of ours a face-lift -- mostly just for fun. We knew that some people were using Repl.it but when we looked, we where surprised to see that there are 10s of thousands of people using it a month. We started researching, visiting our users, and doing surveys. We found that our biggest impact was on physical classrooms across the country and the world. (Which was not that big of a surprise).

Haya talking to students using Repl.it at the Mountain View High school

Repl.it was always at least partly about education. Back in school, I was displeased with the fact that every class I went to had to spend hours installing software. And I watched the instructor struggle to get everyone's compilers and editors setup (with matching versions). I started dreaming up a site where you open a new tab and start coding. And in 2011 that's what we built and not only did it help with that, we open-sourced the underlying execution engine (built with emscripten) which went to on power many learn-to-code websites (most famously, Codecademy, which I joined as the #1 employee).

One thing lead to another, and my brother Faris joined us in working on the project and we ended up not only redesigning the website, but we added user accounts, built a cloud-based code execution engine and many smaller features. We also started planning a totally new product on top of our core offering -- a classroom product that automates many of the tedious tasks we noticed a teacher has to do to manage their classroom. Things like submitting homework, giving feedback on homework, and tracking student progress.

We incorporated in May, 2016 with the mission to make programming more accessible. We're building powerful yet simple coding interfaces for programmers and students. And we're building a platform for teachers that want to bring programming to their classroom or reach a wider audience online.

Repl.it classroom

We rushed to build our first major product as a company. After tons of research and a tight feedback loop with a handful of teachers it was ready for the release just before the fall school season started. We launched in August and much to our surprise that put us on an exponential growth curve. Professors at universities like CMU signed up and used us to teach "Math Background for Machine Learning", followed by MIT, Cornell and many others. Bootcamps like Hack Reactor and App Academy used us for introductory courses. And high-schools across the US, UK, Japan, and elsewhere in the world started signing up.

The student environment

Partners

We're so lucky to be in this part of the world -- Silicon Valley is a place where immigrants can come in and build companies. We're double lucky to have found the support and mentorship of amazing people. Repl.it is now backed by Bloomberg Beta and Reach capital and I could've never imagined that the founder/investor relationship could be this good. We're still starting out and the journey is only 0.0001% complete (Facebook likes to say it's 1% complete), but whatever modest success we achieved we couldn't have done it without the support and mentorship of Roy Bahat, Wayee Chu, Christina Cacioppo, Chris Mather, and Ly Nguyen.

Repl.it in 2017

We spent the last quarter of 2016 focused on the core REPL product -- adding more power yet maintaining the simplicity. We added support for third-party libraries, implemented a debugger, and live file updates. You can see more on our blog.

Live file updates

Debugging

We also grew the team and hired our first employee. This month, we'll be moving to our first private office and we're hoping to add more engineers to the team soon. We have a lot of interesting technical challenges, and we'd like to think we're working on an important mission, if that's interesting to you then consider joining us :)

This year we're going to continue being heads-down focused on product and technology. We have a lot of interesting features in the pipeline. But most importantly we want to find ways to have our teachers, students, and engineers collaborate with each other and build an awesome community.

Thoughts, books, etc

Coming to terms with Physicalism

You don't notice how much outdated belief you have in your head until you sit down and examine them. In a recent talk, Alan Kay describes how every 3-5 years he sits down and writes down all his beliefs in an effort to update them.

This year I did this for my worldview and my philosophy on the nature of the universe. Physicalism is the thesis that everything is physical. That means -- among many other things -- that your mind/soul is a product of the physical processes in your body, and it obeys the laws of physics just like an apple falling from a tree. The implications here are big and many. It also could be scary, but luckily I was aided by a few books that I recommend to anyone who wants to come to terms with this.

Rationality: From AI to Zombies

To build an AI you need to understand and describe how the human mind works (and how it often doesn't). This book helped me in a few ways:

• I now understand pervasiveness of cognitive biases and fallacies. In the words of Richard Feynman: "You are the easiest person to fool".
• Using a mix fables and science the author gently guides you from the default dualist belief (mind is separate from the body/world) to a purely physical world.
• Presents different ways to think about some of the seeming absurdities of Physicalism (for example, are we all just cogs in the unwinding clock that is the universe?).

The book has all sorts of tips and tricks to help you face up to the truth. One of my favorites is the "Litany of Gendlin":

What is true is already so.
Owning up to it doesn't make it worse.
Not being open about it doesn't make it go away.
And because it's true, it is what is there to be interacted with.
Anything untrue isn't there to be lived.
People can stand what is true,
for they are already enduring it.

The Beginning of Infinity: Explanations That Transform the World

This book layed out the basis for a hopeful and optimistic Physicalist worldview. It gives people (or universal explainers in general, as the book calls them) a more privilege place in the universe. Yes, we are "chemical scum" that evolved via Darwinian selection but our reach can be infinite. And our journey has just begun towards the infinite creation of knowledge.

Personal Identity

The concept of "self" seems to be a hack. Evolution gave us this abstraction because it seems to simplify a lot of things -- most importantly, self-preservation (so we can take care of ourselves until we procreate). This idea started forming in my head in 2015 after reading Marvin Minsky's Society of Mind, which plausibly breaks down the mind into modules and presents it as if it's a big piece of software.

Consider how split brain patients seem to have two sides of their brains behave somewhat autonomously (as if it's a different person). In this video the patient's right hemisphere is shown a word (via his left eye) but he couldn't say what it was. However, when he closed his eyes and started drawing he was able to draw a pan (which is the word that he saw).

This is just scratching the surface, earlier this year I started reading Reasons and Persons by the late Derek Parfit (died a few days ago). It includes all sorts of thought experiments that all but destroys the concept of self. I couldn't finish the book because it was too hard and jargony. However, luckily, I found a course on YouTube titled Death that draws heavily from Parfit's work on personal identity. And this completely shattered how I thought about my self and my place in the world.

I'm now more accepting of the fact that I and everyone I know and love will die in the not very distant future. I feel more connected to other people. And finally understand what it means to have an impact in the world (improve lives and reduce suffering).

(For a quick primer on the subject I recommend Wait But Why's "What Makes You You?" essay).

Thanks for reading.

Last month, on the Philosophize This podcast, I heard about Kierkegaard's work on despair and found it to be a weirdly good articulation of my thoughts on work fulfillment and progress. He was a 19th century Danish philosopher and wrote primarily on psychology and the human condition. Although he viewed most things through the lens of theology, it's common -- and works pretty well -- to have a secular reading of his work.

He viewed the self as having two opposing aspects. One that he called the infinite and the other is the finite. He described the relationship between them as dialectical -- which means that one cannot exist without the other and that there is constant tension between them. Furthermore, there exists a "synthesis", a point which we can balance these contradicting forces.

The infinite and finite

The finite aspect of the self deals with worldly facts about the person. It is the condition in which one exists. Your name, sex, race, and even things that are more general like the social, political, and cultural environment that you find yourself in. The finite is concerned with necessity as opposed to possibilities -- things that are largely predetermined.

The infinite is the aspect of the self that deals with abstractions, different meanings, and possibilities. And imagination is its primary device. The infinite is concerned with what the self can become as opposed to its current state. It opens up opportunities to free oneself from the rigidity of finite existence.

If someone lacked either aspects of themselves, Kierkegaard thought they'd be in a state of despair -- they can lose themselves in the infinite or in the finite.

The finite is the default

There is generally a set path in life for people to follow. Most choices are made for us, and someone can exist purely within the tracks that were manufactured for them by their parents, culture, and society. After we graduate and become adults we go to work and get plugged into the place that is deemed most fit for us and contribute our small part as cogs in the machine.

Just by losing himself this way, such a man has gained an increasing capacity for going along superbly in business and social life, indeed, for making a great success in the world. Here there is no delay, no difficulty with his self and its infinitizing; he is as smooth as a rolling stone, as courant [passable] as a circulating coin. He is so far from being regarded as a person in despair that he is just what a human being is supposed to be.

Bob is an engineer because his father was an engineer. He uses vim because everyone at work uses vim. He takes the designs passed to him by his product manager and implements them 100% according to spec. He never questions anything. He is moved by his managers from team to team without any objections. When asked why he's doing what he's doing, he parrots what his manager told him about the importance of the mission and how he fits in. He is as passable as a coin.

by getting engaged in all sorts of worldly affairs, by becoming wise about how things go in this world, such a man forgets himself, forgets what his name is (in the divine understanding of it), does not dare to believe in himself, finds it too venturesome a thing to be himself, far easier and safer to be like the others, to become an imitation, a number, a cipher in the crowd.

Bob is so easy to replace. He provides nothing to his team, work, society, or family that is unique to himself. He'd rather lose himself in the crowd, become indistinguishable, than be himself.

it is dangerous to venture. And why? Because one may lose. But not to venture is shrewd. And yet, by not venturing, it is so dreadfully easy to lose that which it would be difficult to lose in even the most venturesome venture, and in any case never so easily, so completely as if it were nothing ...one’s self.

Bob should know that he stands to lose more by accepting the default. He risks losing himself by taking the seemingly safe and secure choice. Let alone dream, imagine, or take the time to figure out what he really cares about in this world.

Lost in the infinite

Engaging in the infinite aspect of the self is important to balance out the finite. To come up with new ideas, new understanding of the world, and new meaning. In other words, to become something more. But unless this process is grounded in reality (the finite), the self may risk becoming too abstract, fantastic, unreal.

For example, if Bob loves humanity so much it makes him weep, it's just his boss he cannot stand. He has been carried away into the abstract, the infinite, and have lost his relation to the finite, the concrete. He holds an abstract and free-floating belief that's not influencing his behavior.

Similarly a person may get caught up in abstract knowledge that never makes its way back to the finite world. For example, Bob likes to learn about Machine Learning, he accumulates a whole lot of knowledge on the subject but never gets a chance to apply it at his job. Bob has lost himself in pursuing this knowledge because he is not able to benefit himself or the world from it.

Finally, and more relevant to our discussion, is being lost in "willing" (or wishing). For example, Bob wishes the world to move to renewable energy. But he never takes an action towards that end. This goal is so out of his control that there seems to be nothing he can do about it. He never grounds his imagination in the finite. He doesn't take the time to come up with the smallest possible task that can be a step towards achieving his desired state.

the will does not constantly become concrete in the same degree that it is abstract, in such a way that the more it is infinitized in purpose and resolution, the more present and contemporaneous with itself does it become in the small part of the task which can be realized at once, so that in being infinitized it returns in the strictest sense to its self, so that what is farthest from itself (when it is most infinitized in purpose and resolution) is in the same instant nearest to itself in accomplishing the infinitely small part of the task which can be done even today, even at this hour, even at this instant.

Entrepreneurship

I view entrepreneurship as means of reconciling the infinite and finite. You venture into your imagination, gather knowledge, and dream about a better world. But you have to bring some of that back to earth. You take a step -- no matter how small -- towards your imagined world in the real world.

This is not a one time thing, it's a recursive process. If your imagined possibilities became real then that's your new "finite". The process restarts and that's how we make progress.

This notion of progress comes from Hegelian dialectic. When traversing dialectical opposites like the infinite and finite, and are finally able to reconcile the conflict and arrive at common truths. This becomes our new reality and the process restarts.

I see this as the perfect framework for the work we do in technology. There is always a tension between what is and what could be. There are people and organizations who are stuck in the status quo (the finite). On the other hand, there are folks who are stuck in the what could be without any actionability (the infinite).

Taking a step into the infinite could be hard, but the hardest thing of all is bringing something back to the finite. The real art is coming up with the smallest possible task that can be done here and now.

Take Elon Musk for example, like Bob, he wants the world to move to renewable energy but that's such a big and daunting task that seems unapproachable. Elon could've been lost in the infinite. Instead he took a step towards doing something within his reach. He started an electric super-car company. It's counter-intuitive how this is relevant as outlined in his master plan in 2006:

The strategy of Tesla is to enter at the high end of the market, where customers are prepared to pay a premium, and then drive down market as fast as possible to higher unit volume and lower prices with each successive model.

Ten years later, Tesla is shipping the first mass-market electric car and innovating in battery technology. Making real progress towards a renewable energy world.

Not everyone can be Elon Musk, but we all can be entrepreneurial in our own sense. I think the most important thing is to always make progress. Don't get stuck in the weeds for too long. Imagine a better world, and take a small step towards it.

My problem is that I'm a perfectionist -- Everbody

As I finished writing the title for this post I thought about quitting. I didn't think it was good and told myself that this is off to a bad start and it'll only get worse as I write more words. There is always an easy fallback to get out of doing hard work without feeling bad about it: "I'm a perfectionist, and I can't possibly achieve perfection in this project so I'm going to quit altogether".

What was really going on here is that I realized that it's going to be harder than what I imagined it would be, and I just didn't want to do the work. Just being lazy. Laziness is a simplification here and in this post I'll go over all the layers that I've been able to debug in myself.

False dichotomies

I often notice that before I throw my hands in the air and claim perfectionism I present myself with a dichotomy: "It's either that I finish this work and hit all my goals or it's not valuable to anyone". Here are some examples:

• "I don't think it's worth going to the gym today because I know I don't have the time to go everyday and get six packs"
• "I need to revamp my blog before I write my blog post and I don't have the time to do all that now"

The truth is that most things are still valuable even in there imperfect or unfinished form. For example, it's hard to argue with the effectiveness of the popular Minimum Viable Product approach to product development. You're able to deliver value to people and at the same time test and iterate on your ideas.

Back to our examples, going to the gym at any time no matter what the situation is will be a categorically positive thing to do. And writing a blog post doesn't strictly depend on your blog's design (I almost fell for this one the other day).

Decision fatigue

Another thing that I've detected in myself that would make me fallback on the "I'm a perfectionist" excuse is decision fatigue. You can get tired from just making decisions if you had to do so many of them while working on something.

Say for example you want to tidy up your apartment. Since this is such a general goal, you'll be faced with so many questions along the way: "Should I fold my clothes like I always do or is it time reorganize my closet? Should I throw out the books I'm not using? Should I maybe give them away?" and so on. Very soon you'll be tired just from answering these questions without even doing much work. Then you'll see the nice and cozy excuse waiting for you: "I'm such a perfectionist I can't even tidy up my room!".

Embarrassment

Putting yourself and your work in the public requires a great deal of courage. For probably some evolutionary survival reasons we tend to think about all the things that could go wrong. One of the strongest negative emotions that I get when I'm not certain about the quality of my work is the feeling of being embarrassed by it. That people much smarter than me will look at it and laugh about how bad it is. That's almost never the case. I've written some really silly posts and code and it rarely gets ridiculed. Even when it does happen, it's usually by people that I don't necessarily respect or look up to (see my post about on the Stoic of Open Source for an example of this). That is not to say that everything I do is perfect, in fact, I get really awesome constructive feedback every time I release something.

Another tactic for avoiding embarrassment is not to over-promise. I'd go as far as to say you should not talk about your ideas before verifying that they work (see my post about idea generation). Which reminds me of what Tom my manager (who manages projects like React and Flow at Facebook) likes to say: "under-promise, over-deliver".

Confidence

If you aspire to do quality work you need to be able to trust in your abilities. Or at least that you would try really hard. Going back to the meta-example of writing this post. If I were confident of my abilities to overcome any hardship that started with the title, I would keep going while knowing that I will rewrite this as many time as it takes to get it to good enough state.

So I would need to be confident of my ability to get close to the goal, and in my ability to persevere and work hard enough to get there.

Curing perfectionism

Recognizing these patterns in our behavior is a good first step in getting over them. I had a lot of success with -- what I later discovered to be -- cognitive behavioral therapy. This is a good introduction to the subject but we're mainly interested in the following methods:

• Forced Activity
• Exposure

Forced Activity is when you recognize a vicious cycle in your behavior and force yourself out of it. It's forced because you need to swim against the current in order to break out. For example, if you noticed that you always start projects but quit and claim perfectionism, then try to start the smallest project possible that is actually perfectible and finish it. If you have too many unread books and you stopped reading because you can't possibly finish all the books then go throw them out (or delete everything on your kindle). Even if the action is a bit radical, do it to get you out of the cycle.

Exposure is when you tackle psychological pain by leaning into it. Start small with something you fear and do more and more. If, for example, you're afraid of publishing code then start by publishing a gist of a program that does something useful and share it. Then slowly work your way up to sharing a library and finally to contributing to large open source projects.

Up until last year, I had a crippling fear of public speaking and this method worked really well for me. Although I've spoken a few times before, every time I spoke the fear was worse than the one before. However, after committing to the Exposure method I started small by speaking at a friendly and welcoming meetup in NYC called BrooklynJS. And then worked my way towards a larger conference and spoke at EmpireJS. I then started really leaning into it and even performed at a story telling show. And finally completely improvised a couple of meetup talks. I'm now almost fearless when it comes to public speaking.

In conclusion I think that perfectionism is mostly a thin veil hiding a multitude of insecurities, fears, and logical fallacies. And it's something we need to face in order to reach self-actualization.

Thanks to Haya Odeh for reviewing this post and providing feedback, examples, and refining many of the ideas mentioned here.

Instead, he opened with talking about -- what is now a Silicon Valley cliche -- how ideas are overrated and execution is everything. Of course, cliches are sometimes cliches because they're true. However, things took an interesting turn when he mentioned the "Antifragile" concept.

Antifragile

A phenomena discovered by Nicholas Nassim Talib that describes things that are the opposite of fragile. We don't currently have a word to describe this in English. You might think that words like "robust" or "resilient" come close but actually those words describe systems that don't break under stress, but what about things that benefits from stress?

To me, this was one of those questions that you realize is simple but you're surprised that it hasn't entered your consciousness until this day.

Here is the description from the Antifragile book:

Just as human bones get stronger when subjected to stress and tension, and rumors or riots intensify when someone tries to repress them, many things in life benefit from stress, disorder, volatility, and turmoil. What Taleb has identified and calls “antifragile” is that category of things that not only gain from chaos but need it in order to survive and flourish.

After picking up this book and reading it, I was not only able to relate this back to Carmack's idea system (more on this later) but saw the world in a slightly different way. To give only one example, I see large open source software as antifragile. The more stress people put the software under the better it becomes. The more people use it in unanticipated ways and the more code path combinations are exercised then the more bugs are found and fixed. In contrast, proprietary software is usually used in controlled environments all the while building up fragility for a major catastrophic event waiting to happen (see Black Swan Theory).

Antifragile Idea Generation

In programming and many other creative jobs you get many ideas in any single day, but you can only implement a fraction of them. The fraction you haven't implemented you might start obsessing about. Everyone has their pet ideas that they go around discussing. The more time this idea spends in your head the less critically you think of it. Now, when the time comes to actually try implementing it, if it fails you're left discouraged, embarrassed and might even quit the project you're working on.

This is obviously a fragile system. You start neutral, get a small high when you first get the idea, and then it starts building up fragility while in your head. If and when it fails it's catastrophic on your productivity.

So what does an antifragile system for generating ideas look like? First let's lay out some criteria:

1. Antifragile systems are -- by definition -- able get the upside but are not affected by the downside. That means, we need to be able to get the initial idea high and the motivation that comes with it.
2. Failure events must end up making our system stronger. Meaning when an idea fails it needs to make the overall system better.

Here is what Carmack thinks an antifragile system might look like:

1. You are working on a problem and you get an idea and with it the initial idea high
2. You should instantly try to defeat your idea -- think of all the ways it could not work, test it out, put it under stress
3. If the idea survive the brutal scrutiny then it has legs for further investigations or implementation
4. If the idea is implemented and it works then that's great
5. If the idea fails the scrutiny or implementation you can quickly move on to the next idea without feeling the lows because you haven't obsessed or talked about it i.e. it's not your pet idea.

Carmack describes how this becomes like a game -- as soon as you get an idea you try to defeat it. You'll be able to generate more ideas because you freed up mental space. Furthermore, your existing ideas will even be stronger because they survived heavy scrutiny.

In Practice

I've been using this at work and in my personal life for a few months now and I recommend it to everyone. I end up prototyping a lot more and going through many iterations of ideas. And that reminded me of my early days of programming. Because I didn't know what was possible or not, I had to vet all my ideas by coding them up. I went through multiple VB projects in any single day.

At work, we're now focused on JavaScript and web performance, and found this an indispensable tool for this type of work. Optimization work (after crushing the low-hanging fruit) is often counter-intuitive and many ideas that sound great in theory end up tanking in practice. So to make progress we need to have a lot of ideas and try many of them. And this gave me great framework to approach this with.

Complications arise when we have different modules at different times being interested in the same data. And fetching something from memory (cached) is fundamentally different from, for example, reading it from disk or a remote host. In JavaScript, the latter is implemented as an asynchronous call. And since we usually don't know the order of calls ahead of time we're left with having to provide a consistent interface to all callers regardless of where the data is being fetched from. You'd also need to handle cases where callers ask for data concurrently. Meaning that we may get another call while we are still fetching the data and now we're left to manage calling the clients back in the right order that they called us in.

The good news is that we can use Promises to:

1. Not have to distinguish between first and subsequent calls
2. Provide a consistent async interface
3. Manage callbacks and error propagation

A more interesting example would be something that needs to change it's internal state. However, we need to do it in a way that doesn't require synchronous and mutative access to the data. One of our criteria is to blur the distinction between readily available data and things we haven't fetched yet. We also don't want different mutation calls to effect each other. Ideally, every call would get it's own copy of the data that reflect the state of the world at the time of the call.

We can handle this by chaining promise calls that will result in new instances of the data that will also be cached for future use. Regardless of whether calls happen concurrently we maintain a strict order of execution and every call will get a copy of the data without the changes that were made by other callers.

Stores and Loaders

Caching can be hard if we have to continually answer the question: Do we have the data in memory or do we need to fetch it? We just showed how we can use promises to simplify this. However, it doesn't take into account function parameters. A robust caching system has to be able to associate results with inputs, be it URLs, file names, or arbitrary function parameters. To this end we can create a store abstraction that will store things in the form of key/values. But this presents a new challenge of having to synchronize fetching data and storing it.

You can imagine two get calls to the stores for something we don't have a result for yet. Then these two callers would go about concurrently trying to compute or fetch the data and then come back and try to set it in the store. And now we have a duplication of work and something akin to a race condition when it comes to writing the result back to the store. We can add an isFetching flag to the store but that brings us back to square one of having to manage callbacks. Here again we can use promises to solve this problem. In addition to managing callbacks for us they'll provide something which we can call the "loader" interface.

So instead of having the callers arbitrarily check and set data on the store, we can instead only expose a get method that will take a key and a loader function that if called should return a promise for the value. That way the first time the Cache class encounters a key it will call the loader function and cache the promise for any subsequent caller.

Memoization

So far we've seen how we can remove the burden of having to check whether something is in memory or not at every turn. If we generalize this a bit we can say that callers should always call functions regardless of the current state. This is commonly referred to as memoization and it allows us to build faster programs without compromising on simplicity. That's partly why frameworks like React are popular -- it unburdens the programmer from dealing with stateful objects like the DOM. You always render. Just like you always call.

All the caching techniques powered by promises that we talked about here can come in handy when building large programs that conceptually looks like good old simple and stateless programs without compromising on performance.

My personal experience with this was with building the React Native Packager and the module resolver. One of our goals with React Native is to bring the fast feedback loop we're used to in web development to native. However, when we looked at bundlers in the wild we found that for any sizable project they took 10s of seconds to recompute the bundle after a single file change. So we had to build our own with performance as the defining feature.

The entire system was built to be lazy and heavily cached using the techniques outlined in this article. When we get a request for a bundle we go through and apply the module resolution algorithm recursively while reading all the necessary files. And then we compile the files in parallel and finally combine everything in a single bundle and generate the sourcemaps. Everyone of those steps requires heavy computation and/or I/O. But along the way we cache everything at a granular level. Then the next time we fan-out in the tree of calls to generate the bundle most things will be cached and the result is instantly returned from memory. The whole thing takes up to a hundred milliseconds to execute.

When a file changes we invalidate the caches concerning that file and we simulate a request that would go through entire process again but this time recomputing parts of the process concerning the changed file (and any other artifacts affected by it). This will take less than a second to finish. And by the time the actual request comes in from the client we have everything cached!

repl.it and the underlying tech is a project that grew out of my frustration from the process of setting up machines to learn programming. I believed that one of the main turn offs for people wanting to learn how to code was setting up the development environment. That's when I thought that putting a REPL on the web was the best way to get started with programming.

In 2011, and after working on the problem for almost a year we were able to cross-compile numerous language interpreters to JavaScript and we also hand coded some. We open sourced everything along the way and little did we know that our work would help accelerate a revolution in online programming education.

Our open source code evaluation infrastructure was used by companies like Codeacademy, Udacity, Bloc, and many others to deliver an in-browser coding experience. Unfortunately, the way we were doing things was pushing the envelope for what browsers could do at the time and they would break our code very often. Coupled with the fact that users had to download megabytes worth of JavaScript before being able to do anything made it unreliable for websites serving millions of users all over the world. Since then, I stopped using it in production in favor for a server-based system and to keep myself honest I also deprecated the open source project.

After the move, I still got emails from people asking for support on those projects, and I felt guilty for not being able to help. At the same time repl.it was growing and with it my wallet was shrinking. One of the benefits of doing client-side code evaluation was that the cost was practically zero. I considered putting ads on the site but I couldn't do this to our users. Especially because many of them happen to be students learning as part of classrooms:

After getting so many emails from people asking for support I decided to offer our code evaluation infrastructure as a service. Since then we had a few customers use us -- enough to cover repl.it's cost. More than anything, I'm happy that our customers are deriving a lot of value from the service and in many cases they're building things in line with our mission of democratizing programming. For example, Carnegie Mellon University is using us as part of their online open learning initiative. Flatiron school and Trinket are using us to build their online education platforms. Oneinterview and Airety are using us to deliver online interviewing services. And of course repl.it uses the same API for the main site, and the embeds.

I'm planning to do a technical write up about the tech and architecture behind the service but the basic idea is that you connect to our servers and then send us programs to execute. It's fast, reliable, and scalable. Try out at repl.it. And check out the API page for more information. Here is what an API call looks like for a "Hello World" in Ruby:

var repl = new ReplitClient('api.repl.it', 80, 'ruby', token);
repl.connect().then(() => repl.evaluate(
  'puts "hello world"',
  { stdout: out => console.log(out) }
));

What started as something that I thought of as a necessary annoyance to keep the site running turned out to be something that I'm actually proud of. This wouldn't have been possible without the work from Haya and Faris where they continue to build awesome new features and products on top of repl.it.

1. A few high profile open source maintainer burnouts¹
2. I've been reading a lot of philosophy²

I was first introduced to Stoicism by a friend who recommended the book A Guide to the Good Life. And they kept coming up whenever I'm reading about philosophy, and for good reason, they're a cool bunch.

Stoics understood that you can never depend on external factors for happiness and that the only way to achieve a sense of well-being is to be internally satisfied. However, unlike the cynics or the skeptics, they can derive happiness from the external world. In other words, they get all the upside while avoiding downside. This sounds amazing, and at first glance it sounds a bit like Buddhism, but I think the defining feature of Stoicism is their use of psychological tricks and reasoning to achieve their goal of tranquility. That's why I think it may resonate with the programmer community. Maybe we can learn something from them about open source maintenance?

insults and attacks

One thing that angers me -- and I see angers many open source maintainers -- is the harsh criticism mixed with personal attacks that some users launch against maintainers. There could be thousands of satisfied users but a handful of loud and vile individuals could make your life miserable. This can be related to how the Stoics dealt with insults. And they had a lot to say about the subject.

Epictetus recommended that we pause to consider our insulter. If he is a fool then rather than become angry or hurt, we should feel relief over his disapproval and insults. Indeed, we should be more concerned if we find the fool agreeing with us³. It goes without saying that someone launching personal attacks against you for providing your work free of charge, is a fool.

Begin each day by telling yourself: Today I shall be meeting with interference, ingratitude, insolence, disloyalty, ill-will, and selfishness -- all of them due to the offenders’ ignorance of what is good or evil?

-- Marcus Aurelius

If you are putting yourself and your work in the public eye then it's very likely that you're going to have a run-in with the above-mentioned unpleasant people. So accept it as a reality and learn to deal with it.

Seneca suggests a potentially more useful way of dealing with insults:

Why is it an insult, to be told what is self-evident?

If you found that there is some truth in the attack. Then simply extract that knowledge as constructive feedback and use it to improve yourself and your project.

Those are some tools we can use to reason out the sting of the insult, but what do we do about it? do we have to reply? The Stoics advocated two main ways of responding to insults:

1. Humor
2. Refusing to respond

By simply laughing off an insult, we are implying that the insult and insulter are not to be taken seriously therefore stripping them of any legitimacy that would otherwise be implied if we replied seriously to their insult. Here are a couple of amusing anecdotes from Seneca:

Seneca points approvingly to Cato’s use of humor to deflect a particularly grievous insult. Cato was pleading a case when an adversary named Lentulus spit in his face. Rather than getting angry or returning the insult, Cato calmly wiped off the spit and said, “I will swear to anyone, Lentulus, that people are wrong to say that you cannot use your mouth!” Seneca also approves of Socrates’ response to an even more abusive insult. Someone once came up to Socrates and, without warning, boxed his ears. Rather than getting angry, Socrates made a joke about what a nuisance it is, when we go out, that we can never be sure whether or not to wear a helmet. ⁴

If you are quick-witted then this type of humor may come naturally to you, but I'm not. And, paradoxically, spending a lot of much time coming up with the perfect comeback will have the negative effect of dwelling over the insult. Therefore the best thing to do is act as if it never happened. This, first of all, robs them of the pleasure of having upset us. And also shows everyone in the community that we can't be bothered with childish behavior and we have more important things to attend to (such as maintaining the project).

on making mistakes

Everyone makes mistakes, and open source maintainers are no exception. You'll eventually push a breaking change that will unleash a mob of semver purists gunning for your head (refer to the previous section on how to deal with obnoxious people). Here, I'll talk about how you should reason about the fact that you made a mistake.

Truths about the past are necessary: it is not merely that they aren't other than they are—they can't be other than they are, for nothing has the power to change the past -- Epictetus

Stoics were pioneers of logic, and it followed from their use of logic that we should have a fatalistic attitude towards the past. We just learn from our mistakes and move on -- there could have never been a world where you have not made that mistake. Because without that event happening the world where you are now looking back at that mistake doesn't exist. The last part was me going out on a limb, but all this to say is that you can't change the past and there is no point in feeling regret.

Mistakes may help you revise and strengthen your processes and tests. It may even get your users to be more involved in the project's maintenance because they see you as someone needing their help. I doubt that any one mistake has ever caused the failure of an open source project, the important thing is to learn and move on.

work on your own terms

Taking a utilitarian approach to open source seems to be the best and most sustainable. In the JS Infra team at Facebook we have the following dictum:

We only open source what we use in production

When we stop using something internally we either find a new home for it or simply deprecate it. This puts us in a better position to serve our community. Similarly, you can approach your personal open source projects with the same attitude. Keep your project focused and fully aligned with your needs.

For example, if someone sends you pull request for a feature that you are not going to use yourself and don't have the time test and maintain, then simply refuse it. It's better to be focused in scope than to make the project suitable for every possible use case while increasing your chances of burnout.

Nothing is worth doing pointlessly -- Marcus Aurelius

People looking from the outside at open source are often amazed by how a world based on altruism could exist. Sorry, it doesn't. A lot can be gained from participating in open source. Slaving away with no explicit goal is a recipe for disaster. I'm not saying that helping others is not a valid a goal -- it could be, however, it should be intentional.

It is impossible that happiness, and yearning for what is not present, should ever be united -- Epictetus

Try not tie your identity and sense of well-being to your open source project. Align your needs with the community, get the upside of any contributions and popularity. But try not to get affected by any downside.

[1] I've never been a sole creator/maintainer of a massively popular open source project, however, I work as part of teams on massively popular open source projects. So I probably don't understand the magnitude of stress sole maintainers may feel.

[4] A passage from The Guide to The Good Life

I've been thinking about how this translates to programming. Programming is an intellectually challenging task, but luckily we invent tools to make it manageable. I find that up to a certain point, the intuitive and easy properties of a given language, framework, or library might start to have negative effects. From personal experience and from mentoring beginners I noticed that when using tools that allow us to reason within our intuition, anytime we're faced with some difficulty we feel that we've done something wrong. And although we might have the necessary skills to overcome the difficulty, we often start questioning and revising our work. Asking questions about best practices relative to the framework instead of programming our way out. The quintessential example of this is the Stack overflow questions for "how do I use jQuery to do X?" or the answers "use jQuery [plugin] to do X" where X could be anything from basic arithmetic to websockets.

The framework negative space

When using a framework, a certain class of problems are made easy to solve. Programming feels intuitive if we stay within that space created by the framework. We may refer to this as the framework intuitive space. On the other hand we may refer to the rest of the space that framework doesn't solve or have an opinion on as the framework negative space. The negative space is not necessarily a defect of the framework, it's just not in the space the framework was built to solve. However, having put the programmer in the intuitive space for a long stretch of time, it makes it feel out of place when finding oneself in the negative space.

When the beginner programmer find themselves in the negative space, they often look to the library authors to put them back in the intuitive space. That's why for any popular framework you find that there is an entire ecosystem of plugins and addons that extends the framework's intuitive space to cover an increasingly growing surface area. It doesn't seem to be inherently wrong if it makes programmers more productive. However, it may have unintended negative consequences:

1. Increased reliance from the programmer on the ecosystem's library authors
2. Offloading of architectural decisions to the libraries all the while incurring technical debt
3. Enabling the false belief that programming should always feel intuitive

The developer and library author codependency

I should start by saying that this is technically a false dichotomy. All programmers take on both those roles in any programming session. You maybe coding the product business logic and switch to building a general purpose abstraction to help you in multiple places in your codebase. However, I've noticed that in open-source, people tend to act in a manner that makes this dichotomy seem true.

The easiest way I've found to succeed in open source is to pave the negative framework space to become an intuitive space. In other words, writing the plugins and extensions. As a framework becomes more popular, a growing number of developers (usually beginners) will start complaining about how it's hard to do X in this framework (and as we've seen X might be totally unrelated). Now, as in the business world, open-source is extremely competitive and as soon as there is an opening to solve a perceived problem for a lot of people, many would rise up to the occasion. This becomes an enabler to the false belief that a programmer can spend all of their time programming in the intuitive space.

Conclusion

I think fixing this problem ultimately comes down to education. Very early on when someone is learning programming our culture tend to emphasize an obsession with tooling. I get a lot of questions from aspiring programmers on what's the best tool or languages to learn. It's almost always a premature question to ask. I used to come up with answers like "depending on what you're building" or "pick a beginner friendly community" or "invest in a growing language". I think all of these are good answers, but it doesn't really matter that early on in a programmer's learning journey. It's all the same when you're essentially learning how to compute. Furthermore, these sort of answers enable the culture of tooling obsession.

Code reuse, libraries, sharing, and open-source are very important to software engineering, but we should be careful to not enable the belief that programming should be as easy as gluing things together. In fact, these days I'm often skeptical when things feel a little bit too easy. If programming was as easy as this then it would've already been automated away.

When I joined the company, I worked on a team tasked with improving photo upload reliability on the site. We were failing 1 out of 10 people that tried to upload a photo album. Which translates to millions of people having terrible experiences on daily basis. One of the first things that we struggled with was understanding the ordering of operations. The system was made up of multiple components (Flash for image re-sizing, UIs, Controllers, Servers) that had to asynchronously communicate via JS and was all done in callbacks. This made debugging really hard. Sometimes callbacks will get lost and never get called, at times they will be called multiple times, sometimes errors will occur after the callback is called and never gets reported. Not to mention all the horrible race conditions that we saw. And this is not something that is limited to Facebook, or that can only happen at our scale. I was in similar situations at small startups too. This can happen in any sizable (potentially distributed) system written in JavaScript using callbacks.

When I first started learning JavaScript, one of things people praised it for was: "easy concurrent programming". The argument goes "it's a single-threaded process with a strict run-to-completion programming model and that means you can't have race conditions". Turns out that can't be further from the truth. The definition of race conditions is not tied to multithreading. It is simply when you have a system that is dependent on the sequence of events from multiple components and then the components behave in an unintended way. Which brings me to the point of this post. I want to show that using async functions (or generally co-routines) you can write programs that makes the expected ordering of events explicit and makes it easier to recover from failures in subcomponents.

I will illustrate this by going through an example of building a vending machine. Everything in the vending machine costs 1 cent, but the machine can take in any coin that is worth any arbitrary number of cents. A sample run of this machine:

• Insert a quarter
• Select an item
• Dispense the item
• Return 24 cents change

Here is my initial implementation:

• A VendingMachine class with two public methods
• coin(value) inputs a coin with a given value in cents to the machine
• select(item) inputs an item selection to the machine
• Two subcomponents itemDispenser and change resoponsible for dispensing the items and returning the change respectively

class VendingMachine {
  coin(value) {
    this.cents = value;
  }

  select(item) {
    this.itemDispenser.dispense(item, () => {
      this.change.return(this.cents - 1);
    });
  }
}

Simple enough. But of course it's missing a few things. First of all there is no error handling:

• What if the itemDispenser failed? We should of course return all the money.
• What if the change component failed? We should get into broken state so we don't accept any more coins until someone fixes the machine.

Let's add error handling and a broken state.

class VendingMachine {
  coin(value) {
    if (this.broken){
      console.error('Out of order');
      return;
    }

    this.cents = value;
  }

  select(item) {
    let change = this.cents - 1;
    this.itemDispenser.dispense(item, e => {
      if (e) {
        console.error(e.message);
        // Failed to dispense item, return all the money.
        change = this.cents;
      }

      this.change.return(change, e => {
        if (e) {
          this.broken = true;
        }
      })
    });
  }
}

Now that we can handle errors from the machine components. What if the outside world behaved in an unintended way? In other words, what if someone selected an item without paying? What if someone inserted two coins without selecting an item? Ideally we'd have input queuing, but let's keep it simple for now.

class VendingMachine {
  coin(value) {
    if (this.broken){
      console.error('Out of order');
      return;
    }

    if (this.cents) {
      console.error('Processing existing order');
      return;
    }

    this.cents = value;
  }

  select(item) {
    if (!this.cents) {
      console.error('Please insert a coin');
      return;
    }

    let change = this.cents - 1;
    this.itemDispenser.dispense(item, e => {
      if (e) {
        console.error(e.message);
        // Failed to dispense item, return all the money.
        change = this.cents;
      }

      this.change.return(change, e => {
        if (e) {
          this.broken = true;
        }
        this.cents = 0;
      })
    });
  }
}

Can you spot the potential race condition? What if you inserted a coin, selected an item, then before the machine gets a chance to dispense the item and return the change you selected another item? We should make sure this.cents is updated right after the selection.

class VendingMachine {
  coin(value) {
    if (this.broken){
      console.error('Out of order');
      return;
    }

    if (this.cents) {
      console.error('Processing existing order');
      return;
    }

    this.cents = value;
  }

  select(item) {
    if (!this.cents) {
      console.error('Please insert a coin');
      return;
    }

    let change = this.cents - 1;
    // Immediately update to avoid race conditions
    this.cents = 0;

    this.itemDispenser.dispense(item, e => {
      if (e) {
        console.error(e.message);
        // Failed to dispense item, return all the money.
        change += 1;
      }

      this.change.return(change, e => {
        if (e) {
          this.broken = true;
        }
        this.cents = 0;
      })
    });
  }
}

But wait, are we really done? What if you inserted a coin, selected an item, and then immediatly inserted another coin? That coin is then lost in limbo. We should gaurd the entire the process with another state variable. But the problem is that every time we add a state variable it makes the program harder to understand and test, and presents more race hazards. Who would've thought a program with two input events can be so complex to build reliabily. I'll spare you anymore inspection and iteration and directly jump to what any sensible programmer would do when presented with this challenge: build a state machine.

class VendingMachine {
  constructor() {
    this.state = IDLE;
    this.queue = [];
  }

  coin(coin) {
    if (this.state === BROKEN) {
      return console.error('Machine broken');
    }

    this.queue.push(coin);
    this.dispatch();
  }

  dispatch() {
    if (this.state !== IDLE) {
      return;
    }

    this.cents = this.queue.shift();
    this.state = WAIT_FOR_SELECT;
  }

  break(err) {
   console.error(err.message);
   this.state = BROKEN;
  }

  select(item) {
    if (this.state === IDLE) {
      return console.error('Please insert coin');
    }

    if (this.sate !== WAIT_FOR_SELECT) {
      return console.error('Processing existing order');
    }

    let change = this.cents - 1;
    this.itemDespenser.despense(item, err => {
      if (err) {
        console.error('Error dispensing item');
        change += 1;
        return;
      }

      this.change.return(change, err => {
        if (err) {
          this.break(err);
          return;
        }
        this.state = IDLE;
        this.dispatch();
      });
    });
  }
}

I think I got it right. But who knows, you wouldn't know by reading the program, you'd need to write a lot of unit tests to convince yourself that it works. And then write some pseudocode in comments to explain what you intended to do here for future programmers. But even then there is room for failure. One of the subcomponents can call our callback multiple times causing all kind of failures to happen.

Now that we've explored how hard building something -- that is conceptually easy -- using callbacks can be. Let's try with a better concurrency primitive, namely async functions.

If you're not familiar with async functions, read this intro first.

Here's how we'll structure our code for the async version:

• We'll be using a data-structure called PromiseQueue (it's really simple and can be implemented in ~20 lines of code)
• A PromiseQueue has two methods put and get. get would return a promise that can only be resolved once we put something into the queue
• We'll be using two promise queues, one for the coins and one for the items
• We'll have a main run loop that will run indefinitely or until the machine breaks

class VendingMachine {
  constructor() {
    this.coins = new PromiseQueue();
    this.items = new PromiseQueue();
    this.brokenErr = e;
    this.run().catch(e => this.brokenErr = e);
  }

  coin(coin) {
    if (this.brokenErr) {
      return console.error('Machine broken', this.brokenErr);
    }
    this.coins.put(coin);
  }

  select(item) {
    if (this.brokenErr) {
      return console.error('Machine broken', this.brokenErr);
    }
    this.items.put(item);
  }

  async run(item) {
    while (1) {
      let cents = await this.coins.get();
      let item = await this.items.get();
      let change = cents - 1;

      try {
        await this.itemDispenser.dispense(item);
      } catch (e) {
        console.error('Error dispensing item');
        change = cents;
      }

      try {
        await this.change.return(change);
      } catch (e) {
        console.error('Error returning change');
        throw e;
      }
    }
  }
}

Look how beautiful this is. Everything you need to know about the program you'll know by reading the run function. A single function that reads exactly like how we described the machine should work. We are even using elementary control flow, like try/catch, and while loops! What's more, the entire state of the machine are basically local variables. That leaves less room for races to happen. Which brings me to the conclusion:

Co-routines are to state machines what recursion is to stacks

Co-routines are the generalized form of async functions. Where async functions can only pause execution while waiting on a promise, co-routines allow multiple entry points for functions to suspend and resume execution. ES6 generator functions are an example of a generalized co-routines. So, similar to how recursion can help process nested data-structures without using explicit stacks, co-routines helps solve problems involving state without using explicit state machines.

C++

C

Ruby

Python 3

Node

Go

Java

Command Line API

Started by Firebug and currently implemented in all browsers with a debugger. It has many useful utility functions such as $, $0, keys, values etc. and I highly encourage you to learn everything about them.

Until recently, Chrome DevTools didn't implement the full API, and even after they did, a lot went undocumented. The most useful of those functions are:

debug and monitor

If you basically live in the console like I do you'd want to be able to add breakpoints to function references without having to go to the source and find the function, especially when debugging production apps with minified source or built source with no source maps.

debug(ExampleApp.exampleFunction)

Now every time the ExampleApp.exampleFunction is called the debugger will be invoked. To turn it off simply call undebug on the same function.

However, you often just need to know if the function was called and the arguments passed to it, for that you can use monitor and unmonitor.

Setting up traps

When working on a complex system with many modules, it's impossible to know what every part is doing. Beyond the typical console.loging and breakpoint insertion, a good debugging technique is setting up traps with debugger statements to stop and get an idea of what's going on.

Just debugged a link-not-working issue by doing Event.prototype.preventDefault = function () { debugger; };. Feeling pretty smooth.

— Domenic Denicola (@domenic) March 7, 2014

For a long time I've had a library of functions that I copy-pasted around to help set up traps. But after a round of polishing I'm releasing it as a stand-alone JavaScript library and a chrome extension called Debug Utils. You can find it on GitHub and can install it directly from the Chrome Webstore.

Enter DebugUtils

Break on native method call

Unfortunately debug and monitor don't work on native methods so you need to wrap native methods with functions containing a debugger statement, similar to the tweet above, except you probably would want to call the original function after the debugger statement. In DebugUtils this is called $dum (short for debug utils method).

$dum(Event.prototype, 'preventDefault');

Break on custom events

The Command Line API provides a monitorEvents function which is great for debugging DOM events, but it won't work for custom events. For that you want to setup your own debugger or logger function as a handler to an event on an object. In DebugUtils this is called $duv (short for debug utils events).

$duv(exampleModule, 'data');

Break on property access

Often times, objects can start changing from under your feet. You can setup object getters and setters containing a debugger statement to find out what part of the code is responsible. When something changes a given property on your object you will stop and be able to trace back what's changing it. In DebugUtils this is called $dus:

$dus(exampleObject, 'someProperty');

You can also break on property read using $dug.

For more documentation and information on DebugUtils, be sure to check out the Github project. Happy debugging!

Edit: My EmpireJS talk on this subject

I built a JavaScript VM and debugger in JavaScript. Checkout the example in the demo app and the source code. Read on for a dive into the technical details.

Update: I implemented one of the examples from Bret Victor's Learnable Programming using debug.js.

Introduction

Motivation

For the past few years I've been working on creating tools to help people learn programming on the web. I've worked on repl.it and open sourced the underlying technology which powered a few learn to code websites and until recently lead product engineering at Codecademy. Through all that, one thing I really wanted to see are the tools to make it possible to visualize code execution and step through code in the browser. To catch glimpse of what an ideal interactive learning environment would be you should check out Learnable Programming by Bret Victor.

In addition to the educational benefits of such a tool, if matured it could be also useful for code instrumentation, web IDEs, and creating a foundation for writing other VMs on top of JavaScript (having the pausable machine state let’s you not worry about the non-blocking environment).

Ever since I've read about the ES6 Generators proposal, I've been toying with this idea in my head but it wasn't a real possibility until Ben Newman’s Regenerator brought generators to the browser.

Goals

• JS VM capable of running ES5 code
• VM should be pausable on any instruction
• Ability to create a feature complete JS debugger on top of the VM
• Mainly targeting browsers but should work in Node.js for development

Generators

if you're familiar with generators, feel free to skip this section or read this instead for a more comprehensive introduction

Generators are part of the ES6 proposals and is making it's way slowly into production environments. Generators gives us a new type of functions where we can step in and out of a function while sending and receiving values to and from it.

The following example should illustrate the fundamentals of generators:

function* genFn() {
  var x = yield 2;
  yield x;
  return 'done';
}

var gen = genFn()
console.log(gen.next());  // {value: 2, done: false}
console.log(gen.next(1)); // {value: 1, done: false}
console.log(gen.next());  // {value: "done", done: true}

Notice the * at the end of the function keyword, that's all you need to create a generator.

Overview

Having the unique ability of suspending execution of a function and resuming at a later point in time, generators gives us the basic building block for creating a VM that can step through instructions and pause at any point. To achieve that, every function in the system must be transformed into a generator that yields to the machine before every instruction execution. This may sound similar to Continuation Passing Style with a trampoline, however, the main difference is that the call stack information in CPS is held in the lexical scope whereas in this method we need to take full control of the call stack. I'm not a compiler nor a PLT expert so I'm not really sure if this method has a name or if it has been tried before, if you do please let me know.

We want the host JavaScript environment to take on as much of the responsibility of running code as possible. Beyond generator function transformation we have to do a few other things which I'll outline here and get into each later.

• Control the call stack
• Handle errors and error propagation
• Control timers in the system (setTimeout, setInterval etc)
• Workaround native APIs that expect function arguments (callbacks and not generators)
• Write a debugger module

Code Transformation

In order to control the execution flow we need to yield back to the machine after each instruction execution. To do so, we take each instruction in our program and insert a yield expression before it. I chose to define an instruction (or a step) as a single JavaScript statement.

For example:

var foo = 1;
if (bar === foo) {
  foo = 2;
}

After the transformation:

function* __top() {
  yield {step};
  var foo = 1;
  yield {step};
  if (bar === foo) {
    yield {step};
    foo = 2;
  }
}

In addition to the basic instruction transformation we need to add information about each function in our program that would be useful when building the debugger. We call this, a stack frame and it includes the following data about our function:

• name
• filename
• scope: an array of variable names and their occurrences in the function.
• eval function: this gives access to the function's closure to do things like watch expressions and eval code in that scope.

Finally, function calls are a bit trickier than regular instructions since we need to capture the call stack and play nicely with native and library function calls. On compile time, at the function call site, we don't know whether a function call is referencing a generator function (a function within our ecosystem) or a function object. If it was the former, we need to add it to our call stack and step into executing the function instructions, as for the latter we simply need to get a value out of it. We solve the issue by wrapping all function calls in a thunk and yield it back to the machine to make that decisions on runtime (where we have more information).

“Thunk” is a fancy word for something JavaScript programmers do all the time -- create a closure that delays the computation of a piece of code. To illustrate:

foo();

Becomes:

yield __thunk(function *thunk() {
  return foo();
}, this, arguments);

A more complex call expression would also work:

for (var i = foo(), b = bar(); i < 50; i++);

Becomes:

for (var i = yield __thunk(function* thunk() {
  return foo();
}, this, arguments), b = yield __thunk(function* thunk() {
  return bar();
}, this, arguments); i < 50; i++);

this and arguments are passed down so we can create the correct scope when invoking the thunk.

VM

Stepping and The Call Stack

Our machine's main responsibility is to invoke, push, and pop functions off the call stack. It starts out with a halted (or idle state) until we eval a string of code which is transformed and converted into a top-level generator. Then, we can call step on the machine and expect it to run the next instruction in our code via the generator next() method. If that instruction returns a thunk, we evaluate it and if it returns a generator we push it onto our call stack and any further steps will be invoked on it. When our current peek generator is done stepping we take the last value and pass it back into the next generator on our call stack. The passing is also done via the generator .next function which accepts an argument to be sent into the generator function.

Errors

When invoking an instruction, there is a possibility it could throw an error. The way we deal with that is we try/catch every instruction invocation and if we get an error we pass it up the call stack incase one of the caller functions have try/catch statement waiting for us.

Runner.prototype.$propError = function (e) {
  while (this.stack.length) {
    this.gen = this.stack.pop();
    try {
      this.gen.throw(e);
      return;
    } catch (e2) {
      e = e2;
    }
  }
  throw e;
};

Timers

One of our goals is to be able to pause our machine at an point in time and for as much time as needed. Because of that we run into the problem of not being able to rely on the host JavaScript environment for controlling timers. e.g. we have a setInterval running with a second in between and we decided to pause the machine for 10 seconds, when we resume we shouldn't expect 10 back-to-back timers to trigger. The machine time should only be running when:

1. We are executing instruction code.
2. We are in idle state (the call stack has unwinded and the machine is in a halted state).

We use a priority queue to store our timers and have a tick method that checks if there are any timers that should fire at that point in time. We rely on the host setImmediate or setTimeout(tick, 0) to provide us with our tick function.

When a timer fires the machine simply triggers timer event and clients could react by running or stepping through the timer (thus creating a new call stack). This is very similar to JavaScript event loops but very specific to timers.

Native APIs

We can't expect every API our code touches to understand how we do things using generators so the machine provides a way to wrap callbacks and yield them back to the machine to further step through them. However, a problem arises when we consider synchronous APIs that expect callbacks, for example Array.forEach will call the callback continuously until the iteration finishes and that's a problem because we expect to be able to pause any execution indefinitely. For that reason, we can't rely on the host environment native APIs to do the same thing. Luckily, this turns out not to be very hard to solve. All it took is taking the popular es5-shim library and running our transformation on it so it become generator friendly.

Events

Much like the the Native API problem, events expects event listeners made of functions, but this is a much simpler problem because this is an asynchronous API and all we have to do is wrap our listeners with a function wrapper that would trigger our machine whenever it's called.

Debugger

After creating the VM, writing the debugger was fun and relatively straightforward. The only issue I ran into is handling all the thunk garbage we have in our call stack because we treated them just like any function call to make the machine simpler.

Features:

• Breakpoints
• Debugger statements
• Step in, out, and over any statement
• Get scope variables and values
• Get call stack
• Eval in scope: whenever you on a breakpoint you can evaluate in that scope

Check it out here.

Current status

The project is still in early development stages. I’ve only been working on it for about two weeks. In terms of correctness, I’m sure the VM can run most of the ES5 spec. One thing that came to mind while writing this post is that getters and setters are definitely broken at the moment.

The VM is currently very slow, especially the code transformation bit but there are a few quick wins to be had there to get it to an OK speed.

I also realize that the generator transformation is just an intermediate step to the transformation that Regenerator does to be able to step in and out of functions freely. Therefore we could get rid of that step and transform directly to the state machine.

• TameJS
• Narrative JavaScript
• jwacs and the list goes on...

In the VM

You maybe asking yourself what kind of asynchronous operations would an interpreter need to do in the first place. Good question! It's always good practice to put computationally heavy programs in Web Workers and that include VMs which makes interactions with the UI thread asynchronous, which for the most part, is ok, except to when it comes to user input. Most would expect it to be blocking. Also having the ability to pause and resume execution at any point in time would open the opportunity to create debugging tools like a stepping debugger.

One thing you can and many already do is design your VM with a yield state. But that doesn't really apply when implementing an X-to-JavaScript compiler or when compiling interpreters from other languages to JavaScript or when writing simple interpreters without really implementing a full blown VM.

Case study: BF Interpreter

For the following section I will use a brainfuck interpreter to illustrate the problem and part of the solution.

BF Interpreter

The function bf takes a string made of characters representing a BF program and runs it. You do not need to know what all the operations in the BF interpreter are but note that the input command , asks for user input.

// Adapted from http://code.google.com/p/jslibs/wiki/JavascriptTips
function bf (code) {
  var codeLength = code.length

    // Code pointer
    , cp = 0

    // Data pointer
    , dp = 0

    // Tape.
    , m = []

// Loop start and end positions.
    , loopIn = {}
    , loopOut = {}

// Match [].
    , stack = [];

  // Register loop jumps
  for (var cp = 0; cp < codeLength; cp++) {
    if (code[cp] == '[')
      stack(cp);
    else if (code[cp] == ']')
      loopOut[loopIn[cp] = stack()] = cp;
  }

// Execute.
  for (var cp = 0; cp < codeLength; cp++) {
    switch(code[cp]) {
      case '>':
        dp++;
        break;
      case '<':
        dp--;
        break;
      case '+':
        m[dp] = ((m[dp]||0)+1)&255;
        break;
      case '-':
        m[dp] = ((m[dp]||0)-1)&255;
        break;
      case '.':
        console.log(String.fromCharCode(m[dp]));
        break;
      case ',':
        m[dp] = prompt('input').charCodeAt(0)||0;
        break;
      case '[':
        m[dp]||(cp=loopOut[cp]);
        break;
      case ']':
        cp = loopIn[cp]-1;
        break;
    }
  }
}

Now the above is a synchronous BF interpreter written in JavaScript and it uses prompt for input (,) which is the browser's native blocking stdin. Loading it in the main browser UI thread would work, however, running large BF programs would cause it to block and hang your tab or browser. Loading it in a Web Worker would not work either because Workers do not have access to the window obect.

CPS'ed BF interpreter

We can try fixing the interpreter by making the input operation a non-blocking call that takes a callback to continue the program after input was recieved from the user from the UI thread, via the Web Worker message API. let us assume this has been already implemented for us and we can use: console.input.

You would quickly notice that having an asynchrounous operation is infectious and it would force us to restructure our program into a CPS style.

Note that This could be further simplified but it's left to demonstrate the point.

function bf (code) {
  var codeLength = code.length
    , i = 0, cp = 0, dp = 0
    , loopIn = {}, loopOut = {}, m = {}
    , stack = [];

  for (var cp = 0; cp < codeLength ; cp++) {
    if (code[cp] == '[')
      stack.push(cp);
    else if (code[cp] == ']')
      loopOut[loopIn[cp] = stack.pop()] = cp;
  }

  var ops = {
    '>': function (cont) {
      dp++;
      cont();
    }
  , '<': function (cont) {
      dp--;
      cont();
    }
  , '+': function (cont) {
      m[dp] = ((m[dp]||0)+1)&255;
      cont();
    }
  , '-': function (cont) {
      m[dp] = ((m[dp]||0)-1)&255;
      cont();
    }
  , '.': function (cont) {
      console.log(String.fromCharCode(m[dp]));
      cont();
    }
  , ',': function (cont) {
      console.input(function (data) {
        m[dp] = data.charCodeAt(0) || 0;
        cont();
      });
    }
  , '[': function (cont) {
      m[dp]||(cp=loopOut[cp]);
      cont();
    }
  , ']': function (cont) {
      cp = loopIn[cp]-1;
      cont();
    }
  };

  function noop () {}

  function runNext () {
    cp++;
    if (cp < codeLength) {
      (ops[code[cp]] || noop)(runNext);
    }
  }
  cp = -1;
  runNext();
}

Notice how every function in the system receives a callback function which is responsible for continuing the program. The callback maybe called with values that would've rather been return values. In our case, there exist no need for return values because state is encapsulated within the bf function closure.

By doing so We eliminated the need for a JavaScript runtime call stack, as each function would be responsible for continuing the execution of the program. Which means each function has the power and ability to stop the execution (maybe wait for an event to happen) and continue at a later time. Which I think is freeing.

Blow it up

Even-though we don't need an actual call stack anymore because every function call in our program is the last statement in it's caller function that would be responsible for continuing it's program after it finishes executing. However we are still bound to the runtime's call stack, that would be exhausted as soon as we try to run a non-trivial BF program.

Luckily in functional programming there is a technique called trampolining that would help minimize the call stack size needed to run programs written in CPS. It works by having a loop that is responsible for calling the program's functions that would in turn return a continuation function to be executed by the same loop.

function bf (code) {
  var codeLength = code.length
    , i = 0, cp = 0, dp = 0
    , loopIn = {}, loopOut = {}, m = {}
    , stack = [];

  for (cp = 0; cp < codeLength ; cp++)
    if (code[cp] == '[') stack.push(cp);
    else if (code[cp] == ']') loopOut[loopIn[cp] = stack.pop()] = cp;

  var ops = {
    '>': function () {
      dp++;
      return runNext;
    }
  , '<': function () {
      dp--;
      return runNext;
    }
  , '+': function () {
      m[dp] = ((m[dp]||0)+1)&255;
      return runNext;
    }
  , '-': function () {
      m[dp] = ((m[dp]||0)-1)&255;
      return runNext;
    }
  , '.': function () {
      console.log(String.fromCharCode(m[dp]));
      return runNext;
    }
  , ',': function () {
      return function () {
        console.input(function (data) {
          m[dp] = data.charCodeAt(0) || 0;
          run(runNext);
        });
      };
    }
  , '[': function () {
      m[dp]||(cp=loopOut[cp]);
      return runNext;
    }
  , ']': function () {
      cp = loopIn[cp]-1;
      return runNext;
    }
  };

  function noop () {}

  function runNext () {
    cp++;
    if (cp < codeLength)
      return (ops[code[cp]] || noop)();
  }

  function run (cont) {
    // Trampoline.
    while (typeof cont === 'function') {
      cont = cont();
    }
  }

  cp = -1;
  run(runNext);
}

A glimpse into the future

Things should not be this hard. JavaScript must grow as a language to allow constructs that makes it easier to write asynchronous programs. In addition to the web finally realizing the dream of being the application platform, JavaScript also plays a strong role in evented-io server programming which had proven to be quite efficient.

Let us take a look at using generators to emulate coroutines that will land in the next version of JavaScript, ES Harmony. The following example is written using the excellent task.js library:

function bf (code) {

  // Create a task that could yield.
  task.spawn(function () {
    var codeLength = code.length
      , i = 0, cp = 0, dp = 0
      , loopIn = {}, loopOut = {}, m = {}
      , stack = [];

    for ( var cp = 0; cp < codeLength ; cp++ )
      if ( code[cp] == '[' )
        stack.push(cp);
      else if ( code[cp] == ']' )
        loopOut[loopIn[cp] = stack.pop()] = cp;

    for (var cp = 0; cp < codeLength && i < 100000; cp++, i++) {
      switch(code[cp]) {
        case '>':
          dp++;
          break;
        case '<':
          dp--;
          break;
        case '+':
          m[dp] = ((m[dp]||0)+1)&255;
          break;
        case '-':
          m[dp] = ((m[dp]||0)-1)&255;
          break;
        case '.':
          console.log(String.fromCharCode(m[dp]));
          break;

        // Yield to the event loop until we get the user input.
        case ',':
          m[dp] = yield console.input();
          break;
        case '[':
          m[dp]||(cp=loopOut[cp]);
          break;
        case ']':
          cp = loopIn[cp]-1;
          break;
      }
    }
 });
}

What's more, ES Harmony will also include tail call optimization.

A Shameless Hack

To get input on the emscripten compiled languages on our repl.it project we considered using a CPS code transformer like the above-mentioned list but the approach failed for the following reasons:

1. Compiling language interpreters to JS using emscripten generates lots of JavaScript which when ran against these compilers takes forever.
2. JavaScript is not tail call optimized; and this is bad because compiling to CPS means functions would be used for control flow, a whole lot of them. However I think some transformers do use clever tricks to minimize call stack.
3. Performance hit which is for the most part from the cost of creating and invoking a lot of functions.
4. Adding an additional compile step makes it even harder to debug.

So we took the easy way out and hacked the hell out of it. After thinking for a while about the problem of what in essence is resource sharing across threads which is prohibited in browsers for the added complexity and the security concerns of the web. I had a crazy idea of using the Web SQL Database to share data between the Worker and the UI thread since it has a synchronous worker API. While I'm sure this hack doesn't make threads share memory but is fast enough for stdin. The busy loop count (100000000 in the code below) is tuned and maybe tuned further to get faster results.

When the language interpreter in a Web Worker hits an input operation it will stop execution, ask the main thread for input via a message, and busy loop while polling for changes in a Web Database table:

var DB = self.openDatabaseSync('replit_input', '1.0', 'Emscripted input', 1024);
var input = function () {
  self.postMessage('stdin');
  var t = null;
  DB.transaction(function (tx) {t=tx});
  var i, res;
  while (!(res = t.executeSql('SELECT * FROM input').rows).length) {
    for (i = 0; i < 100000000; i++);
  }
  t.executeSql('DELETE FROM input');
  return res.item(0).text;
};

And in the UI thread:

worker.addEventListener('message', function (e) {
  if (e.data === 'stdin') {
    console.input(function (data) {
      DB.transaction(function () {
        tx.executeSql('INSERT INTO input (text) VALUES (' + data + ')', []);
      });
    });
  } else {
    // Do other stuff
  }
}, false);

The Web SQL Database spec is deprecated for the IndexedDB which has not fully landed in browsers yet but this approach, in theory, should work with it.

Why all this?

I ran into these issues during my work on repl.it last year. And my recent on and off work on allowing debugging JavaScript in the browser at codecademy.