If you want to get into fixed-width character art, I highly recommend doing it in the browser like OP did rather than trying to old school it in the terminal. I have done a little ascii[0] and unicode[1] graphics, and the browser is such a better tool. You can set fonts and proportions and know exactly how things will render for the user. Mouse input, performance profiling and a bunch of other things are just better in the browser. Both of my projects work in the terminal but were browser first.
It is kind of shocking to me how TUIs are enjoying a bit of dev tool renaissance right now when the browser is such a capable platform.
> It is kind of shocking to me how TUIs are enjoying a bit of dev tool renaissance right now when the browser is such a capable platform.
Command line tools (and by extension TUIs) can be used over SSH and don't require messing around with HTTPS certificates. They also have the benefit of having the context of your CWD.
Most reasonable countries have the same defense against that as you get against someone stabbing you. I don't see many security professionals insisting that you have to walk around in plate mail for some reason.
I was pretty proud of my Game of Life & Wireworld implementations for the terminal, with half-character resolution o.o;
Guess I'll have to up my game and start work on Twin Cobra and Dune ][ clones.. now that I've seen it's possible..
Using sprites is clever :-) then I guess that's how these older games worked too.
A couple of years ago I wrote extensive benchmarks on three browser-based rendering techniques: text in the DOM, 2D canvas, and WebGL canvas.
The DOM approach is the purest, as it uses a font, and it can achieve very good performance. The only noticeable slowdown at 60 FPS occurs when the character color changes frequently within each line: each new character needs to be wrapped in a span. 2D canvas is a bit more flexible but not necessarily faster.
WebGL is obviously the fastest, at 1000+ FPS, and pixel fonts can be rendered ultra-crisp as well.
Below is the DOM test for frequent vertical color changes.
Press and hold the cursor over the ASCII output to change the orientation (notice the FPS drop at the top left).
I suspect DOM is probably fast enough for most usecases. For me, DOM only started chugging because every tile (2 half-width characters in hexwalker) was a react element and those would get garbage collected en-masse and cause studder.
> It is kind of shocking to me how TUIs are enjoying a bit of dev tool renaissance right now
For me, it's because I can SSH from my wimpy laptop to systems with hundreds of CPU cores and TBs of RAM - and use the same tools and workflows that I am used to.
In hexwalker, what does the AU/A0 button do? Also is there anything to "do" or is it more of a wanderlust simulator? I found a cave with a coffin but so far no items underfoot to use.
AU/AO are auto explore underworld and overworld and A0 is to stop auto explore. You can click on them in the top menu.
> Also is there anything to "do" or is it more of a wanderlust simulator?
It is mostly just a technology demonstrator for having a hexagonal grid map in the terminal. There is nothing to do. I am prototyping some gameplay features around interacting with the environment, but I expect the end result will be very light weight gameplay that more "A Short Hike" than nethack.
Also had this issue. I have made a meta-task runner to make discovery and running of already defined make/just/task/npm/etc task targets easier called dela[0].
The ergonomics of running tasks are very similar to the article as you can run a task simply by typing the name of the task in your shell without saying "make" or "npm run" or whatever else that is the actual task runner. The difference is that you just have to install dela without having to change anything in the underlying project repository.
There are many ways of making wigglegrams. The first method is to capture multiple horizontally displaced shots together at once. There were cameras designed for this in the 80s that had 4 lenses, with the widest about eye width apart; the intent was for them to be printed as lenticular 3d images. The second is to have a single shot and then synthetically create additional perspective, such as by using a depth map.
I have done both of these. For the first one[0], I used a Nimslo 3D and for the second one[1] I drew with pastels on paper, and then drew a depth map in Photoshop and used it to displace pixels horizontally for the novel perspectives.
The OP's "accidental" wigglegrams are mostly of the first variety but, the horizontal allignment is not locked in and the shots were taken not at the exact same time. That's why the parallax effect isn't as strong and they don't look as good as the first 3 images that came from Nimso/Nishika.
What is intresting is that both of these two methods are relevant in the age of modern iphone. Iphones capture multiple exposures together in live photos, so moving the iphone laterally when shooting creates a "boomerang" wigglegram. Iphones also capture depth map from the LiDAR sensor when shooting in portrait mode.
Between increased hardware capability and genai for synthesizing additional perspectives, we could be living in a golden age of wigglegrams. Alas, they are out of style.
OP’s wigglegrams are fun but a bit jarring; your “at the concert” is much smoother. I wonder how we could bridge that gap. My first thought was to use video stabilization algorithms. I suspect they would either fail do to insufficient frames or remove the interesting movement entirely.
"I always thought that Homejoy were planning to automate as much as possible, if not everything, related to cleaning services using robotics and stuff, and that humans were only a temporary measure while developing technology." -devgutt 2015 [0]
This quote about robots doing home cleaning has been living in my head rent free, and refusing to cleanup after itself, for over a decade. It seemed so crazy to me in 2015 that anyone would seriously consider home cleaning robots to be on a realistic timeline. Yet here we are in 2026 and robots could plausibly clean our homes beyond vacuuming and mopping.
Humans training robots now completely makes sense to me. I think Sunday Robotics use of people wearing "skill capture gloves" [1] that both capture data and limit range of motion to that of the robotic hands is particularly clever. I wish success to both these and other companies in the space, so that someday soon there will be just a little fewer housework around the house, and we move a bit closer to the Jetsons.
> here we are in 2026 and robots could plausibly clean our homes beyond vacuuming and mopping.
It is very bold to just assert this is true. Certainly it will be possible eventually, but there's still _lots_ of disagreement in the industry about what is realistic within 3-5 years. See this rodney brooks article for a good overview of the difficulties: https://rodneybrooks.com/why-todays-humanoids-wont-learn-dex...
The fact that devgutt was talking about this in 2015 gives some hint at its unique combination of [seems really easy] and [is really hard].
That article is a load of baloney, and I wish people stopped posting it around as if it's some kind of gospel.
Modern robots are nowhere near being bottlenecked by hardware. They are all bottlenecked by AI. Today's hardware with perfect AI would absolutely demolish tasks like "clean a house". Today's AI with perfect hardware would still fumble.
We know that because we can't even train an AI policy that would reliably solve tasks in a sim with perfect sensors and perfect execution.
I used to be really excited for stuff like this. Now I realize, home cleaning bots will basically just be cameras in your house reporting back everything it sees to the advertisers/government. Not a very utopian outlook anymore.
At some point you're gonna be able to self host this stuff, which will likely be required for security reasons in some kinds of facilities. Now whether it's open and not spying on you still, that's another question.
Not to mention it directly targets a job category overwhelmingly held by poor and marginalized women, especially immigrants, in order to boost the profits of the automation company and the hotel chains it serves. Destroying the livelihoods of some of the most vulnerable and exploited workers on the planet with no pretense of caring what happens to them or their families.
Any company like this actively working to liquidate entire categories of menial work with no tangible support for sufficient social safety net programs and retraining is both sociopathic and digging its own grave for the inevitable populist backlash against what's shaping up to be the biggest class war in history. It's too broad a change, too fast, and these companies are running society off a cliff with no care for what happens when gravity kicks in. (Apart from the techno-fascists who plan on bunkering down while crushing the desperate masses with surveillance and killer robots, ofc.)
> It seemed so crazy to me in 2015 that anyone would seriously consider home cleaning robots to be on a realistic timeline. Yet here we are in 2026 and robots could plausibly clean our homes beyond vacuuming and mopping.
I don't think that they can plausibly clean our homes. I don't think it's much different from back in 2015 when everyone was talking about self-driving cars and auto-pilot yet here we are over a decade later and nobody is getting into their car and then taking a nap on the way to the office. Most people don't have any kind of "self-driving" car today at all. My guess is that if we have housecleaning robots in 2036 they'll be shitty at it and very much watered down from the Jetsons style future tech companies want you to daydream about today.
The claim was that “nobody” is doing this. It’s weird to split hairs on whether or not the own the car. Who cares if you’re napping in a driverless vehicle on the way to work?
I'm not sure there would even be a market for a much more expensive vehicle that can't drive itself outside of the very small number of carefully mapped out and managed zones they are currently capable of operating in. Maybe in another 10-20 years we'll see some progress but for right now they're still working out how to tell the difference between a flood and a puddle which is a huge problem and only one of countless others they haven't addressed yet while they continue to beta test on a small number of our public streets.
This isn't splitting hairs, it's technology not living up to promises that were being hyped over 10 years ago. In 2012 it was "Everyday folk will have access to cars that drive themselves within five years" (https://www.computerworld.com/article/1526480/self-driving-c...) but nobody today has access to a real self-driving car and even those who live in an area waymo supports aren't your average person, they are the very very small exception to the entire rest of the country (to say nothing about the rest of the world).
You can iif you live in on of the supported cities that is not currently suspended. Waymo is a promising participant here, but it very much isn't at the "just be driven to work stage" for almost everyone.
>You can iif you live in on of the supported cities that is not currently suspended.
Yes. The claim was that “nobody” is doing this today when in fact tens / hundreds of thousands of people are doing this today. The tech is here, next is widespread adoption.
The Jetsons wrecked their world. All housing was on stilts. Flying cars were a necessity because there were no roads, only water. They melted the poles!!
All I’m saying is careful what you wish for. Wish fulfillment is always outsourced to the Djinn.
Agree with you on outdated and upper bounds. However, if users are complaining about the interface being difficult, there is probably something there.
Yes, it makes sense that `uv lock` commands only work the lock file, but users have real needs to upgrade direct and transitive dependencies. For transitive dependencies `uv lock --upgrade-package` works, even if a bit wordy. For direct dependencies, `uv lock --upgrade-package` also works, but doesn't touch `pyproject.toml`, which is much more developer visible. As `uv.lock` package versions get ahead of `pyproject.toml`, `pyproject.toml` becomes a less dependable guide to the surface area of dependencies. A friendly `uv upgrade` command would be nice.
The biggest uv ux footgun I have seen by far is `uv pip`. I have seen a lot of projects use uv correctly with pyproject.toml/uv.lock for development, but then use `uv pip install -r pyproject.toml`, which bypasses uv.lock, in their deployment Dockerfiles and ci tooling. Yes, coding agents are to blame for recommending bad `uv pip` patterns because they have so much `pip` in their training sets, but uv should provide some affordances to protect the user.
Sorry for the rant, uv is a great tool, that I think[0] should be used more! Thank you for your contributions to the ecosystem.
Over on reddit and over here as well people seems to be reacting to the title of the video or the first 5 seconds or just the author. On the original x[1] post however, the top replies are about the subject matter, which is about having agents write tests and refactor code.
And speaking of agents writing tests, I have an ask. The tests agents love to write are in a lot of ways like human written tests, perfunctory and smelly. They are there to check coverage or prompt checkbox, but they barely stress the system under test. I often find that the tests are faking and mocking so many inputs, methods, and side effects, that they aren't testing anything at all. Asking the agent to write the tests first so that they the underlying implementation is more testable has yielded no results.
What has worked for people to get agents to write more testable implementations and better tests?
PS. Reacting to Uncle Bob, I found metric driven agentic refactors just push complexity to outside the scope of the metric. I am finding I need to actively guide the agents for the refactors to actually improve things without increasing the entropy of the codebase.
1) 2008: pip, 2012: Conda, 2018: Poetry, 2021: PDM, 2023: Rye, 2024: uv. A new package manager every few years rather than every few months would be more apt. But, yes I agree we shouldn't tool churn for newness sake.
2) Have you tried uv? The speed is nice, but is not what makes it shine.
3) uv not being written in python is a defining positive feature for it. It eliminates the bootstrap problem of having to get a system python with the right setup before you can run your python manager, virtualenv manager, and finally package manager. I haven't had to debug anyones virtualenv or python version issues in a year.
This is a fantastic discovery! Displaying azimuth in my ascii-side-of-the-moon [0] sounds useful, but then I would need to explain the symbol. I am displaying altitude/elevation below horizon, but there doesn't appear to be standard symbol for it. I checked the tables linked from article and there doesn't seem to be a symbol for it.
Maybe this is the opportunity to invent and suggest a symbol for Altitude?
Yes, the angle above the horizon is usually what is most useful because it is used to find something small but visible. In the case of my ascii moon, the angle below the horizon, is there to explain why something is not visible. The Moon is large enough that people can easily find it on their own if it is not obstructed by the Earth itself.
Consider the Moon as viewed from NYC at time of comment [0], it is hiding below the horizon. If you were to look at my website and then at the sky you might become upset that I am reporting the shape of the moon, but obviously it can't be seen. Hence why the website reports the angle below the horizon roughly half the time it isn't visible.
Adding Azimuth and Elevation when the Moon is above the horizon would be for completionism only and not the real enterprise use-cases served by ANSI compliant renderings of the Moon.
Shouldn't it be the same symbol but turned 90 degrees? Seems to mimic the sextant operation if so. I've always used some set of greek symbols (theta, phi, maybe psi) for these kinds of angles.
Great work! While I was building ascii-side-of-the-moon [0][1] I briefly considered writing my own ascii renderer to capture differences in shade and shape of the Lunar Maria[2] better. Ended up just using chafa [3] with the hope of coming back to ascii rendering after everything is working end to end.
Are you planning to release this as a library or a tool, or should we just take the relevant MIT licensed code from your website [4]?
No plans to build a library right now, but who knows. Feel free to grab what you need from the website's code!
If I were to build a library, I'd probably convert the shaders from WebGL 2 to WebGL 1 for better browser compatibility. Would also need to figure out a good API for the library.
One thing that a library would need to deal with is that the shape vector depends on the font family, so the user of the library would need to precompute the shape vectors with the input font family. The sampling circles, internal and external, would likely need to be positioned differently for different font families. It's not obvious to me how a user of the library would go about that. There'd probably need to be some tool for that (I have a script to generate the shape vectors with a hardcoded link to a font in the website repository).
It is kind of shocking to me how TUIs are enjoying a bit of dev tool renaissance right now when the browser is such a capable platform.
[0] https://aleyan.com/projects/ascii-side-of-the-moon/ [1] https://ytirnity.com/play/hexwalker
reply