> That's true, but most people don't know the numbered manual sections, so they get the docs for the cron table command not the cron table config file.
Aren't those startups the ones wanting a google style infrastructure based on kubernetes with database sharding, an event-source architecture,... And when you told them a few VPS with postgres would have sufficed, they absolutely insisted that unless it's a next.js app backed by a serveless ecosystem and tens SaaS, they couldn't build their products?
> I can do an experiment, show it to coworkers and get feedback in a morning, for something that would have taken me almost a week in the past.
That argument always rings hollow to me. What systems were you prototyping that took that long? I don't need to build a complete MVP to present a design. Or understand an API.
In the visual art industry, there are thumbnails and storyboards that are the first iteration of any project. They are quick to produce, and can serve as the basis for brainstorming. No one wants a finished picture, because it restrain your thinking. Too much details and you start bike-shedding.
Only when you've solved higher concerns and have a concrete direction that you start to invest physical efforts. But that does require someone to have the capacity to discern higher concerns from crude sketches. If you don't and rely on "I'll know it when I see it", then you sure need finished products to clarify your thinking.
Qt and GTK has bindings for a lot of languages. calibre is Qt built with python. And GTK has GI which allows to basically autogenerate bindings. It’s not plug and play, but it’s not difficult either.
> I've been thinking on and off for a few years now about the idea of a "graphical terminal", sitting somewhere between a GUI toolkit and a terminal emulator and a full blown OS for building inter-composable apps and tools and components that could replace TUI based workflows/apps/layouts. I have a vision of every "pro" app just being a different curation and configuration of underlying components rather than actually separate software.
I'm using cwm (x11) without a compositor (never noticed tearing). And it's so nice when everything is not trying to be cute with shadows, animations and round corners. Animation only makes sense when there's a direct action that controls it (like when swapping spaces or hovering) or the system wanting to inform us (notifications). And it's better be fast. Otherwise it's just visual effects that quickly become tiring after a few days.
> And when you want to search for that one thing that you know got documented somewhere, but can't remember where, how many systems do you have to search?
Not GP, but is that actually a real problem? Take a project like OpenBSD where the code, the bug tracking , and the design discussion happens in different place?
Even in reality, you don’t put the workshop in the conference room.
We are a software dev/consulting company. We have a lot of client repos and a lot of different internal teams. It's a real and significant problem for us and we are a pretty small org.
I've done consulting with bigger orgs (Fortune 500) and the more systems they have the harder it is to find things. It's a problem for them too.
it would be way easier if dependencies were a flat list and not a graph, aka peer in npm parlance. I believe that’s what go does. A library only need to say that it depends 1.x.x or 1.2.x and it’s up to the application to provide it. Conflict is handled manually.
The onus is on libraries developers to cleanup their act. Start vendoring code instead of depending on hundreds tiny libraries.
No `man man`? ;)
reply