Not to be critical but I clicked thru to another article, 'Ai makes sitting with discomfort shameful' and I still don't get it. I don't understand the need to cry about a completely optional tech. Especially when, if yu love it so much and are forced to use it at work, yu can just ionno use it whenever else you have more control over your own agency? Coding and learning is hard but now they both got easier. What's all the romanticising the grit around programming when yu can very optional still go eat granite of that's what you're into. Really, it's beginning to feel like, 'turn on your camera with tears in your eyes and talk about how you're crying'
No offence truly but crying over 'optional' is weird
Not sure how you're missing it. He's making a distinction between the concept of a Project and a Product. I agree with the distinction and he seems to be saying that the author has the wrong concept of what a product is but to answer your parent comment is saying that there's no difference between a vibe coded thing and a 'real' product so long as there has been some satisfactory transfer of agency and an exchange between user and product creator at any scale. So he's essentially saying that the author may be conflating vibe coded PROJECT (with a vibe coded PRODUCT) and that if so comparing a vibe coded PROJECT with any 'real' (whatever that means) product is an unfair comparison and on the flip side if they're comparing vive coded PRODUCT with a real PRODUCT then they're one and the same thing from the perspective that there was an transfer of agency and utility has been exchanged between user and product creator. I happen to agree with parent comment. It's an airtight argument that it doesn't matter how yu made it. The distinction between vibe coded and 'real' product is fuzzy at best. The real distinction lies between a PROJECT and a PRODUCT.
Absolutely ABSOLUTELY love the idea and the first thought I had was Virtual Desktops! If that's a correct way to think about it then I can absolutely see myself using each tile (Desktop/Monitor to me) to contain a single thread of work.
I don't use agents at all and I think that building agent/Ai-first is gonna push away people like me (who don't want to deal with agents or any related concept or even git tbh). I'd genuinely say generalise into a Virtual Desktop typer thing.
In your blog, you mentioned that each tile is sorta like a computer (sandbox?) in itself actually containing AND running the work. That's brilliant! Now, if you could make it possible that one single tile could fill the entire screen, like a typical desktop view, on demand. Incase I just want absolute focus on one thing (I'm not always looking across all three monitors) and not be in 'Canvas mode' seeing all my Virtual Desktops.
I could also see myself working across three (or more) tiles where I've got docs in chrome, vs-code open in another and something else (more docs? Terminal? Doesn't matter). Fact is that the infinite canvas literally replaces me having to buy two - three monitors to get the same feel. I could now buy a single large curved one and have infinite monitors.
I had an inkling of this feeling when I saw Omarchy (A tile-based Linux distro from Basecamp / 37signals). What I thought was missing was infinite-ness and a little spatial something? I actually literally thought, what if those tiles didn't squish together like that and the BG were a 2D infinite canvas?
If you pull this off just right and actually focus on getting the desktop version right first (I believe that's where your users are), I believe you may have stumbled onto a different kind of operating system paradigm for a workflow issue we try to solve with even more physical monitors.
I never shut off my PC so I can imagine long lived virtual monitors wayyy off in the canvas ether with all that work still open and waiting until I'm ready for that frame of mind.
I don't have anything to say about the disappearing message except that it's cool as a way to ping or get someone's attention but a dedicated chat box? window? Just a little foldable flourish in the bottom left or right corner so yu can directly 'chat' with someone persistently who's in your space (or you're in theirs) is way more healthy for a serendipity than a disappearing message where it's kinda like an implicit race condition and loses the asynchronous nature of letting me consider a text before I reply especially in work settings. I'd also not want to give access to my entire canvas ether as opposed to selectively allowing access to specific virtual desktop lol
As for 3D? Meh I don't know. Don't need that but other people may like it. I'm just approaching this from a workflow angle. Love the whimsy regardless.
I absolutely want this, I would absolutely pay for this, I think this is a great product in the Figma range and I absolutely wish you all the best of luck because this is awesome. Just focus on the operating system /workflow angle for a desktop use-case first. I couldn't try it (don't have a Mac) but I got the idea from the video.
Good luck, guys! And ykw? I wonder if I could fork around with Omarchy and give it infinite canvas since it's already 95% there. Never mind the social feature or 3D graphics yet.
Hey, author here. Thanks for the feedback! The goal definitely is to focus on the core. I mentioned this in the video, I like to think of this as a (multiplayer) work sandbox. I'm really curious about all the different workflows people have/ could build.
I kno you're not suggesting the visual system would drive coding at all or that it'd be a way to visually code (see: scratch). You seem to mean it as a visualization of the current code base. I'm hoping Google's code wiki is the first step in this direction. One thing I always thought was a problem with visual systems like this was understanding the codebase's architectural design at a level yu can't programmatically get out via a syntax tree analysis. Google's code wiki seems to be using an LLM to figure out the high-level structure of the code and then building the flowchart and diagrams from that understanding. Obviously there's gonna be issues and misunderstanding but I think that's the first step in the direction you're talking about. First it's text, mermaid diagrams and 2d. Next it's a 3d visual world of your codebase. AWESOME stuff. Someone @ Google.
'in->func()->out' work cleanly for physical engineering domains because blocks of computations (or functions) have no memory basically. There's no DB and there's usually no global state in the way you'd mean with classes. I've observed that when you work on complex software, you could play by the ear to enforce 'high cohesion and loose coupling' up to the point to where you've now got a data store holding system state. Based on what I've worked on, this system state is actually user data and then some derivative of the system's own interaction on this user data, both of which are necessary for the 'continuity of system runtime'. For example, working with redis as the primary data store, I extracted different types of redis calls for specific keys, (like set [specific_key], get [specific key], etc.) into functions, then I put these functions into a StateStore class so I can simply call StateStore.get_user_data() or StateStore.set_user_data() etc from any module across the entire system. From first principles, this is great modularity and high cohesion but it's very tight coupling around a single module i.e. StateStore. Any change in that module means I'd have to find all references for that updated function and cross check for any contract violations.
It's difficult for me to see how software can purely be 'High Cohesion and Loose Coupling' regardless of paradigm or architectural pattern. There's always gonna be an unavoidable and inevitable principle violation that's simple a result of a large complex system actually doing many little things that come together to actually do one big thing. The software itself, no matter how complex, IS the blackbox where data goes in and something comes out but that's the user perspective not ours as the programmer.
I think the idea I'm trying to hint at is that software cannot have every module independent of every other one. That's impossible. If nothing depended on anything else, the system wouldn't do anything. Rather than have every module know redis keys, States tore actually concentrates coupling into one place, which is exactly what high cohesion tries to accomplish.
I think that's the idea I'm chasing.
It's not really true that components in physical engineering domains have no memory. The behavior of many physical components can only be described with access to a recent history. Other components, specially controllers, are typically state machines (which obviously have state).
But it is true that there will always be parts of a software system that are highly coupled. I'm not even sure if that's even a problem, unless the coupling is also highly tangled (meaning the connections are coming from too many places).
But if you want to decrease coupling between parts of a system, OOP by itself is not particularly good at it. Even something like an Entity Component System is usually less coupled than most OOP codebases because while each System is heavily coupled to the components they do work on, the Systems are usually fully independent from one another and easily replaceable.
Yeah you're right. It's an oversimplification to say components in physical engineering domains have no memory. I was thinking about how logic gates are reasoned about. But that's not the exact point... It's that the argument is usually that OOP cannot decrease coupling. I can't see how exactly. OOP seems to strike a balance between good enough modularity and expressive power enough to keep your system directionally loosely coupled. Infact, I'd say that, I my experience, lots of the coupling between modules is inherent to the 'specifics' of the system's design requirements itself. This is where sometimes within the same logical subsystem/component you could find multiple design patterns all deployed in the bid to reduce coupling. I don't think this is OOP's fault directly as opposed to the 'devil that is in the details'. But maybe I don't have enough experience or exposure yet (I'm a 2nd-year junior)
No it is not a fault of OOP, it is just that OOP does not really provide the tools to help either. It is the fault of people with the wrong expectations or of those trying to sell snake oil.
OOP allows to create decoupled systems but it doesn't help in creating them. It is not an inherent property of the paradigm, but many people sold it as such.
"Use OOP and your application is now magically more modular! Buy my latest book to find out how!"
Since you mentioned you are a junior I guess this sort of nonsense is from before your time. No worries, that just means you won't have stupid dogma shoved down your throat. Use whatever paradigm if it helps you and avoid whatever gets in the way.
reply