Bottom-Up Programming vs Application Frameworks.
Cameron Ross
to the development of application frameworks? Specifically, I'm
looking for pros, cons, similarities, differences etc.
Thanks in advance.
Pascal Costanza
Application frameworks only make sense for a domain that is considerably
well-understood. Such frameworks fix certain behavior while providing
variability for other behavior. It's important to know what guaranteed
behavior should be, how varied behavior interacts with the fixed one and
where to place the hooks that client code can use. Deciding these things
upfront with no real experience in a certain domain probably leads to
wrong decisions in this regard and may be hard to refactor later on,
especially when you are then dealing with published interfaces that you
need to maintain or deprecate (with the respectively incurred costs).
When in doubt use an incremental approach and keep your options as long
as possible.
Some of the material in "The Art of the Metaobject Protocol" is related
to this and was turned into the notion of "Open Implementations" later
on. See http://www2.parc.com/csl/groups/sda/projects/oi/default.html
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Daniel Barlow
Bottom up programming is typically practiced by people who don't fully
understand the problem domain and are experimenting with the best
approach.
Framework creation is typically practiced by people who still don't
fully understand the problem domain, but have an unfortunate
combination of arrogance and lack of introspective ability, so fail to
realise that more exploration is needed.
OK, that's flamebait, but I'm sticking to it. If you show me a
useful framework I will counter by reclassifying it as a platform.
-dan
--
"please make sure that the person is your friend before you confirm"
William Bland
> Bottom up programming is typically practiced by people who don't fully
> understand the problem domain and are experimenting with the best
> approach.
>
> Framework creation is typically practiced by people who still don't
> fully understand the problem domain, but have an unfortunate
> combination of arrogance and lack of introspective ability, so fail to
> realise that more exploration is needed.
I find it well worth lurking on c.l.l just for the amount of sensible,
quotable material (like the above) that I find here.
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
Kenny Tilton
Daniel Barlow wrote:
> camero...@bestech.com (Cameron Ross) writes:
>
>
>>Does anyone have opinions regarding how bottom-up programming relates
>>to the development of application frameworks? Specifically, I'm
>>looking for pros, cons, similarities, differences etc.
>
>
> Bottom up programming is typically practiced by people who don't fully
> understand the problem domain and are experimenting with the best
> approach.
>
> Framework creation...
Is that what the OP meant? His OP was a little too terse for me to make
out his meaning. He did say, in confirmation of "framework creation",
"the development of application frameworks". But...
"development" might not have been meant as "software development".
perhaps he meant "the advent of application frameworks". I quickly went
for "advent", because I just cannot imagine anyone arrogant enough to
develop an application framework asking for advice. I concluded the OP
was asking "does the existence of app frameworks obviate the need for
bottom-up development". A response to that possible question later.
The tie-breaker for me was the request for "similarities, differences".
That would not make sense unless two alternatives had been posited (b-up
and app-fw).
And the answer (to the possible question) is... the advent of app
frameworks just solves that one problem. It means that, when I sit down
to use GTk or CodeWarrior PowerPlant or (I guess) Swing, certain
problems have been solved for me.
The remaining problem is my unique application functionality. If I am
not sure how to do that... hello bottom-up programming.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton
Oops. I left out an unwritten bit of answer: if the question meant
"should I use an app framework or bottom-up develop my own", well, app
frameworks are a lot of work, so try to use one of the shelf. They can
be a PITA depending on how flexible they are. The ones I have seen from
MCL and AllegroCL and (by reputation) from Lispworks have all the
flexibility one would image where Lisp is involved.
Even with Cells, I first used them alongside the MCL/MacOS framework.
Only when I got to win32 did I stop using native widgets (they
conflicted a little with my approach), but I still used winodws, menus,
and more from ACL's Common Graphics framework. Even in Cello, the
underlying Glut framework uses native windows and event streams. No need
to reinvent those (and become even less native).
Marc Battyani
> camero...@bestech.com (Cameron Ross) writes:
>
> > Does anyone have opinions regarding how bottom-up programming relates
> > to the development of application frameworks? Specifically, I'm
> > looking for pros, cons, similarities, differences etc.
A framework is only useful when you have to do some things often.
Note that the framework has probably been constructed in a bottom-up way and
is some kind of packaging of the bottom-up exploratory programming phase.
> Bottom up programming is typically practiced by people who don't fully
> understand the problem domain and are experimenting with the best
> approach.
>
> Framework creation is typically practiced by people who still don't
> fully understand the problem domain, but have an unfortunate
> combination of arrogance and lack of introspective ability, so fail to
> realise that more exploration is needed.
>
> OK, that's flamebait, but I'm sticking to it. If you show me a
> useful framework I will counter by reclassifying it as a platform.
From now on, I will talk about my web application platform ;-)
(More new paradigms!)
Marc
Paolo Amoroso
> OK, that's flamebait, but I'm sticking to it. If you show me a
> useful framework I will counter by reclassifying it as a platform.
It would be interesting if you could list a few frameworks that are
not useful.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Daniel Barlow
> Daniel Barlow <d...@telent.net> writes:
>
>> OK, that's flamebait, but I'm sticking to it. If you show me a
>> useful framework I will counter by reclassifying it as a platform.
>
> It would be interesting if you could list a few frameworks that are
^^^^^^^^^^^
> not useful.
ITYM "almost painfully dull". At least, you might find the result
interesting, but I would find the necesary research to produce it
grounds for self-harm. Five minutes following links from a Google
search from "application framework", and already my fingers are
starting to tingle.
Forcing your users to design their applications as a bunch of
callbacks invoked by your framework ("Inversion of Control", or IoC)
is /not/ a goal to aspire to: it's a necessary evil. It's what you do
when you're constrained by external forces (you're providing an
interface to some kind of interrupt-driven architecture, like a
network server) or when you have no imagination. Or both, perhaps.
I find it interesting to note the trend for using continuations and
similar constructs to invert interrupt-driven architectures the
/other/ way, so that the application programmer can write something
resembling a normal program. For that matter, we may as well note
that the typical multitasking operating system does exactly that as
well: deal with the external interruptions and provide the application
with the illusion that it's "in control". Inversion of Control is
for, well, inverts.
Kenny Tilton
Daniel Barlow wrote:
Invert? I think the preferred term is "girly-men". Your problem is
explaining the popularity of CAPI. Obviously working beautifully for
many a Lispnik. I wager Common Graphics is as effective.
Or are those platforms? :)
kt
Paolo Amoroso
> Forcing your users to design their applications as a bunch of
> callbacks invoked by your framework ("Inversion of Control", or IoC)
> is /not/ a goal to aspire to: it's a necessary evil. It's what you do
[...]
> with the illusion that it's "in control". Inversion of Control is
> for, well, inverts.
Speaking of inversion, let me invert my original question. Can you
name[*] one "system"[+] designed in a way that doesn't involve the
framework issues you mention? I'd like to see an example of what you
consider good and useful design.
Paolo
[*] If it takes less than 30 seconds.
[+] For appropriate values of "system".
Marc Battyani
"Daniel Barlow" <d...@telent.net> wrote
>
> Forcing your users to design their applications as a bunch of
> callbacks invoked by your framework ("Inversion of Control", or IoC)
> is /not/ a goal to aspire to: it's a necessary evil. It's what you do
> when you're constrained by external forces (you're providing an
> interface to some kind of interrupt-driven architecture, like a
> network server) or when you have no imagination. Or both, perhaps.
I don't know where you got this idea that framework equal IoC ?
The fact that most frameworks are written in low level languages makes them
use this model but it's obvious that a Lisp framework is not constrained to
this model.
> I find it interesting to note the trend for using continuations and
> similar constructs to invert interrupt-driven architectures the
> /other/ way, so that the application programmer can write something
> resembling a normal program. For that matter, we may as well note
> that the typical multitasking operating system does exactly that as
> well: deal with the external interruptions and provide the application
> with the illusion that it's "in control". Inversion of Control is
> for, well, inverts.
Continuations can be good but trying to fit all in the continuation model is
rather simplistic.
Marc
Kenny Tilton
Paolo Amoroso wrote:
> Daniel Barlow <d...@telent.net> writes:
>
>
>>Forcing your users to design their applications as a bunch of
>>callbacks invoked by your framework ("Inversion of Control", or IoC)
>>is /not/ a goal to aspire to: it's a necessary evil. It's what you do
>
> [...]
>
>>with the illusion that it's "in control". Inversion of Control is
>>for, well, inverts.
>
>
> Speaking of inversion, let me invert my original question. Can you
> name[*] one "system"[+] designed in a way that doesn't involve the
> framework issues you mention? I'd like to see an example of what you
> consider good and useful design.
I think he likes Cello-- we have discussed the possibility of his
getting involved with the project.
:)
kenny
Will Hartung
news:CfA7d.3478$4C.11...@twister.nyc.rr.com...
> Oops. I left out an unwritten bit of answer: if the question meant
> "should I use an app framework or bottom-up develop my own", well, app
> frameworks are a lot of work, so try to use one of the shelf. They can
> be a PITA depending on how flexible they are. The ones I have seen from
> MCL and AllegroCL and (by reputation) from Lispworks have all the
> flexibility one would image where Lisp is involved.
I'm a big fan of frameworks. But frameworks I think only help when you
already have a sense of the issues that they're saving you from,
particularly when you hit an issue that isn't addressed directly by the
framework and you may have to work around it. All of a sudden the framework
comes crashing down on you and you find yourself at the bedrock the
framework is built upon. Suddenly you find that it's really dark down there.
But, if you tried to solve a taste of your problem without the framework,
and erected your own rickety skeletal experiment first, then you'll find
that when the framework fails you (and they all fail, at some point, it's
the price of the their utility), you have a better idea on how to shore it
up and work your plumbing around and through it.
Simple example today is that I'm working on a simple webapp for a friend.
Despite have been invloved in a monster webapp, and even helped design at a
high level an earlier webapp, I've never need to build one from scratch, and
I've never spent hardly any time on the client end of the spec.
So, I went looking at the generic Java web frameworks, looking for a silver
bullet (talk about a daunting task). After flailing about in configuration
nightmares, false starts, and more infrastructure than application code, I
simply punted and am now just writing it from scratch, reinventing the bits
of wheels that I need for this small application. If you're familiar with
the frameworks, then I'm wasting my time. I know this, but I'm making
progress anyway.
When I'm done, I'm sure I'll have a much better appreciation of the benefits
of these frameworks. But as someone who hasn't needed them, it's easier to
move forward by contriving my own silly framework (mostly a base servlet
class). It's a right and wrong way to approach things. On the plus side, I
get a better understanding of the basic issues involved, on the minus I
don't get to take advantage of the things that the modern frameworks fix,
that will be an issue for me in the future, but of which I may well be
ignorant now. But it makes sense for me in this case.
Regards,
Will Hartung
(wi...@msoft.com)
Kenny Tilton
Will Hartung wrote:
> "Kenny Tilton" <kti...@nyc.rr.com> wrote in message
> news:CfA7d.3478$4C.11...@twister.nyc.rr.com...
>
>>Oops. I left out an unwritten bit of answer: if the question meant
>>"should I use an app framework or bottom-up develop my own", well, app
>>frameworks are a lot of work, so try to use one of the shelf. They can
>>be a PITA depending on how flexible they are. The ones I have seen from
>>MCL and AllegroCL and (by reputation) from Lispworks have all the
>>flexibility one would image where Lisp is involved.
>
>
> I'm a big fan of frameworks. But frameworks I think only help when you
> already have a sense of the issues that they're saving you from,
> particularly when you hit an issue that isn't addressed directly by the
> framework and you may have to work around it. All of a sudden the framework
> comes crashing down on you and you find yourself at the bedrock the
> framework is built upon. Suddenly you find that it's really dark down there.
Absolutely. And it is a permanent drag, because one never stops fighting
the framework. In fact, the deeper one gets into a project, the more one
stresses the framework. (Been there, done that.) Then one day one
realizes, jeez, if we had done this from scratch we would have been done
months ago, and /gaining/ speed because now one has a tailored system,
well-understood, and one you do not need to persuade someone else to
enhance.
Frameworks really are for girly-men, by which I mean folks who just need
to toss off a vanilla GUI for some app. Anyone trying to Change the
World will soon outrun a typical GUI and grab Cello. As a starter app,
not as a framework.
Speaking of which, I gotta check back into the Betty Ford Clinic for
Usenet addiction. I am famous (Fred says so) so I think I qualify.
:)