Weblogs Forum - How Does Language Impact Framework Design?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
How Does Language Impact Framework Design?

42 replies on 3 pages. Most recent reply: Feb 15, 2008 4:22 PM by Andy Dent

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 42 replies on 3 pages [ « | 1 2 3 | » ]

Eivind Eklund

Posts: 49
Nickname: eeklund2
Registered: Jan, 2006

Re: How Does Language Impact Framework Design?

Posted: Jan 11, 2008 1:34 AM

Sean,

> Eivind,
>
> >
> > The question isn't how much it is to type - it is how
> > much it is in the way of reading.
>
> I believe the reading argument is very weak. I won't speak
> for the rest of my staff, but it has *never* come up.

I would not expect it to come up unless your staff was trained in cognitive psychology (attention research).

> Anyway, the reading cost is nothing compared to the cost
> of failing to detect errors until deployment (or even QA).
> Of course Unit testing helps but things do get through.

The primary way the reading cost shows up is as failing to detect errors early. It isn't about speed of reading - though that is a factor - it is about comprehension.

> > When you have readable code - and readable code include
> > *compact* code, so you can get the maximum amount of
> > context into a single screen - you have less errors.
>
> > 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 time,
> or where the developer doesn't stick around to observe the
> 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.

That's especially my experience with large projects with a hundreds of programmers (e.g, FreeBSD.) It holds true for most of the smaller projects, too.

The only case where I find typing to be the major factor in programming is in very small projects - a few kloc or so. The major amount of time goes into making the right choices around how to design things.

> > Then, adding some more boilerplate - e.g, a
> configuration
> > n for how to map tables to class names - does not seem
> > like a big deal. You gain flexibility, after all, and
> > it's consistent to have a single place where you
> declare
> > all such mappings instead of having to declare
> exceptions
> > to the general rule. But - that lead to a ton of
> > declarations, and most of them are the obvious ones.
> This
> > hides all the non-obvious variation in this.
>
> What point you are trying to make?

That the repetition Java leads to internally in the source code spreads into programmer minds, where repetition end up being "no big deal" or "necessary", and influence culture.

I should probably have had quotes around "gain flexibility", because you don't gain flexibility by not having a default - you gain repetition of the default (and a repetition that's self-contained and not relying on knowing the default, something that occasionally is worth something.)

>
> > Contrast this with the ActiveRecord pattern, of which
> the
> > most well-known variant is Rails ActiveRecord class.
> The
> > ActiveRecord pattern is simple: One database row, one
> > object. This creates a very "thin" mapping, and makes
> it
> > obvious to the person working with the program how this
> > maps to the database - and where performance hits come.
>
> I figured this was coming. Rails is fine for a web site
> that babysits a database. But if you need to do something
> complex, you are SOL.

I was not talking of Rails. I was talking of the ActiveRecord pattern. I don't use Rails, so I can't say that much about it.

> Yes, some problems actually are
> complex and you need a language that helps. Our problems
> are complex and we get benefit from the 'constraints' of
> Java and even the complexity of Hibernate.

You seem to be taking several things as a given: That constraints help you, that the complexity of Hibernate help you. I used to take these things as a given until I tried experimenting with small variations, such as increasing the type checking in Ruby by writing a checker implementation, tracking where errors come from in the apps I work on using different patterns, etc.

I found that a lot of the things I'd believed were incorrect. 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 thought the types were useful for tracking what was going on - it turns out they aren't - for me. 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.

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 have reversed my own judgment when I was quite experienced (I lost belief in static typing after almost 20 years experience, and Hibernate after almost 25 years experience including 10 years dealing with databases and ORMs).

I still believe there are probably areas where static typing is worthwhile - even visible type annotations. I am just not certain of what exact areas they are, and what exact properties are necessary around the system to make it useful. (I have written a 20-page paper on adding more type checking to Ruby, evaluating the advantages and drawbacks of all ways I could think of to add more type information, so I have some idea. Enough that I have decided more research is necessary.)

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).

