Smalltalk Framework Is Ok

XP says frameworks are bad, yet they use one of the most successful frameworks of all time: smalltalk.

XP doesn't say that on every project you should evolve an OS, evolve a language, evolve a large set of interconnecting libraries. No, smalltalk is accepted without question as an acceptable solution even though it is as huge and invasive a framework as one can think of. Shouldn't a project evolve this part of the application too?

Why is smalltalk an ok framework and other frameworks with equal real-world experience behind them are not ok? If a framework for something as simple and well understood as logging is not ok then smalltalk shouldn't be ok either.

Discussion (on the substantial questions)

This topic seems to be blurring the distinction between EngineeringForReuse? and EngineeringWithReuse?.

EngineeringForReuse? is the attempt to generalize your code for hypothetical situations beyond your immediate application requirements. An XPer will not do this, since it violates YouArentGonnaNeedIt and DoTheSimplestThingThatCouldPossiblyWork. In XP, reuse happens only as a side effect of OnceAndOnlyOnce coupled with RefactorMercilessly.

EngineeringWithReuse? happens any time you call a method from more than one client. It happens any time you use an operating system, a standard library, a third-party framework, or library. An XPer will practice EngineeringWithReuse?, as long as it doesn't violate DoTheSimplestThingThatCouldPossiblyWork. This certainly supports the reuse of a full-featured framework in many cases.

The question of when it's appropriate to reuse a framework is completely different than the question of when it's appropriate to create a framework.

--CurtisDuhn

Using existing frameworks is fine, if that will make the team faster and the design better.

Then how do they every get built? Why are frameworks not subject to yagni?

