3 ms·

I've been working on the Obvious Architecture, which seeks to decouple your app from both the database and your web framework. Treating Rails or Sinatra or what

I've been working on the Obvious Architecture, which seeks to decouple your app from both the database and your web framework. Treating Rails or Sinatra or whatever as just a delivery mechanism frees you from a lot of of the potentially bad design decisions that your web framework made about how you should structure your app, the worst offender of this is how rails implies the use of ActiveRecord. You should use Rails for what it's good at - web stuff (routing, asset management, view engine integration). I've got an example Obvious twitter close/status update app in progress at https://github.com/RetroMocha/obvious_status https://github.com/RetroMocha/obvious_status Obvious is still super new and I'm working on documentation and examples. You can read more about Obvious at http://obvious.retromocha.com http://obvious.retromocha.com

TylerE 14y ago
This sounds rather...performance killing. Too much abstraction is way way worse than too little, as well.
- tinco 14y ago
 No it isn't. Too much abstraction can always be refactored down to less abstraction. (Too much abstraction means that there's abstraction that is unnecessary, thus it can be cut away.) Too little abstraction means your code is too closely coupled. When the code is fresh and small, then ofcourse it's not hard to abstract out a method to DRY something up. But when your code is big and old this will quickly approach infeasability, which is the reason many projects fail. I would go as far as saying that the science of software engineering exists because your statement is false :P
 - andybak 14y ago
 So you're saying that the arrow of refactoring generally points in the direction of less abstraction? That directly contradicts my experience where most refactoring introduces abstractions when they are needed.
 - ncallaway 14y ago
 My interpretation was that he was saying the arrow of refactoring is easier when refactoring in the direction of less abstraction. I suspect he agrees that generally the arrow points in the direction of more abstraction. This would be the problem he thinks exists. Not sure where I stand on either side of this; just trying to clear up what I saw as a miscommunication.
 - tinco 14y ago
 Yes. Usually when programming one encounters problems that are solved elegantly by introducing abstraction. The parent argues that doing this too eagerly results in a big mess that should be avoided by being cautious with abstraction. I argue the converse, being too cautious with abstraction can result in a big mess and you should be eager to abstract. Of course there is a golden path in the middle, but it is closer to my side ;)
 - TylerE 14y ago
 I have one word for you: InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButton
 - programminggeek 14y ago
 Too much abstraction or indirection will certainly lead you down that path, but that is not really what I would advocate at all. With Obvious the goal is to make it feel obvious what the system is doing. No big complicated inheritance systems. Instead it uses a bit of indirection via dependency injection and reflection to make the data plugs swappable. Nothing too crazy or complicated.
- programminggeek 14y ago
 It doesn't hurt performance in any noticeable way. Your database plugs are passed into the actions. The plugs are designed to do only what you want them to do, so you can tune them to your hearts content. In fact, I would argue it is far easier to tune a query in Obvious than it is in a traditional ORM which hides the query from you. This is done via simple dependency injection, which is pretty standard in many other languages outside of ruby.
yusefnapora 14y ago
This looks interesting, thanks. I'm looking forward to seeing how the delivery and external portions develop in the sample app.
- programminggeek 14y ago
  I'm coding those bits today. What is up so far is 3 hours of coding last night.

TylerE 14y ago

This sounds rather...performance killing. Too much abstraction is way way worse than too little, as well.

tinco 14y ago
No it isn't. Too much abstraction can always be refactored down to less abstraction. (Too much abstraction means that there's abstraction that is unnecessary, thus it can be cut away.) Too little abstraction means your code is too closely coupled. When the code is fresh and small, then ofcourse it's not hard to abstract out a method to DRY something up. But when your code is big and old this will quickly approach infeasability, which is the reason many projects fail. I would go as far as saying that the science of software engineering exists because your statement is false :P
- andybak 14y ago
 So you're saying that the arrow of refactoring generally points in the direction of less abstraction? That directly contradicts my experience where most refactoring introduces abstractions when they are needed.
 - ncallaway 14y ago
 My interpretation was that he was saying the arrow of refactoring is easier when refactoring in the direction of less abstraction. I suspect he agrees that generally the arrow points in the direction of more abstraction. This would be the problem he thinks exists. Not sure where I stand on either side of this; just trying to clear up what I saw as a miscommunication.
 - tinco 14y ago
 Yes. Usually when programming one encounters problems that are solved elegantly by introducing abstraction. The parent argues that doing this too eagerly results in a big mess that should be avoided by being cautious with abstraction. I argue the converse, being too cautious with abstraction can result in a big mess and you should be eager to abstract. Of course there is a golden path in the middle, but it is closer to my side ;)
- TylerE 14y ago
 I have one word for you: InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButton
 - programminggeek 14y ago
 Too much abstraction or indirection will certainly lead you down that path, but that is not really what I would advocate at all. With Obvious the goal is to make it feel obvious what the system is doing. No big complicated inheritance systems. Instead it uses a bit of indirection via dependency injection and reflection to make the data plugs swappable. Nothing too crazy or complicated.
programminggeek 14y ago
It doesn't hurt performance in any noticeable way. Your database plugs are passed into the actions. The plugs are designed to do only what you want them to do, so you can tune them to your hearts content. In fact, I would argue it is far easier to tune a query in Obvious than it is in a traditional ORM which hides the query from you. This is done via simple dependency injection, which is pretty standard in many other languages outside of ruby.

yusefnapora 14y ago

This looks interesting, thanks. I'm looking forward to seeing how the delivery and external portions develop in the sample app.

programminggeek 14y ago
I'm coding those bits today. What is up so far is 3 hours of coding last night.