> > You get a large difference in the culture around
> > frameworks, where the languages where you can write
> things
> > so they are simple and small also get compact libraries
> > with small APIs and simple abstractions - because when
> you
> > add complexity, it is so obvious that you do so.
> >
> > Eivind.
>
> Hopefully you didn't interpret that I was advocating
> writing frameworks to add complexity.

Not at all.

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, is the Spring/HiveMind/Copland/Needle distinction. HiveMind is, as far as I understand, considered a fairly lightweight dependency injection framework for Java, with Spring's DI components being the "heavyweight". In Ruby, Copland is a framework written as a parallel to HiveMind. Rubyists considered that very heavyweight, and the author of Hivemind ended up writing a new framework - Needle - to create something that was lightweight. Using the language features of Ruby, it turned out we could implement DI in a very simple way (http://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc). This resulted in the Needle implementation.

However, in the words of Jim Weirich, the guy that wrote that (and did a presentation on DI in Ruby/Java):

> Dependency injection provides vital flexibility in Java
> and unneeded overhead in Ruby.

That presentation is here: http://onestepback.org/articles/depinj/

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: How Does Language Impact Framework Design?

Posted: Jan 11, 2008 5:08 AM

> Achilleas Margaritis wrote:
> > For example, if Java had lambda functions, its UI
> > frameworks would be much easier to program for.
>
> The Mozart/Oz happens to have a high level GUI toolkit
> called QTk in its standard library. Here's your GUI
> example in Oz+QTk:
>
>

declare
> Username
> Password
> LoginPage = td(label(text:"username")
> 	       entry(handle:Username)
> 	       label(text:"password")
> 	       entry(handle:Password show:"*")
> button(text:"login" action:proc {$} {Login
> } {Login {Username get($)} {Password get($)}}
> end))

>
> Note that I changed the login(username) call to
> login(username,password). Also note that Username and
> Password aren't strings here: they're handles. Handles
> have methods like get() and set() to get and set the value
> of the text entry fields.
>
> The GUI is ready to be displayed:
>
>

{{QTk.build LoginPage} show}

>
> The first thing you noticed is Oz' weird syntax. Curly
> braces are used for function calls and parens are used for
> tuples: the opposite of your example syntax for Java.
>
> Oz has the same language features as your extended Java.
> Tuples: the GUI layout is specified using tuples and
> records (records are tuples with named fields). Oz has
> closures, so we can specify the action:
> property of the login button inline, and we automatically
> have access to the Username and Password variables.
>
> One feature of Oz that is used which your extended Java
> probably doesn't support is dataflow variables. They allow
> you put uninitialized variables, like Username and
> Password, in tuples and records, and they can be
> initialized later. In this case QTk initializes them for
> us.
>
> All these language features are necessary to build this
> concise and declarative GUI framework, so in this case the
> answer to the question of this post is: language features
> are critical for framework design.

Yeah, Oz is cool. Too bad it's so different from anything else.

Sean Landis

Posts: 129
Nickname: seanl
Registered: Mar, 2002

Re: How Does Language Impact Framework Design?

Posted: Jan 11, 2008 7:00 AM

Eivind,

> > > 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
> time,
> > or where the developer doesn't stick around to observe
> the
> > 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
> incorrect.

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.

Jules Jacobs

Posts: 119
Nickname: jules2
Registered: Mar, 2006

Re: How Does Language Impact Framework Design?

Posted: Jan 11, 2008 10:35 AM

Yes! Oz is fantastic in many ways. I'm still learning a lot from it.

> neat! is there a way to generate interactive web
> applications, too?

Not that I am aware of, but it's certainly possible to write a framework that allows you to change the QTk.build call:

{{QWeb.build LoginPage} show}

In theory. The callbacks would be quite slow. You'd need a different framework in practice, one that doesn't assume that callbacks are fast.

Elizabeth Wiethoff

Posts: 89
Nickname: ewiethoff
Registered: Mar, 2005

Re: How Does Language Impact Framework Design?

Posted: Jan 11, 2008 9:49 PM

Frank Sommers wrote: "...Ruby wouldn't scale up to large systems: The way Ruby classes can be opened up and parts of a class redefined--a very handy feature when writing Rails modules, for instance--can, for instance, lead to completely incomprehensible programs in the wrong hands."

