Frameworks are for the Impatient
So I installed this framework. It's supposed to enable and empower me, give me some superpowers, make me more productive. It's installed, and I can see that it is running.
The problem is that I don't know what to do with it. I've just been parachute dropped into a running system without a map. I poke around and start to find configuration files. I use my knowledge of the operating system to locate more. I eventually find out what port it is running on, and hook up a browser. Nothing. I find two more ports. Both of them accept my session, and look identical.
Look, this framework is not the game Myst. I did not install this thing so that I could amuse myself for days by running around the file system trying to figure out what it is about, and how it works, what it is for, and what I'm supposed to do with it. I don't play games. I don't generally amuse myself with puzzles, either. I installed the framework precisely so that I could avoid reconstructing the world it lives from terse clues. It should be obvious. It should tell me what it wants me to do. It should "just make sense". It should just work with me, or teach me how to use it.
I find that in the python world, things are made to be more obvious. In the Java world, maybe not. Even opening and reading a file is cause to go google the library one more time. Heaven forbid you have to manipulate dates or the like. These are small things, and should be very easy. And tiny. Occam's razor, you know? Likewise reflection. You shouldn't have to spend time in trial-and-error, or in google searches. You shouldn't have to crack open a half-dozen US$50.00 books. Does this seem silly to anyone else but me? Lest you think I'm picking on Java alone, think "MFC" or "COM". I didn't become a programmer to enjoy the privilege of devoting my life to someone's ill-conceived framework. It's not fun, and I don't like it.
The reason that dynamic languages should own the world is because they try to make everything more simple for the patience-impaired. I suppose there is much to be said for catering to those who are time-pressured and impatient, since that's pretty much all of us these days.
I guess all I'm trying to say is that library and framework designers need to keep first and foremost in mind that they are not writing to the curious and clever. They are writing for people who have limited time and energy. One point of "obvious" is probably worth one hundred points of "clever".
!commentForm
You seem to be saying that software written in dynamic languages are automatically easy to understand and use. I think that's a silly assertion. Even Ruby on Rails, today's poster child for frameworks written in dynamic languages, doesn't "just make sense" without reading up on it. I've certainly spent some time googling for examples of things I think should be simple and obvious, but didn't find them that way.
I don't think it's the implementation language.
Actually, I said that in dynamic languages like python, people *try* to make things easier. Not that they automatically were. I have found the Tao of Python to be inspirational. I've not tried rails yet. -- Tim Ottinger
I don't think it's the implementation language.
Actually, I said that in dynamic languages like python, people *try* to make things easier. Not that they automatically were. I have found the Tao of Python to be inspirational. I've not tried rails yet. -- Tim Ottinger
between dynamic languages and better designed or documented frameworks. Certainly I've found things in java that "just worked" or were well-described. And certainly I've found things in python that were quite puzzling to me at first. Of course, once you're used to a framework, it's all easy.
I understand your rant about things that are complex and difficult to approach. I just don't think it's related to dynamic or static languages.
Okay. I'll watch more carefully for correlation. It was admittedly empirical and kind of knee-jerk. I may find that it's not so, or not so much. -- Tim Ottinger
I understand your rant about things that are complex and difficult to approach. I just don't think it's related to dynamic or static languages.
Okay. I'll watch more carefully for correlation. It was admittedly empirical and kind of knee-jerk. I may find that it's not so, or not so much. -- Tim Ottinger
In design they have the concept of affordance, a feature than invites the user to interact.
For example, the grip lines on the corner of a window simulate the grip handles used on objects to make them easier to hold.
http://en.wikipedia.org/wiki/Affordance
The only problem is, too much affordance can stiffle creativity.
Take Visual Basic's form designer for example. When it comes to an accessible framework with affordance Visual Basic did a great job. The first thing you were presented with was a blank form with controls to drag over to it.
However, the result was that too many applications were written as a set of forms rather than using a more suitable abstraction.
For example, the grip lines on the corner of a window simulate the grip handles used on objects to make them easier to hold.
http://en.wikipedia.org/wiki/Affordance
The only problem is, too much affordance can stiffle creativity.
Take Visual Basic's form designer for example. When it comes to an accessible framework with affordance Visual Basic did a great job. The first thing you were presented with was a blank form with controls to drag over to it.
However, the result was that too many applications were written as a set of forms rather than using a more suitable abstraction.
I think dynamic languages by nature just allow you to think different. If you look at Ruby and C# implementations of the same problem, it's amazing how quickly the C# solution can become verbose and unwieldy, even if it is faster due to its compiled nature.
I think this notion carries over to Rails and ASP.NET respectively. Look at the effort it takes to make an RSS feed:
Rails: Make active record call to get last 10 posts (1 line of code), iterate over them in an rxml builder template. Done.
ASP.NET: Piddle with ADO.NET to get last 10 posts (about 5 lines of code), then create an XmlTextWriter[?] to build the XML feed. About twice the code compared to the builder template and a lot harder to parse through it to understand what's going on.
I think this notion carries over to Rails and ASP.NET respectively. Look at the effort it takes to make an RSS feed:
Rails: Make active record call to get last 10 posts (1 line of code), iterate over them in an rxml builder template. Done.
ASP.NET: Piddle with ADO.NET to get last 10 posts (about 5 lines of code), then create an XmlTextWriter[?] to build the XML feed. About twice the code compared to the builder template and a lot harder to parse through it to understand what's going on.
The point of a framework is to provide for reuse. The problem with reuse is that the developers of the framework don't have access to the domain of the user. Simply put, they don't know how their framework will be (re)used so they have to provide a lot of flexibility usually in the form of extensibility or configuration.
We are all taught that flexibility, loose coupling, etc. is The Most Important Thing. In actuality flexible, loosely coupled code is harder to use and understand. So there is a trade-off. We can have highly reusable code that is hard to understand or very domain specific code that is simple.
In my experience the best and most worthwhile frameworks are very small and solve one specific problem very well. They take a particular problem domain and tackle it so that you don't have to. They don't try to give you a way to do Everything. That is what general purpose languages are for.
However, most of the time you probably don't need a framework. If you develop your own code to solve your own problems you are free to do the Simplest Thing That Could Possibly Work. And, refactoring will evolve flexibility naturally into the areas of the application where it is most needed and most reflects the specific domain.
Hear hear! -- Tim
We are all taught that flexibility, loose coupling, etc. is The Most Important Thing. In actuality flexible, loosely coupled code is harder to use and understand. So there is a trade-off. We can have highly reusable code that is hard to understand or very domain specific code that is simple.
In my experience the best and most worthwhile frameworks are very small and solve one specific problem very well. They take a particular problem domain and tackle it so that you don't have to. They don't try to give you a way to do Everything. That is what general purpose languages are for.
However, most of the time you probably don't need a framework. If you develop your own code to solve your own problems you are free to do the Simplest Thing That Could Possibly Work. And, refactoring will evolve flexibility naturally into the areas of the application where it is most needed and most reflects the specific domain.
Hear hear! -- Tim
Add Child Page to FrameworkImpatience