Tree-sitter is a really cool project. It’s primarily designed for code syntax-highlighting use cases (in editors and IDEs), but it also exposes a Query API for selecting portions of a parsed syntax tree, using an S-Expression based query syntax.
TreeQuery is a new CLI that makes it easier to run Tree-sitter queries against local source code files. It installs as tq and looks something like this:
I think this is pretty cool. We’re still exploring use-cases and getting a feel for what’s possible to query, go ahead and give it a try! It’s still rough around the edges and more language support will be added soon. See the open issues for a sense of the roadmap.
Yes, this joke has been made before, but I’m serious. In the same way that serverless lets backend developers “forget” about servers, what if “codeless” did the same, but for your application code.
In other words, what if API requests to your service included the code that the caller wants to be executed on the server?
Your backend could essentially become a “runtime” for client-provided code. GraphQL APIs in some ways approach this - the backend is an “execution environment” for a (well defined and structured) GraphQL query. What if the “query language” became another programming language instead?
This is just an example to illustrate the point, use at your own risk!
deno run --allow-net --allow-run --unstable main.ts
Will start an HTTP server that responds to GET requests, parses the path, and runs a Deno subprocess (deno run with no additional permissions) pointed at the remote code specified by the request path. In other words, you’ll be able to:
Which will hit an instance of this service running in Google Cloud Run (a container based serverless platform).
Why not? As more tools make it easier and possible to sandbox external code, maybe this isn’t such a weird (or dangerous) idea.
You only need to update your API runtime, changes to backend business logic can be made in client implementations, which means that…
Clients can call very specific versions of code since the code-to-run is described with the request (pin to a git SHA, version tag, etc.)
Clients can arbitrarily shape the output to their need (only fetch the data they care about, one of the benefits of GraphQL)
No need to agree on explicit frontend <> backend API contracts (beyond the runtime) - frontends can incrementally change the behavior of their backend calls without synchronizing with the API maintainers
Be stricter about API resource consumption (could even be based on request status: auth vs unauthed, paying vs non-paying), timeout calls after N seconds, limit memory usage - treat more like a “cloud service”
Map HTTP headers to ENV variables (or some other place) in the execution environment for contextual information like API keys or auth tokens
Enable (permissioned) access to other backend services - like a database - to use directly in the sandboxed code
Support execution in different languages (WebAssemby?)
The title of this post is extreme, and maybe clickbait-y, but I’ve come to agree with the sentiment. I think it’s made me a better developer.
A manager I know likes to describe software engineers on a spectrum, between “cowboy” and “astronaut.” Cowboys commit to master frequently, leaving a trail of bugs and TODOs. Astronauts ruminate on open PRs for weeks and over-architect for every possible (unnecessary) scenario. Good developers are somewhere in the middle. I’d say the best are the ones who can play both roles, depending on the requirements at hand.
Sometimes you just need to cowboy 🤠 some code to spike an experiment, other times you need to astronaut 🧑🚀 a foundational solution. The extremes are never the answer, but knowing which hat (helmet?) to wear and when is an invaluable skill.
I’d call myself astronaut-leaning, and learning to become more of a cowboy has made me a better developer, which is the sentiment of this post’s title.
Caring less about code doesn’t mean caring less about its outcome. In fact, putting the outcome before the implementation can really unlock you to think about the problems that “matter.” The value your software delivers, not the software itself.
It’s similar to the trap of building what you think your users care about vs what they actually want. No one cares about the abstractions or elegance of the code beneath your product, they care about the product.
Good abstractions, maintainability, elegance, reliability, the “behind the scenes” features of code astronauts like to overthink, can also be the outcome, if that’s what the problem calls for. They just don’t always need to be part of a particular solution.
Learning to care less about code can make you a better developer. It will make you more willing to throw code out to try new ideas, and less likely to get caught up in minutia (though, often it’s the minutia that makes our jobs fun!).