Frank, I see you're expressing some concerns I raised on Jan. 11 in http://www.artima.com/forums/flat.jsp?forum=106&thread=221903 about Ruby's scalability to large apps.

Michael Feathers responded to Frank: "That's true, but in the wrong hands nothing is safe and that trumps anything you can do in a language. Ultimately, code comprehension and maintainability are social rather than technical problems. I've seen exquisitely good large systems written in C, and lousy systems written in much more capable languages. It all goes back to the people."

At least C (well, C++, 'cause I'm not up on C) doesn't let a function be defined more than once. Attempts to do so are caught by the compiler or linker. Therefore, when you design tests pertaining to that function, you know that the function your tests exercise is the same function that gets invoked when the full app runs in the real world.

I've concluded that Ruby's openness means Ruby programs are impossible to white-box test or black-box test in chunks. (Yeah, yeah, please don't bring up the Halting Problem.) NUnit testing has been all the rage for a few years, but what is a "unit" in Ruby? A .rb file? A class? A module? A library? A gem?

I no longer believe there's any such thing as a Ruby unit. Sure, a disciplined team of Rubyists can create something which appears to be composed of distinct units. But I think they're not, and so-called unit testing in Ruby is ultimately futile.

Then add to this the fact that Ruby culture encourages opening things up. After all, the standard library does it (abbrev, mathn, open-uri, pp, set, yaml, etc.), so everybody else does it, even just by requiring a library. DHH does it: Think 5.day.ago--and it returns a Numeric, of all things (oy). Therefore, every Ruby blogger under the sun goes through the exercise of inventing something like

if bob.has_a.dog.and.bobs.dogs.name.is."Fido"

Ruby's genie is out of the open bottle, and it'll take a lot of "considered harmful" articles to bring discipline to the community.

Meanwhile, I think we can only truly rely on black-box testing of a whole Ruby system and wait for bug reports to roll in. That is so last century. It's ironic that a forward thinking language throws us back a century in testability.

Elizabeth Wiethoff

Posts: 89
Nickname: ewiethoff
Registered: Mar, 2005

Re: How Does Language Impact Framework Design?

Posted: Jan 11, 2008 10:17 PM

I wrote above: "At least C (well, C++, 'cause I'm not up on C) doesn't let a function be defined more than once. Attempts to do so are caught by the compiler or linker. Therefore, when you design tests pertaining to that function, you know that the function your tests exercise is the same function that gets invoked when the full app runs in the real world."

Hmm. Upon further reflection it occurs to me that the tests can't anticipate DLL Hell. That's why it's so hellish.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: How Does Language Impact Framework Design?

Posted: Jan 12, 2008 5:22 AM

> At least C (well, C++, 'cause I'm not up on C) doesn't let
> a function be defined more than once. Attempts to do so
> are caught by the compiler or linker. Therefore, when you
> design tests pertaining to that function, you know that
> the function your tests exercise is the same function that
> gets invoked when the full app runs in the real world.
>
> I've concluded that Ruby's openness means Ruby programs
> are impossible to white-box test or black-box test in
> chunks. (Yeah, yeah, please don't bring up the Halting
> Problem.) NUnit testing has been all the rage for a few
> years, but what is a "unit" in Ruby? A .rb file? A class?
> A module? A library? A gem?

I share your concerns, and I do think it will be interesting to see where things are in Ruby in a few years. But, that said, Smalltalk and Python have the same problem. It's not new, it's just different. TDD was actually refined in a large Smalltalk project.

> I no longer believe there's any such thing as a Ruby unit.
> Sure, a disciplined team of Rubyists can create something
> which appears to be composed of distinct units. But I
> think they're not, and so-called unit testing in Ruby is
> ultimately futile.

Re testing, we call them "unit tests" but the fact is all tests execute a path, and tests are never exhaustive. Ultimately, we have to write tests that give insight into the operation of the system and we can we can always do it badly.

> Then add to this the fact that Ruby culture
> encourages opening things up. After all, the
> standard library does it (abbrev, mathn, open-uri, pp,
> set, yaml, etc.), so everybody else does it, even just by
> requiring a library. DHH does it: Think
> 5.day.ago--and it returns a Numeric,
> of all things (oy). Therefore, every Ruby blogger under
> the sun goes through the exercise of inventing something
> like
>
>

if
> bob.has_a.dog.and.bobs.dogs.name.is."Fido"

>
> Ruby's genie is out of the open bottle, and it'll take a
> lot of "considered harmful" articles to bring discipline
> to the community.
>
> Meanwhile, I think we can only truly rely on black-box
> testing of a whole Ruby system and wait for bug reports to
> roll in. That is so last century. It's ironic that a
> forward thinking language throws us back a century in
> testability.

I really don't think it's that bad. :-) As a guy who spends most of his working life helping people break dependencies in statically typed languages, I appreciate the ease of dynamic languages. You can retrofit unit tests far more easily.

