Hacker News Reader

Comment by z9znz | Hacker News Reader

What a remarkable coincidence. I was just looking at alternative terminals today and saw warp.

I like what they are doing. And like copilot (which I'm not a fan of, but I understand the goal maybe), I think it is leaning toward the real issue - we waste energy solving the same problems over and over.

Instead of helpers which enable us to reinvent wheels, we should be directing our efforts toward establishing a collection of pattern solutions and tools to compose those solutions into bigger ones which solve specific needs.

In the terminal, there are certainly a limited set of things we do repeatedly. In fact, much of what we do in the terminal can be done elsewhere (UI); it's just slower or more tedious due to clicking. It's also less easy to automate. But the intentions behind the actions are the same. "Create a new directory <here> name <name> and execute this <script>". Perhaps the biggest challenge is just in naming and organizing.

View on HN

Hey there! Advait here - author of the blog above. That's awesome to hear, hopefully you enjoy trying out Warp and switch over to it full-time ;)!

That's an interesting point you raise - definitely agree that there's tons of wasted efforts solving the same problems multiple times. With Warp, the eventual hope is to build an ecosystem for developers to be able to collaborate with each other and build reusable extensions directly on top of the terminal, to help address the concerns you mentioned.

Though, fostering this environment for collaboration can be quite difficult - in your experiences, what do you think would work well for creating such an ecosystem, where we can prevent duplicative work and encourage sharing?

How to create an ecosystem, I'm not sure (although discussions like this on HN would go a long way).

But how to identify common patterns of problems? I think we just need to make an effort to zoom out and consider the phases of software development and infrastructure management we do, then look for similarities.

For example on the web development side, we routinely build web application foundations which require authentication (and less often but also authorization), state storage (database backends), and presentation layers. And yet, unless you start with something like Wordpress, there is little out there which provides a fundamental foundation with modular extensibility.

From a terminal perspective, we manage processes - start/pause/kill, we check states - active network connections, running processes, resource consumption levels, and we do ad-hoc data processing (piped unix commands, but typically in service of one of the previous two categories of needs).

In my work, I commonly use tmux to keep sessions open for different constant needs like psql shell, tail -f of logs, and other routine system management tasks. Most of these could be modules enabled and configured within a management system. I'm sure plenty of other people here have built their own scripts to do exactly this, especially for text or tiled UI systems.

Yep, ahaha - creating an ecosystem is a massive undertaking but an interesting topic to dive into.

Agreed - I like the aspect of trying to distance ourselves from the existing paradigms and modularizing the world. It'd be insanely awesome to have a common space to share these creations - I guess GitHub is one of the ways to do this but stuff definitely isn't as cohesive as you'd want it to be, in that each solution isn't meant to easily work with others. App-specific extension stores get closer to this vision but are limited to a specific application.

This gets me thinking about whether it'd make sense for software to have more standardization, in the same vein as ISO standards but with a focus around interoperability between such modules? However, standardization also brings a lot of drawbacks, as we've seen with ISO or ECMA's committees where bureaucracy blocks innovation, hence I'd be both excited and wary about authoritative universal software standards.

It's interesting to see that in the hardware space, we see the issue of interoperability being tackled more broadly due to the limitations of "needing" to be compatible with other pieces of hardware, for many use cases. Though, you always have proprietary standards within this space as well.

Reply on news.ycombinator.com