The downfalls... 1) stuff can take a LOT longer to develop, 2) sometimes I feel like I'm stuck implementing middleware when I should be developing features, 3) there is more room for bugs to sneak in 4) scaling could be tougher when/if the need arises
The positive... 1) I for once feel like I actually know the full flow of execution and this at times makes certain solutions much easier 2) I don't feel that Im on the treadmill of hopping from learning one framework to the other 3) it grows my skill 4) I feel more like Im chiseling something from one stone rather than tying together rocks
Im not entirely sure Id recommend what Im doing - in someways its really stupid but I personally get gratification from it and oddly feel more productive than when Im fusing together multiple frameworks.
Alan Kay, "The Power Of The Context", p.8, https://docs.google.com/viewer?url=http://www.vpri.org/pdf/m...
EDIT google search (mostly) provides a "Quick View" link for pdfs - there's also addons for chrome/FF that add a right-click context menu option to open a file in google view, useful for checking out lecture notes/slides, that often are a list of pdf links.
1) The libraries are guaranteed to be decoupled.
2) The libraries are better maintained individually.
3) It's much easier (sometimes painless) to replace them if they don't suit your needs.
4) ... probably many more.
The hardest part of bootstrapping a new application is the boilerplate. Let someone else take care of managing session state, generating SQL queries, URL routing, DI containers, buffered logging, templating, etc. If you haven't found something that suits your needs, sure, write it yourself.
I wouldn't say what you're doing is stupid. Do what makes you successful and happy. Just don't be stubborn ;)
One of the directions LedgerSMB (http://www.ledgersmb.org) is going is from a framework which was originally written by one guy to something which outsources as much as possible to CPAN modules. This poses some issues, but in general it works pretty well. We probably have as much framework code as we used to but the code does a lot more. We decided not to go with other frameworks because of the dependency issues that sometimes arise.
Also I will personally vouch for #3. We started off using Std::Config for processing ini files. But this isn't well supported in distros or well maintained so we switched to Config::IniFiles and it was a pretty painless effort.
the bigger thing though is you don't have to do it all yourself. :-)
In Rails land at least, a lot of relatively inexperienced developers tend to have trouble when they can't google for the thing they want to implement or find it in the docs. I find that if I open up the source in roughly the area in which I need to implement something, a hook point is provided at about the right level of abstraction. Your mileage with other frameworks/environments may vary.
* Bundle comes with a `bundle open <gemname>` command that opens up the gems source code in whatever your shells $EDITOR is set to. I use this at least three or four times a day.
* Pry (an IRB alternative) will tell you the file + line of the definition of the method you'd be running if you ran `show-source some_object.some_method`. You can also `ls` and `cd` your way around ruby modules/objects which has been invaluable.
My plan to solve this is to open-source my tools/libraries and switch to Flask, so at least some of the stack is familiar. Open-sourcing these tools will force me to isolate them, clean them up and write some documentation - - it can benefit other people and maybe open a pool of developers that know the tools better.
Quick advice: Don't. You'll make it worse.
You're already undermining your thing in that first sentence ("switch it to X so that other people will understand it"). Turning an in-house framework into a "ready for the real world" framework is a ton of work and will invariably need to dull down the sharp edges and general case a bunch of things.
The thing is, those sharp edges are what make it such a good tool. You want sharp edges on your tools. Dull tools might not hurt anybody else but they won't be as good at doing what they do.
You've got something that works really well for you. Chances are it's so focused towards your workflow and way of thinking about the world that it just won't be all that useful to anybody but you. That's just fine.
Trying to make it useful for everybody else will only succeed in making it less useful for you.
Pretty accurate… I like your idea of how to solve it… You can do it the other way around too, have/ask a coder with whom you work spend at least some time on cleaning up and documenting the code… Sounds like a lot of extra effort, but they are already trying to understand and conceptualize the thing for themselves, might as well write it down…
As soon as you try to bring somebody that will mainly "use" those tools/libraries instead of actively developing them, the tools/libraries becomes a de-facto framework to them, just a proprietary one with no community.
If/once you open-source it, it just becomes another framework competing with the other ones.
In short, if you are not rewriting everything new from scratch for every project, you are using a framework - only your own.
If you're switching between frameworks all the time, it would be even more difficult because you wouldn't have deep knowledge, but at least there is presumably a group of people somewhere to consult. If you're lucky they even had some plan when they came up with design decisions.
I can see how you avoid a lot of cruft, but how do you discipline your own projects? How much documentation do you create for your own later reference?
1) Consistent but evolving paradigms. In other words, let's not be static, let's keep most change happening relatively slowly. But let's review and try to fix problems as they happen, cleaning old code slowly and continuously.
2) Try to document everything to at least a basic extent.
3) Let the documentation practices evolve. Don't try to document too much too soon. Start out with a basic level. As the project matures you will have a better idea of what needs more documentation and you can spend your time on the areas that help.
4) Don't underestimate person to person mentoring.
I think it is wise to learn other frameworks and languages. It will help you with making wise decisions when developing your own tools.