As I mentioned before, without discipline all projects fall apart. Therefore, it makes sense to assume discipline. If you try to design a language which tries to compensate for discipline within a team, there's a good chance that you will make it harder to recover when things go awry. And, frankly, I see a lot of that out in the field.

The thing about discipline, though, is it is easier to achieve in small jelled teams. It breaks down in larger groups of people. So, knowing that, it seems that the one area that language designers would do well to revisit is componentization. They've shied away from it since the Modula family and Ada. Since those, we've had a mis-mash of extra-linguistic solutions. If there's a place where we need clarity and restriction in languages it isn't the code that you and the guy or gal you sit next to work on together, it's the places where you import and export code to different teams. To me, discussion of scalability in language design has to start there.

Elizabeth Wiethoff

Posts: 89
Nickname: ewiethoff
Registered: Mar, 2005

Re: How Does Language Impact Framework Design?

Posted: Jan 12, 2008 6:18 AM

I agree that all projects fall apart without enough discipline, and the larger the project/team the more discipline is needed.

Allow me to digress a bit. I haven't worked in C++ in years, and I'd say in retrospect that I was pretty inept at it. But I find since then that I love reading C++ books and articles. The language has been around for, gosh I dunno, nearly 30 years, and I'm fascinated by the developments in theory, coding practices, and libraries for getting stuff done without shooting your legs off or waiting forever for the compiler. Take, for example, the growth in clarity about levels of exception safety and how to analyze a piece of code for its exception guarantees. Now, that's cool and important. Then there's the whole business about is-a, has-a, is-implemented-in-terms-of. And on an on. Eventually Alexandrescu's use of templates blows everyone's minds.

Even though C++ hasn't changed much, there's been tremendous growth in how to use it well. And Scott Meyers-like recommendations to "Prefer this" and "Prefer that" distill this knowledge for lesser lights like me.

The Ruby language is still pretty young, and I think an awful lot of Ruby users are still in a rabid, drooling weenie stage. In other words, the community is immature (in many ways).

Like C++, I'd say Ruby is an astonishingly powerful language. Though it's not close to the metal and probably can't shoot our legs off, I do believe it has the ability to drive us stark, raving mad. It'll take some battle-worn "considered harmful"s and "Prefer this"es and "Prefer that"s before the Ruby community is ready for large projects/teams.

Oh, I had a brain fade earlier. I should have written:

if bob.has_a.dog.and.bobs.dogs.name.is :Fido

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: How Does Language Impact Framework Design?

Posted: Jan 12, 2008 7:41 AM

> I agree that all projects fall apart without enough
> discipline, and the larger the project/team the more
> discipline is needed.
>
> Allow me to digress a bit. I haven't worked in C++ in
> years, and I'd say in retrospect that I was pretty inept
> at it. But I find since then that I love reading
> C++ books and articles. The language has been around for,
> gosh I dunno, nearly 30 years, and I'm fascinated by the
> developments in theory, coding practices, and libraries
> for getting stuff done without shooting your legs off or
> waiting forever for the compiler. Take, for example, the
> growth in clarity about levels of exception safety and how
> to analyze a piece of code for its exception guarantees.
> Now, that's cool and important. Then there's the whole
> business about is-a, has-a, is-implemented-in-terms-of.
> And on an on. Eventually Alexandrescu's use of templates
> blows everyone's minds.
>
> Even though C++ hasn't changed much, there's been
> tremendous growth in how to use it well. And Scott
> Meyers-like recommendations to "Prefer this" and "Prefer
> that" distill this knowledge for lesser lights like me.

