Making every feature a plugin is hard -- it requires that the original implementation expose everything possible in APIs to be take advantage of by a plug-in.
Plugins are hard, and very OS dependent. There's plenty about the current system that is fragile, and likely to cause problems. I think it's likely the linker rework needs to happen before plugins can be properly addressed.
The problem if you want to write your own plugin is that the compiler interface is really brittle and not documented properly, so thats going to be a maintenance nightmare.
It's cerainly as sane as sane defaults come, but I agree that if the philosophy is 'everything-as-a-plugin' (another excellent choice for this kind of tool) then everything should be a plugin :)
Now to build something with this, I can see a 'dual write' plugin in my immediate future...
This makes sense. I had been thinking of it as something fundamentally different than plugins. But just "plugins done right" is a lot more compelling to me.
Plugins are half-done feature, I would like for them to finish the implementation across all supported OSes and improve the way the code gets loaded as well.
The problem is that there is a large overhead associated with writing a plugin. Sometimes the things you need to do are as small as copying a file from one directory or another. Having to write a plugin to do something so small is overkill.
The complexity comes with interaction in general. Writing plugins on their own is simple. And defining a good API for most common use cases is also not hard today, as we have enough experience now. But the hard part will be defining an independent Interface which will work everywhere on a satisfying level.
I mean that's basically the biggest selling-point of plugin-systems today. Not that you can write your own functions to do something, but how well you can integrate it into the interface and deliver your own interface to enhance the app. And another part would be safe interaction with other plugins, and necessary package-managment.
Agree with you on that! To my opinion the plugins are the most excising in this version. We are still working on the doc on how to create your own plugins
I've seen this so many times - rather than just write code to do something, wouldn't it be grand if the users could plug their code in with some scripting language or twiddle some configuration and poof! magic! new features just happen!
It's one of those things that looks grand on the whiteboard and fantastic on the slide deck, but holy fucking christ when it comes down to implementing it and moreover, having to support it forever after, the pain spirals. Users can't actually implement their plugins, so you end up writing them for them, in a gimped DSL or scripting language, and all the initial choices that were made become ossified, because you then can't ever risk breaking some potential plugin code out there that depends on the API.
As a developer myself, I was also more than involved in developing the plugin. It's indeed true that it can be a bit messy. But I think the huge ecosystem and customization (through hooks and filters) make up for the sometimes difficult developer experience.
My philosophy is also that 90% of what you would want to do with plugins should be built in, anyways.
reply