Slashdot Mirror
On Plug-ins and Extensible Architectures
gManZboy writes "Developers who want a flexible, configurable, IDE have long preferred plug-in architectures such as Eclipse over what they might view as the bloated, monolithic alternatives. Ever wondered how it all works? Well, ACM Queue just posted an article by someone who has worked on Eclipse since its inception, Dorian Birsan. He gives a great explanation of the Eclipse architecture as well as a thorough analysis of things to watch out for when developing or working with pure plug-in architectures."
At least this is the user's choice.
Bloat then becomes a consequence of the user's choices and not something forced upon the user by the developer.
Obama's legacy: (N)othing (S)ecure (A)nywhere and (T)error (S)imulation (A)dministration
Most of you have probably experienced "DLL hell" at some point and will look with suspicion on something that has the potential of being a "plug-in hell."
I think we already passed the potential phase a long time ago. After a while you either give up installing the latest milestone or give up your added plugins.
That was meant to be funny, right? Because few things are as so monolithically all-encompassing as Eclipse.
I should reveal personal bias from the outset: I despite Eclise. Though it sits open in a window just next this one right now, I still loathe it with an utter passion.
I cannot get its editor to put tabs in realistic, predicable places. I don't want my coding environment to start looking like MS Word, underlining things as problems simply because I haven't finished typing thm yet or am concentrating on another part of the design. I had to immediately turn off most of the auto-typing features such as adding brackets or quotes, because I found it vastly distracting. There's a plug-in to search the preferences! My god, that makes it out of control.
I tried to use it at home the other day to import four existing source files and then generate a build.xml file for me. It never even worked out how to import the files with the right directory root, which given a pattern of src/org/eruvia//FileBelongingToPackage.java should have been src, not src/org/eruvia/appname.
Can't stand the thing.
Cheers,
Ian
Does that make it a poor argument?
You can never go home again... but I guess you can shop there.
Oh that makes alot of sense.
How in the hell can you relate a serial killer to fast food? I will not have any sympathy for someone who makes a choice to put food in their mouths they know will kill them eventually.
You go to their place of business and order food that unless you are a complete dumb ass you know what you are getting. Stop trying to make excuses for the people who think if they drink diet soda they won't get fat.
The other day I had to write a bunch of code with similar lines. Something like
I hopped over to my *scratch* buffer and typed in a short emacs lisp function (three lines of code, if that). I evaluated it, switched back to my code buffer, and added the lines by hitting a key sequence. The above lines were reduced to M-x attr RET phone RET M-x M-p RET fax RET M-x M-p RET email RET, etc. I could've even bound the attr call to a chorded key press or two.
Total time to look up the docs and write the code to extend emacs: about a minute.
Total time spent compiling code, loading a "plugin", restarting emacs: 0.
Total time spent dealing with "you forgot the static keyword on line 12": 0.
Total time spent fixing my code after upgrading emacs: 0.
This is a feature that's been around for decades. Decades! When extending your editor is this simple, you'll do it more frequently.
I can't stress enough how important security is!
When you have a late-bound, extensible environment it is so easy to mess with it. Plugins by their very nature are supposed to be powerful, with hooks into the system at very low levels. This makes it very easy for virus writers, malware authors and spyware developers to run their code with full priviledge.
But lets forget about Spyware and Virus for a moment. Lets say you have a plugin architecture for an application that does proprietary financial calculations for loan approval. You don't want someone to come along create a plugin and change those calulations.
I think about this all the time because I have been developing plugin frameworks for the past 7 or 8 years. I really don't want to limit the functionality of the plugins because in all honesty I want the plugins to be as powerful as they can be so they change the calulations. I know it sounds like I am contradicting myself but the truth is I am not. Creating a plugin architecture is not a decision that you should take lightly.
When deciding to create a plugin system you have to be sure that you can handle the complexity and the inherent insecurity that decision brings you.
#1 point with plugin systems. Plugins are all powerful.
Robert
Bet this
As people have pointed out. Eclipse is an integrated development environment. Sure, you just want to edit a file, but editors in Eclipse are part of that integrated environment. As a simple example, you can select the name of class and ask to see its subtype hierarchy. For that to work, you need to build a model of a bounded set of classes. Hence, the workspace: a bound on the set of files to consider, and a convenient API for working with them.
Setting up projects in a workspace isn't terribly hard, and projects can refer to any physical location, so you don't have to actually copy or move your files around. But, it does slow you down a little when you want to get started, and that's a shame. Trade-offs are nothing new in the world of software design.
Eventually, the File->Open External File function was added. But, you only get a small amount of the functionality that's available when you do it the "proper" way. Probably some careful refactoring could make editors on external files more, though not fully,functional. But, in my opinion, that would be wasted effort.
The workspace/project model works well and supports the desired functionality. Yes, it imposes a little bit of learning on some people, but if that's such a hardship, why are you programming, anyway?
By the way, this whole topic really has nothing to do with the article, which is about the underlying pure plug-in architecture of Eclipse.