For the most part, I agree but I think there are two separable things here.

There has been a tremendous amount of advice in how to use C++ well, but it has been because it was needed, given the language. Exceptions, in particular, sparked an incredibly amount of best practice work because they were grafted onto the language late and before the ramifications of late addition were understood. I guess it's arguable, but I think that Java has had less of "best practice" industry because the language design was cleaner and simpler, at least pre-Java 5.

The template metaprogramming stuff.. I had the same reaction to it that you're having to Ruby. In fact, when I read Modern C++ Design, I called it pornography for programmers because it as all so sexy, all so cool, but I knew I'd want to reach for a shotgun if a teammate started doing it in production code.

No language community is immune.

> The Ruby language is still pretty young, and I think an
> awful lot of Ruby users are still in a rabid, drooling
> weenie stage. In other words, the community is immature
> (in many ways).

I agree.

> Like C++, I'd say Ruby is an astonishingly powerful
> language. Though it's not close to the metal and probably
> can't shoot our legs off, I do believe it has the ability
> to drive us stark, raving mad. It'll take some battle-worn
> "considered harmful"s and "Prefer this"es and "Prefer
> that"s before the Ruby community is ready for large
> projects/teams.

But, since it all happens organically, people will attempt large projects, and they will figure it out. And, people are using metaprogramming in the large in C++ (god help them) and they will get to all of the "nevers" and "prefers" later.

> Oh, I had a brain fade earlier. I should have written:
> if bob.has_a.dog.and.bobs.dogs.name.is :Fido

Yup, I agree about the fluent interface style. It's cool, but I wonder now necessary it is most of the time. My fear is that, with people writing more about DSLs now (there are several books in the works) we'll have another era of inappropriate DSL creation like the inappropriate framework building era in the late 80s, early 90s. Fluent interfaces are cool, but like frameworks, you don't want everybody in the world creating them. A bit of restraint is far saner in the long run.

Elizabeth Wiethoff

Posts: 89
Nickname: ewiethoff
Registered: Mar, 2005

Re: How Does Language Impact Framework Design?

Posted: Jan 12, 2008 11:24 AM

> when I read Modern C++ Design, I called it pornography for programmers

I'm not a Rails programmer because I have zero interest in web apps. But I was struck late last summer by someone's blog raving about 5.days.ago, and I downloaded Rails to browse around a bit in the code. When I saw how the 5.days.ago stuff is implemented in ActiveSupport and then knowledge about how clocks and calendars work has to get re-implemented in a couple other places, I called it a "stupid pet trick."

> Yup, I agree about the fluent interface style. It's cool, but I wonder now necessary it is most of the time.

I don't think it's too much to expect client programmers to learn some normal Ruby. It's already quite readable. If I desired to make "fluent interface" wonks happy, could write


class Object
  alias_method :has_a  :respond_to?
  alias_method :has    :respond_to?
  alias_method :have_a :respond_to?
  alias_method :have   :respond_to?
  alias_method :does   :respond_to?
  alias_method :can_do :respond_to?
end

and expect the client to be satisfied with writing

if bob.has_a :dog and bob.dog.name == :Fido

Off the top of my head, I think Ruby's rules for keyword and operator precedence would bind and evaluate all that bob-and-his-dog stuff in a reasonable order, even without parentheses around the :dog argument. And the aliases strike me as minimally invasive to the language core.

> My fear is that, with people writing more about DSLs now (there are several books in the works) we'll have another era of inappropriate DSL creation like the inappropriate framework building era in the late 80s, early 90s.

Ya know, because those

seconds, minutes, hours, days, weeks, months, years, ago, since, from_now, bytes, kilobytes, megabytes, gigabytes, terabytes, petabytes

