Registered: Mar, 2002
Re: How Does Language Impact Framework Design?
Posted: Jan 11, 2008 7:00 AM
> > > Typing is incidental. It's a very minor thing.
> > That's just nonsense. On small projects with one
> > developer, where code doesn't get changed much over
> > or where the developer doesn't stick around to observe
> > long term effects, this may hold true.
> Your experience is way different than mine, if so. Tying
> is quick. It's knowing what to type that matters.
I misunderstood you. I thought you were talking about data typing!
> You seem to be taking several things as a given: That
> constraints help you, that the complexity of Hibernate
> help you.
I am just speaking from my experience. I've worked in shops where there are fewer constraints and that works fine if the staff is senior enough to make the right choices.
> I found that a lot of the things I'd believed were
Reflection is a very good thing.
> For instance, I believed that static typing
> caught me a lot of bugs/typos that would otherwise be hard
> to deal with. It doesn't do so - for me.
I've used dynamically typed languages without any problem too. I believe (and have experienced) that when the number of people, the number of changes, and the life of the project increase, static typing helps, whereas the absence of explicit type information leads to increased confusion and errors.
The way to mitigate is to spend more time theorizing about the code and spend more time writing unit tests. The extra cost must be paid somewhere.
> I thought it would be
> better to work with a flexible ORM (Hibernate) than our
> homebrew little "active record" type ORM (one row, one
> object) with explicit passthrough to the database. It
> wasn't - for the two very parallel apps I have tried this
> on. The benefit of abstraction from Hibernate got lost in
> the cost of having performance problems and errors get
> harder to track, and having it harder to understand the
> relationship between the database structure and the code.
The Hibernate case is a harder one for me to defend. We find ourselves often "working around" Hibernate and using straight JDBC for more complex or performance sensitive queries. Unfortunately, our schemas are very poor legacy code so it is often the case that our schemas don't play well with Hibernate. We believe - although we could be wrong - that better schemas would make using Hibernate easier. Fortunately neither our frameworks nor Hibernate lock us in; we can go around them if necessary.
This introduces a new problem: How does the staff know when to use and when to work around the frameworks?
Frameworks are like process: the intent is to make things better. If they are not helpful, you need to change what you are doing. I believe that, in the end, individual responsibility and judgment prevail. Therefore, we try to hire the best we can; folks who are technically sharp, who are good communicators, and who demonstrate creativity and judgment. Good frameworks only make things better.
> So, I am skeptical of these claims not because I don't
> trust that you're a good programmer - you're making more
> or less the right noises, so I expect you are :) - but
> because I feel these areas are easy to conclude wrong in.
I tend to be healthily skeptical of my opinions and very skeptical of the marketplace that tries to influence my technological decisions.
> I still believe there are probably areas where static
> typing is worthwhile - even visible type annotations.
One of the things I liked about Common Lisp - at least it was true when I last used it many years ago - was that the programmer could optionally specify type information.
> I expect there are areas where being able to have a
> complex object/relational mapping (e.g, Hibernate) is
> useful. I just know that I've been bitten by erring on
> the side of complex mappings, and have not yet been bitten
> on the side of simple mappings (active record pattern plus
> structured (non S/HQL) query capabilities in the ORM).
Isn't it all about choosing the right tool for the job? I have agreed that we have in-house applications that would be appropriate for RoR (or some other RAD friendly framework).
> This was an attempt to get back on topic and discuss how
> features of programming languages affect the frameworks
> written for those languages.
> Another example of the Java/Ruby distinction here,
> influenced by a combination of language features and
> "language philosophy"/culture,
Fair enough. A Ruby-based framework will probably embrace convention, simplicity, and dealing very well with the simple cases. A Java-based framework will probably imbue different philosophical values, although it doesn't have to.
Way back in the day when I was writing C and C++, my frameworks dealt with hiding the complexity and freedom of memory allocation and management. When writing Jini (not that Jini is a language) frameworks, I tried to hide the complexity and freedom of discovery, failover, recovery, etc.
> > Dependency injection provides vital flexibility in Java
> > and unneeded overhead in Ruby.
We have very interesting debates about DI (primarily in the context of Spring) on our architecture team. Everyone agrees it is a good thing for many new projects in our environment. When we consider retooling our web site code to use it instead of our internal (and proven) framework, we balk. First, we have a sort of dependency injection already. Second, we don't gain value (in this case) in the flexibility it offers, third, there are hidden costs in using Spring that may (or may not) hurt us, and finally, the costs don't outweigh the benefits.
The Spring decision is a good example in this discussion. The Spring framework, like all good frameworks, imbues certain principles that determine how the framework is implemented and used. The principles of our frameworks tend to first focus on our problem domain, second on then on our environment (values, staff, processes, etc), and - somewhere down the list - on the problems with the Java language.
Of course, since we write in Java, we can't escape the pervasive influence of the language, it's values and principles; those will be omnipresent in our framework. But we do not find our primary focus in framework building to be dealing with the shortcomings of Java; that is a secondary issue most of the time. The top two language specific pain points for us, as I stated in my original post, are the poor generics implementation and the lack of proper closures.