But more often than not, I find the layers of abstraction become confusing, limiting, and frustrating.
Some recent discussion with a friend with whom I have been coding made me think some more about just how much a powerful, flexible, ingenious set of abstractions can lead to software that is unusable by the intended audience.
I am hoping we go with a simpler, more consistent architecture that uses small, easily-understood concepts. It may be harder to say it's "enterprise grade" without the fancier ideas, but I think it will be both easier to build and easier to use.
This isn't of course a Perl-specific problem, but we're in the design-stage of a Perl application that will require the ability to be customized in ways we will probably never imagine!
No matter what architecture we end up implementing in order to provide a product, if it isn't immediately useful, and easily understandable by the target user audience, it can not succeed.
That makes me think about what makes a language successful... Perl is a great example of a language that shares the ideals I want in this application! It should:
- be easy to get started for simple uses
- be easy to transform simple uses into more complex uses
- provide functionality that users will need to easily get common stuff done
- provide functionality that users will need to customize generic tasks
- allow users to easily add custom functionality
- allow users to share and re-use custom functionality
- be flexible enough to allow for different ways of thinking about solving problems - whatever the user finds best for *them*
- make possible the creation of sophisticated systems - that can then easily become part of other systems.
The just want a system that is immediately useful and easy in simple cases, but allows and encourages them to grow it into something much more powerful over time, without forcing upon them layers of new abstractions or solutions that feel unnatural and inflexible.
Perhaps I'll write more about this specific application soon... I've been reading The Mythical Man Month and it's lit a fire under my rear on actually making this thing a reality... I now want to start not with code (of which I've already written some) but with a design document detailing how an end user would see and use this system in the most common cases.
I believe that software should always be written for the users, and making the program (or language) easy to use yet still powerful and flexible is the highest goal for which a programmer can strive.