, and exabytes methods slapped into Numeric by Rails each return Numeric objects, the following nonsense is valid:


17.terabytes - 3.weeks
5.days.ago ** 6
1.since.byte.year & 0xCAFEBABE
42.from_now.lcm 98

Sigh. Come on, people, types are your friends. It is types which allow and disallow various operations.

> Fluent interfaces are cool, but like frameworks, you don't want everybody in the world creating them. A bit of restraint is far saner in the long run.

A bit of restraint is also far easier because the language's rules for keyword, operator, and binding precedence make life easier when you go ahead and use them, for crying out loud. If someone's idea sensible programming is to string a lot of methods together, as in bob.has_a.dog.and.bobs.dogs.name.is :Fido, the operations all have the same precedence and must be evaluated strictly from left to right.

I suppose bob.has_a.dog should miraculously evaluate to false or true (or nil or something non-nil), but what should bob.has_a.dog.and evaluate to? How about bob.has_a.dog.and.bobs? Etc. Somewhere under the hood you'll need to store some state as you make your way past that fake and. Yeah, I actually ran across an excited blogger a week or two ago who faked a logical and in his pointless DSL of chained methods.

I'm glad we agree that inappropriate DSL design and implementation is loony. Or needlessly difficult. BTW, have you overcome your urge to write twenty.nine.thousand.four.hundred.fifty.three? :-) One of these years we'll have support groups for recovering DSL designers: "Hi, I'm Michael, and I'm a recovering DSL designer." (Sorry.)

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: How Does Language Impact Framework Design?

Posted: Jan 13, 2008 12:21 AM

> I suppose bob.has_a.dog should miraculously
> evaluate to false or true (or
> nil or something non-nil), but
> what should bob.has_a.dog.and evaluate to?
> How about bob.has_a.dog.and.bobs? Etc.

You could evaluate this in the Maybe monad ;)

Elizabeth Wiethoff

Posts: 89
Nickname: ewiethoff
Registered: Mar, 2005

Re: How Does Language Impact Framework Design?

Posted: Jan 13, 2008 10:56 PM

> You could evaluate this in the Maybe monad ;)

If you want a programming language in which you define words that do the right thing as they are read from left to right, your heart is longing for Forth. ;-)

Eivind Eklund

Posts: 49
Nickname: eeklund2
Registered: Jan, 2006

Re: How Does Language Impact Framework Design?

Posted: Jan 14, 2008 12:47 AM

Sean,

> Isn't it all about choosing the right tool for the job?

Definitively - the way I view the discussion we are having is as exploring when which tool may be appropriate.

Eivind.

Eivind Eklund

Posts: 49
Nickname: eeklund2
Registered: Jan, 2006

Re: How Does Language Impact Framework Design?

Posted: Jan 14, 2008 1:19 AM

> Frank Sommers wrote: "...Ruby wouldn't scale up to
> large systems: The way Ruby classes can be opened up and
> parts of a class redefined--a very handy feature when
> writing Rails modules, for instance--can, for instance,
> lead to completely incomprehensible programs in the wrong
> hands."
>
> Frank, I see you're expressing some concerns I raised on
> Jan. 11 in
> http://www.artima.com/forums/flat.jsp?forum=106&thread=2219
> 03 about Ruby's scalability to large apps.
>
> Michael Feathers responded to Frank: "That's true, but in
> the wrong hands nothing is safe and that trumps anything
> you can do in a language. Ultimately, code comprehension
> and maintainability are social rather than technical
> problems. I've seen exquisitely good large systems written
> in C, and lousy systems written in much more capable
> languages. It all goes back to the people."
>
> At least C (well, C++, 'cause I'm not up on C) doesn't let
> a function be defined more than once.

In theory C doesn't; in practice C does.

> I've concluded that Ruby's openness means Ruby programs
> are impossible to white-box test or black-box test in
> chunks. (Yeah, yeah, please don't bring up the Halting
> Problem.) NUnit testing has been all the rage for a few
> years, but what is a "unit" in Ruby? A .rb file? A class?
> A module? A library? A gem?
>
> I no longer believe there's any such thing as a Ruby unit.
> Sure, a disciplined team of Rubyists can create something
> which appears to be composed of distinct units. But I
> think they're not, and so-called unit testing in Ruby is
> ultimately futile.

