That requires architectural work, but they don't want to do that, either.
Discussion
Where can a noob learn more about proper architecture?
Domain Driven Design is one good discipline, i also found another one that is quite useful that nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z talks about a lot, Behaviour Driven Design
at my paid gig the guys who are building the back-end/middleware of our application use both of these techniques in their work also... i honestly haven't studied them hard enough, but i grasp the basic principles reasonably well
DDD is kinda like an elaboration of the Single Responsibility Principle and aims to help meld the expertise of subject matter specialists who have got less software engineering skills with the programmers, project management and ops people
Thanks! Will look into both + search for some Flutter and Go benchmarks.
One of the things you can do, as a Flutter dev, is come up with a Clean Architecture suggestion, that others can use to build with your library, and have a demo system, structured like you suggest.
Then people could fork that and alter it for their own implementation.
> come up with a Clean Architecture suggestion
Aight. Let's do that first then 🥵
Just Googled it. Looks like there's been a lot of legwork already done by other Flutter devs. You could just examine what they've defined and see if that helps you.
🫡
That + nostr:npub1wf4pufsucer5va8g9p0rj5dnhvfeh6d8w0g6eayaep5dhps6rsgs43dgh9 + public documentation towards you guys should do it!
Yes to domain centric design and basic separation of concerns, no to premature optimization and overkill like clean architecture for smaller projects where the boilerplate and indirection make up a lot of the code
Choose names wisely and be clear and consistent. Make code expressive and self documenting.
some time ago I wrote some of what I consider good code recommendations nostr:npub149p5act9a5qm9p47elp8w8h3wpwn2d7s2xecw2ygnrxqp4wgsklq9g722q
note1y9hfddyw2xrt3l50n9pystcc6qn8q5wl3tkg4aa9xky2hvqharkqhdk80q
Yes, I like that!
TDD is 🤌
i am always writing tests because i very often mess things up and do a lot of encodings, but i haven't yet wrapped my head around this BDD style and other protocol correctness
to me part of the problems start before you even get to writing tests, with a protocol that is unclear or breaks domain boundaries or mixes concerns or creates ambiguities, especially ones that are likely to trigger a human to misunderstand even when the logs are printed out ad nauseum
We're solving the protocol issue, slowly. As long as that progresses, I'm okay with it being a bit messy.
Messy implementations are another thing because they send out corrupted events and burn the Nostr brand.
I have never seen Nostr "smaller projects" not become the basis for the Nostr "larger projects". Even major rewrites don't help, for long, as the regressions immediately begin seeping in, and the entire architecture groans under the weight of its own inefficiency and ineffectiveness.
The crappy quality they begin with just stays that way, indefinitely, because those developers refuse to learn better engineering and are actively discouraged from doing so, by people who pay them to stay ignorant and amateurish, so that they can't steal the limelight from the Planned Winner.
It's worth slowing down, refactoring, and retesting as soon as you notice an architectural flaw. The early stages of the project is the best time to do that, because the more code you have, the more time, energy, and risk is required to fix a bad design pattern.
benchmarks? i am just talking about how the Go language makes it easier to throw stuff out fast... it doesn't really force you into good architecture, i think that some aspect of why OOP languages are so wordy is they are trying to do that but it's the wrong place for it
go is unfortunately a poor choice for doing UI tho... there is numerous projects out there but all of them fall down in really big ways... the best one for performance the problem is the devs have architected it wrong... which is my point about how the language itself can do little to stop you making bad designs... i do think that "internal" and "encapsulated" (non-exported) symbols can complicate extensibility a lot but the old days of C++ and now Rust "sAfEtY" which is just a dogwhistle for "you are superior and everyone else is retarded and needs to have guard rails on everything or they will breach your interfaces and abuse your code"
yeah, that's usually because they have created a bad architecture btw
Another good resource is anything from Uncle Bob, especially his "Clean Architecture".
If you think of software development as a learned skill, then the idea of software craftmanship and honing your development operations, can take you a long way.
One of my favorite resources lately has been https://refactoring.guru. It's a great place to survey code organization and design patterns to understand what is available to help solve the problem at hand.
big ball of mud is the name of their game