Some frameworks evolve out of many, many refactorings. The SmallTalk base classes might be an instance of that. (But do ask a SmallTalk expert, which I'm not.)

Some people do build frameworks from scratch. Some of these are even good. XPers use the good ones when they make the team faster and don't intrude on clean design.

Using XP to develop a framework might be tricky.

Under what circumstance would an XPer knowingly build a framework?

If her customer (and, more to the point, the team's) was asking for a framework, I suppose. See ExtremeFrameworks. See also FrameworksConsideredHarmful, where apparently we learn that XP does not say "frameworks are bad". It also touches on some of the same points as this page.

Then when do frameworks get created? If you use a framework you should be willing to create one. Yagni etc all apply to existing frameworks because an existing framework will not likely meet all the requirements that would have been applied to it if XP was used. --AnonymousDonor

Assuming you are asking the question, "when does an XP team set out to create a framework ?" : An XP team will set out to create a framework if that is the project's goal. Otherwise, they won't explicitly create a framework, though it might well be the case that one will emerge from the project anyway. Does that answer the question(s) ?

When would that be the goal? A framework is something one does as part of a project, it's not a project. So the answer would be never i guess. --AnonymousDonor

Someone who has engaged in many conversations with XPers about frameworks understands the actual real-life XP position on frameworks. Still waiting for a situation where an XPer would create a framework. --AnonymousDonor

Help me out here. The above answer is my best shot at answering your question : XPers will create a framework if the goal of the project is to create one. This appears not to be satisfying because "a framework is something one does as part of a project". I'll gladly go along with that definition if it'll help answering the question, but the definition would seem to rule out Smalltalk as a framework - Smalltalk was a project, not something done as part of a project. Or do we have differing definitions of "project" ?

Why is it important to you to know when an XPer would create a framework ?

Also note : insofar as anyone can be considered an "official" spokesperson for XP, we have RonJeffries "officially" stating, in FrameworksConsideredHarmful, that XP doesn't seem to have a position on frameworks.

-- LaurentBossavit (willing to help but confused)

SmallTalk is accepted without question as an acceptable solution even though it is as huge and invasive framework as one can think of.

Could you please expand on "invasive" ?

Smalltalk dictates memory management, tasking model, object model, development model (one image) etc. In addition smalltalk has gobs of premade libraries/frameworks that one may not use but would generally use. Invasive isn't pejorative, it just means smalltalk is everywhere you want/need to go. --AnonymousDonor

So maybe "pervasive" would be a better word than "invasive"? -- TomStambaugh

: The original author should perhaps bear in mind that part of the reason why the Smalltalk framework has been so successful is that it isn't fixed, nor is it application specific.

So all other frameworks are fixed and application specific so no other framework can ever be created? It's not a requirement when building a framework to make it crappy. --AnonymousDonor

Discussion (on matters of form)

XP says frameworks are bad...

Please point to someone saying that ? I recall some people arguing that developing a framework from scratch as part of an application development project, where the application is the primary objective isn't such a hot idea.

See any conversation on XP and frameworks. They are unneeded as they are yagni and should be evolved.

Please point to a specific quote. If it appears to be from an XPer, and appears to say that frameworks in general are bad, we'll know where we stand.

A quote from an XPer saying that not all frameworks are good would be OK, from my point of view. This would definitely not be the same as saying that "frameworks are bad".

XP says frameworks are badyet they use one of the most successful frameworks of all time.

Who is this "they"? Most of the folk I know of who're trying to do XP are using anything but Smalltalk.

The original XP project, ChryslerComprehensiveCompensation. But you're right, most XP people use Java. No frameworks lurking there, nosiree.

: Yeah well, this page clearly began as StrawMan XP knocking copy, so lets not worry about it too much. What can we say? Perhaps that the kind of people that tend to like XP tend also to dislike having to work within fixed application frameworks. And what of that?

Hm, asking a legitimate question is knocking? And why do frameworks have to be anymore fixed than smalltalk? Smalltalk is very fixed actually as most people don't use just the syntax. You are buying into a lot when using smalltalk. Not that there's anything wrong with that, it just hypocrytical to knock creating equally useful frameworks. --AnonymousDonor

It is a simple factual error to assert that "Smalltalk is very fixed actually...". When I realize that behavior I need is missing from the Smalltalk framework, I can simply add it. For example, I can add methods to String, to UndefinedObject (nil), to Stream, and so on. When I do that, *every* instance of the class that I extend in that way has access to the methods. In a similar way, I can add new classes anytime I want. In a modern Smalltalk, with EnvyDeveloper (such as VisualAgeSmalltalk), these extensions are subject to version and change management practices that are still the most advanced in the commercially-available world and exist precisely *because* of the extensibility of the environment. There are plenty of rough edges in Smalltalk, and there is plenty to complain about. Let's not, therefore, let red herrings like this go uncorrected. --TomStambaugh

Fixed is of course relative. Any decent framework can boast the ability to add to it. That's flexibility. Smalltalk is fixed in that the syntax is not changeable, it has an object model, memory management model, etc. If you change these things sufficiently it is nolonger smalltalk. This is the sense of fixed i mean. --AnonymousDonor

I'm sorry, AnonymousDonor, but I suspect you haven't spent much time in Smalltalk. The "syntax" doesn't need to change because, like LispLanguage, it is very sparse and contains little semantic information. The Smalltalk object model, memory model, and everything else IS changeable, and such changes are part of every mature Smalltalk application I'm aware of. For example, new control structures are easy to write -- try adding an "#ifNil:" message to another language. I built, sold, and supported a fully-functional exception system as an add-on to Smalltalk that ran within each of the extant versions of the time (Digitalk, ParcPlace, and Enfin) and required no virtual machine or compiler modifications. It is, again, simply incorrect to assert that changing the object model, memory management model, or similar things makes it "no longer Smalltalk". -- TomStambaugh

How is the "memory management model" not changeable ? I would have thought you can plug any kind of GC, since it's transparent to the programmer. (I hope you're not saying it would be preferable to leave memory management up to the programmer, as in C++ - in most contexts that would be foolishness, not flexibility.) As for the other things - you could vary syntax and still retain the same framework classes. You could add a MOP on top of Smalltalk to vary the object model and retain the same framework classes. SmallScript (http://www.smallscript.org) seems to do both to some extent.

I'm no Smalltalk expert (Tom above is, as I gather), mind you... but it seems to me that you could say of anything that it is "fixed" in the sense that if you change it sufficiently it is no longer what it once was. (That would be a strange thing to say... but true.) -- lb

Can i use smalltalk like c++? No. Let's not bother with the why would you or you can do that this way. It's fixed friends. Very flexible yet it has a nature. As humans we are fixed yet flexible. --AnonymousDonor

You can use Smalltalk like C++. You just don't know how.