I see your argument; I just don't believe it. As far as I can understand this, you want a "guarantee" that your unit is going to behave in the wildness of your program, while in Ruby a name conflict or an unrelated override can make your module misbehave.

In C++, a pointer error in your or another module can kill you. In any language, a compiler or interpreter bug can kill you.

The fact is that more or less no matter what you do, your unit won't only behave as a unit - it's *mostly* a unit, and there are cases where interactions show up.

The question is how often does these cases hit you and create a problem.

The answer for all of the problem I mentioned, in my experience and including the Ruby problems of overrides, is "so seldom it hardly matters".

There are reasons to be skeptical of Ruby in large scale context - the library/gems mechanisms are fairly brittle, for instance, and there is no handling of name spaces for library *class names* - but unit testing works fairly well. Things seem to stay off each other's toes in practice.

Frank Silbermann

Posts: 40
Nickname: fsilber
Registered: Mar, 2006

Re: How Does Language Impact Framework Design?

Posted: Jan 14, 2008 3:34 PM

> I don't think VB.NET or C# (version 1) are much better
> languages than Java, but the ASP.NET framework is pretty
> friendly and fun to work with compared with what I've had
> to work with in Java. ...
>
> I don't see what VB.NET or C# version 1 have that Java do
> not have that prevent impedes Java having great web
> frameworks. In fact I hear Wicket is an excellent java web
> framework.

Servlets was a GREAT improvement over CGI.

The trouble came when J2EE designers decided that we needed to immitate the programming style of such web tools as ASP and ColdFusion. Architecturally, those are horrible approaches to web development -- though proprietary tools make it easy to build (but not maintain) simple web applications using them.

This was the wrong approach for us, because it was decided from the beginning that there would be no single official Java IDE for which venders could target reusable components. Also, because Java's portability attracts enterprise-minded folks, they began to hack enterprise capabilities into these very limited "HTML-with-scripting" approaches.

In other words, JSP was a kludge (basically a Servlet-generating macro) to enable us to embed Java code into HTML -- a bad approach to begin with! Then, to get the Java code out of the JSP we got custom tags -- with an incredibly unintuitive API for building them. Because of the difficulty building custom tags we got standard tag libraries -- which essentially let us put scripts _back_ into the HTML, but now with a new syntax!!! Then, to organize the crap for enterprise-sized applications we got Struts, and then more on top of that.

Now, JSF tries to give us ASP.NET capabilities, but again without the standard toolset (without which ASP.NET would be impossible to use).

Wicket, as you say, is indeed an excellent Java web framework! Instead of following Microsoft's approach --which was developed to take advantage of Microsoft's strengths -- Wicket takes advantage of Java's strengths (though I think Wicket would be even better as a C# framework). Wicket throws out all the J2EE crap and starts over -- just as Hibernate did for those who couldn't stomach the original EJB framework. Originally, Wicket was implemented using Servlets, but the latest implementation relies upon nothing more than Servlet filters.

Though there are some Wicket plug-ins for Netbeans, Eclipse and IDEA, you can build amazing web applications in Wicket with little more than Notepad and a generic WYSIWYG HTML editor. And because all of the application's logic -- display logic as well as model logic -- is written in plain old Java, you can architect your application using whatever object-oriented techniques you would have used to architect any large batch, command-line, or fat-client application.

Until recently, the main disadvantage of Wicket was the reliance upon online documentation that was ad-hoc and scattered. To write a Wicket application two years ago I had to rely on participating in a discussion board while reading example code and even parts of the framework implementation itself! (It's a testament to the rational design of Wicket that learning this way was actually possible!)

But now there's already one book out, and a more up-to-date Manning book on the way with some of the chapters already available online. (http://www.manning.com/dashorst/)

Wicket can save Java on the web, and that, in turn, can save Java.

Flat View: This topic has 42 replies on 3 pages [ « | 1 2 3 | » ]

Previous Topic

Next Topic