Is Lisp more ideal than Smalltalk?

Paul Graham says in his book "Hacker and Painter" that languages of
today is walking the foot step of lisp invented in 1958. I thought it
was Smalltalk they are headed.

Paul knows about Smalltalk but leave out  mentioning the name in the
list of "langauges of 100 years from now" where lisp, ruby, python is
included.

In the other chapter, he mentions Smalltalk expressions are less
compact than those of ruby's or lisp's.

Is this a fair contest?

Let me clear up a couple things real quick...

- I love PG's writings (well, most of them).
- I love Lisp, so I may be a bit biased.
- I will assume this post is genuine (as opposed to a troll).
- I don't know Smalltalk all that well yet. :-)

> Paul Graham says in his book "Hacker and Painter" that languages of
> today is walking the foot step of lisp invented in 1958. I thought it
> was Smalltalk they are headed.
>
> Paul knows about Smalltalk but leave out  mentioning the name in the
> list of "langauges of 100 years from now" where lisp, ruby, python is
> included.

That last sentence really doesn't make all that much sense to me. Did
you mean you thought other languages were copying Smalltalk? If so, you
would be right. There are many languages out there that use the
Smalltalk object/message paradigm (Objective-C, Ruby, ...). Lisp
certainly did not invent OO programming - Smalltalk did.

However, I think you are misinterpretting what PG really is saying.
This essay has to be put in context with the other essays he's written.
Check out the following: (http://paulgraham.com/diff.html). Lisp really
did pioneer programming languages in many, many ways. The fact that
Lisp is still around, is able to be extended to include OO and other
language constructs easily is a testament to what makes Lisp great
(symbol programming and treating code as data).

I should also remind readers that 90% of the time PG is *not* referring
to Common Lisp, but to Lisp the language (and there is a huge
difference). Likewise, PG has an inherent dislike of OO programming (as
do I, actually), and so while he knows of Smalltalk, and has probably
programmed in it some, has never written any significantly large
program in it - so I wouldn't say he was excluding Smalltalk for any
reason other than he had no reason to include it.

> In the other chapter, he mentions Smalltalk expressions are less
> compact than those of ruby's or lisp's.

I think compactness is a joke. I can make C code look extremely
compact, but it would be unreadable. Lisp code is actually quite
verbose compared to a token-syntax language like C. The advantage Lisp
(and likewise Smalltalk) has is the ability to write more functional
code than traditional Algol (ie, imperative) languages. Everything is
an expression. In C, I have to write (yes, this is a trivial example
with many other ways of doing it):

if (x == 10) {
    y = 10;
} else {
    y = 20;
}

Where as in other languages, I am capable of doing:

; Common Lisp
(setf y (if (equal? x 10) 10 20))

; REBOL
y: either x = 10 [10] [20]

\ Forth
x @ 10 = if 10 else 20 then y !

"Smalltalk (I hope I get this right)"
y := (x == 10) ifTrue: [10] ifFalse: [20].

This, and the ability to solve the same problem in many ways (meaning
with different paradigms) is where code compactness comes from. Not
from short variable names, or lack of syntax.

> Is this a fair contest?

I think it is as fair as it can be for anyone who doesn't have
experience with everything. Computer languages can turn into religious
wars very quickly for no reason. Languages are tools. Use the one that
makes the problem simple to solve. Don't force yourself to use
Smalltalk for every problem out there when REBOL might make the
solution 100x easier.

However, what PG's essay was more about (if I'm thinking of the right
one), is that it took radical ways of looking at problems to come up
with Lisp. And Lisp did drastically alter the way we program forever.
PG was looking to the future, and wondering a few things:

- Will the solutions Lisp brought still hold 100 years later?
- What languages today are trying to do what Lisp did?
- Are there other ways we can be trying to solve the same problems?

If there was something about PG's essays that bothers me, it's that
he's taken quite the evangelistic approach to Lisp vs. other languages.
The only ones he casually lists in the "win" column are those that
steal from Lisp (typically Python). However, given the above questions,
he doesn't take enough effort to focus on languages that *are* trying
to look at the problems differently: Smalltalk, Haskell, Erlang, etc.

In fact, I'd argue that many of these languages are going to be (and
currently are) solving problems that Lisp had no need to solve, and
therefor won't be well suited to solving (for example, take a look at
what Erlang is doing with concurrency and distributed processing). Does
that mean they can't be solved in Lisp? No. But that's not the
argument, the argument is about which language(s) will lead us into the
future of programming.

Jeff M.

Jeff M. wrote:

> Lisp certainly did not invent OO programming - Smalltalk did.

Hmmm. Perhaps you can say that Smalltalk was the first language to
perfect object oriented programming, but as for inventing it wouldn't
that distinction go to Simula? And Lisp is certainly off the chart
since it's a functional programming language, not a purely OO
programming language.

gregarican wrote:
> Jeff M. wrote:
>
> > Lisp certainly did not invent OO programming - Smalltalk did.
>
> Hmmm. Perhaps you can say that Smalltalk was the first language to
> perfect object oriented programming, but as for inventing it wouldn't
> that distinction go to Simula?

Agreed. :-)

> And Lisp is certainly off the chart since it's a functional programming
> language, not a purely OO programming language.

I never said it was on the chart. And, while Lisp is certainly capable
of functional programming, it isn't a "purely" functional programming
language (like, say Haskell - or in the way that Smalltalk is "purely"
OO). There are plenty of side-effects in Lisp functions.

The only aspect of Lisp that is truly "functional" is that all
functions return a value. And by that criteria, wouldn't Smalltalk be
functional, too? Of course, this has been argued, debated, and mashed
to death on comp.lang.lisp (and probably comp.lang.functional). And I
don't think any true conclusion has been reached. :-)

Jeff M.

Jeff M.,

> Lisp really did pioneer programming languages in many, many ways. The fact that
> Lisp is still around, is able to be extended to include OO and other
> language constructs easily is a testament to what makes Lisp great
> (symbol programming and treating code as data).

I've later learn from the book that Smalltalk and Lisp share a lot of
features which make them so great like GC, typeless variable, treating
codes as data, and s-expression.

I come to think that lisp must have given a great deal of inspirations
to inventors of Smalltalk.


> I think compactness is a joke. I can make C code look extremely
> compact, but it would be unreadable. Lisp code is actually quite
> verbose compared to a token-syntax language like C. The advantage Lisp
> (and likewise Smalltalk) has is the ability to write more functional
> code than traditional Algol (ie, imperative) languages. Everything is
> an expression. In C, I have to write (yes, this is a trivial example
> with many other ways of doing it):

Some J fellows visit my blog and leaves some J code segments that does
the same thing as my Smalltalk code. Those codes are unbelievably
short. Especially for collect: do: kind of operation. But also those
codes are unbelievably unreadable to me.

The comparison give me a clear thoughts about compactness vs
readablity. Although, REBOL is the only language I do not know of, it
looks like the best considering both sides for this example.


> If there was something about PG's essays that bothers me, it's that
> he's taken quite the evangelistic approach to Lisp vs. other languages.

Many Java fellows hate my blog posts, because of the quoted text from
his book includes low-rating or sometime cursing Java. Considering how
I was tempted by his not giving top scores to a pure object oriented
language, Java guys must hate PG. But, ironically the book was
recommended by a Java guy to me. :-)

Thanks for everything,
Howard

Jeff,

> - I will assume this post is genuine (as opposed to a troll).

FWIW, I believe that is a safe assumption.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Howard,

> Paul knows about Smalltalk but leave out  mentioning the name in the
> list of "langauges of 100 years from now" where lisp, ruby, python is
> included.

Surely you don't imagine that PG would give free publicity to Lisp's only real
competition !  ;-)

Actually, I doubt whether he has much real understanding of OO.  He has not (in
any of his things that I've read so far) indicated that he "gets" objects at
all. (When people say things like "I know what OO is, and I use it only when
it's appropriate" I immediately conclude that they don't, in fact, know what OO
is.  Which may sound uncharitable, and if it offends anyone then I apologise --
but I'll still think it ;-)

I've been speculating for some time that there's something about Lisp which is
inherently antipathetic to OO thinking (yes, I do know about CLOS).  I don't
want to suggest that it's necessarily the language itself that is like that --
it's at least equally possible that Lisp just doesn't attract the kind of
people for whom OO thinking works.

It seems to me that the Lisp style of abstraction is very different from the
Smalltalk (or OO in general) style.  Lisp wants to build layers of abstraction
on top of each other -- you write Z, but that really evaluates to Y, which
evaluates to X, which evaluates to W, which...  And Paul's beloved macros[*]
fit very well with that way of doing abstraction.  But the Smalltalk/OO way of
abstraction does not work like that -- we don't have all those layers.  If we
need a new abstraction we create a new object and add it to the community of
interacting objects.  So as we create more and more powerful and expressive
abstractions we create more and more objects, but they are all just objects --
they live side by side in the "sea of objects".  You might say that Smalltalk
systems get wider while Lisp systems get taller.

([*] I have a personal opinion of a language which needs a macro system just to
express simple control-flow, and it isn't too complementary ;-)

    -- chris

Jeff

> [...] an inherent dislike of OO programming (as
> do I, actually)

If you really mean that word "dislike" then why are you learning Smalltalk or
using Dolphin ?

Please don't take the question as hostile, or as any kind of a "challenge": I'm
just curious about your motivation.  And, I suppose, about how you are finding
Smalltalk now you are here.

    -- chris

Chris Uppal wrote:
Hehe, not at all. I'm actually quite surprised myself.

Professionally, I develop console games for a living. And, typically, I
get to mentor a lot of new, out-of-college, programmers and teach them
good and bad programming practices before they dive into a (rather
large) code base.

Most of the time, we have a funny saying about the non-senior
programmers: they tend to "C++ themselves into a corner." :-)

Let me explain that a bit and perhaps that will explain where I'm
coming from. Also, keep in mind that 95% of my OO experience is C++,
and I'm using and teaching myself Smalltalk to see if OO has
possiblities outside of what I consider a terrible language - C++.

1. OOP (in my experience) makes it extremely easy for someone to "live
in header files". Meaning that they can design, design, design, and
abstract, abstract, abstract, forever (seemingly), without ever writing
one line of code that actually tests what they've done. Someday, they
will eventually have to compile and realize "oh, that doesn't quite
work". And instead of taking a step back and trying to simplify, out
comes the sledgehammer. :-)

2. In my programming career (C/C++ on Xbox, PS2, and assembly code on
8- and 32-bit handhelds - GB/GBA), it is *extremely* important to
iterate very fast. Given a design spec for something, I need to get it
up on screen very fast so a designer or artist can look at it and see
if that really is what they wanted. 90% of the time it isn't and I need
to keep molding it until they get what they want. If my first pass was
some huge class hierarchy with abstractions, that makes the molding
more difficult, and it was a gigantic waste of time - because most of
that code is going to get tossed.

3. It is infinitely more productive to just code in straight C, hack in
what's needed, mold it to get what they want with as little "code
design" and as I get closer to the final goal, I'll discover what the
design should actually be. Once found, then code it up nicely with
abstractions, etc.

4. In large code bases with a very deep class hierarchy and lots of
message passing going on, it can make it very difficult to debug and
extend. Especially if the programmer doing to debugging/extending isn't
the original author (which happens a lot in my business), even more so
if he's a new guy.

5. Not everything is an object (yes, I know this is controversial). :-)

Also, OO programming (again, in my experience) has a much higher
potential to lead to some very, very slow code. I don't know how many
times I've had to lay the "beat down" on a programmer for writing
something like this:

class vector3d {
    float x, y, z;
public:
    vector3d() { x = y = x = 0.0f; }
    vector operator + (const vector& v2) { ... }
};

This leads to some very, very, inefficient code. For those of you that
are C++ experts, there are numerous problems with this code, but that's
another area of OO (or possibly just C++?) that is unappealing to me:
it needs to be used correctly everywhere. There is no such thing as
using OOP 50%. Much like the good ol' const keyword: either use it, or
don't use it, but you can't half-ass it. Hopefully we're using it,
though. :-)

So, this is my experience with OOP. Dolphin has allowed me to try many
other things within the paradigm that are slowly opening my eyes a
little. I don't know that I'm a convert (I don't know that I ever will
be), but I'm starting to believe that many of the problems I see with
OO are problems with the language I'm using and not OO, itself.

However, I do think that some of the problems I've had are
(potentially) still there. Dolphin allows me to edit a running game,
which is awesome! But, it still requires the OO design up front. I
haven't found a way to just slap a group of functions together easily
to test out ideas. I still have to subclass here and there, and try and
see just how everything will talk to each other before I even know what
I'm doing. I'm still attributing most of this to lack of Smalltalk
knowledge, though.

I've been very curious what others with more Smalltalk experience think
about these observations. I haven't wanted to post them, because many
times people will take them as challenges, and many people have a
natural tendency to just slam the door quickly with a "you just don't
understand OO" or "you are a bad programmer" type of statement. But,
I've seen this group to be quite nice, very productive in nature, and
since you asked... :-)

Jeff M.

Jeff M. wrote:
>
> class vector3d {
>     float x, y, z;
> public:
>     vector3d() { x = y = x = 0.0f; }
>     vector operator + (const vector& v2) { ... }
> };

Oh my. Someone take away my programmer card, please. I can't believe I
"checked that in", without testing it. It should, of course, read:

class vector3d {
    float x, y, z;
public:
    vector3d() { x = y = z = 0.0f; }
    vector3d operator + (const vector3d& v2) { ... }
};

:-)

Jeff M.

Jeff,

> 1. OOP (in my experience) makes it extremely easy for someone to "live
> in header files". Meaning that they can design, design, design, and
> abstract, abstract, abstract, forever (seemingly), without ever writing
> one line of code that actually tests what they've done. Someday, they
> will eventually have to compile and realize "oh, that doesn't quite
> work". And instead of taking a step back and trying to simplify, out
> comes the sledgehammer. :-)

This is more about static languages than OO languages.  Smalltalk will
allow you to get things going much earlier than you can with a static
language w/o a live image.


> Also, OO programming (again, in my experience) has a much higher
> potential to lead to some very, very slow code. I don't know how many
> times I've had to lay the "beat down" on a programmer for writing
> something like this:

That depends.  Bad code is bad code, and you can write it with any
system.  Smalltalk shines the least at heavy fixed-precision arithmetic,
but one can always identify the trouble spots and move them into a DLL.
  Just yesterday, I replaced a Smalltalk loop with an exported function
in a slowly growing DLL, and had a huge speed boost.  The trick is to
move the right code, and to do so in reasonably generic ways.


> However, I do think that some of the problems I've had are
> (potentially) still there. Dolphin allows me to edit a running game,
> which is awesome! But, it still requires the OO design up front. I
> haven't found a way to just slap a group of functions together easily
> to test out ideas. I still have to subclass here and there, and try and
> see just how everything will talk to each other before I even know what
> I'm doing. I'm still attributing most of this to lack of Smalltalk
> knowledge, though.

Games tend to be big and complicated.  It is not surprising that you
would need some basic framework to have one work at all.  However, I am
confident that you would be vastly better off in Smalltalk than in C*.
Learning to exploit workspaces will help you a lot, as will making good
use of SUnit.


> I've been very curious what others with more Smalltalk experience think
> about these observations. I haven't wanted to post them, because many
> times people will take them as challenges, and many people have a
> natural tendency to just slam the door quickly with a "you just don't
> understand OO" or "you are a bad programmer" type of statement. But,
> I've seen this group to be quite nice, very productive in nature, and
> since you asked... :-)

You sound like somebody who is willing to consider alternatives.  You
will "get it" if you keep using Smalltalk.  Please note that interactive
games (especially 3D animation if that's your area) will be harder to
flatten out into a workspace and some test cases, but you will find many
tasks along the way that will lend themselves to it.

Happy Smalltalking!

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Chris Uppal wrote:
I don't think that there is anything in Lisp that is antipathetic to OO
thinking. Actually many of the larger software written in Lisp is heavy
OO-based. At the same time there is also lots of Lisp software that is
not OO-based. In Lisp you have a choice. For the large OO-systems
written in Lisp there are also very different approaches. CLOS was
designed not to represent a certain OO-language and style, but more
like a space of possible OO-languages. Many influences are coming from
knowledge-representation systems (Frame Systems, Semantic Nets,
Description Logic systems, ...). If you look at larger commercial
environments like LispWorks or Allegro CL, almost everything is written
using CLOS (streams, windows, database access, ...). Or if you look at
the Lisp Machines, which was based on thousands of classes (flavors).
These were large "seas of objects" - like millions of objects. Here (->
http://lispm.dyndns.org/genera-concepts/genera.html ) you can see it
explained. Since these environments and their libraries were written in
OO-style (Flavors and later CLOS), the applications also tend to be
that way.

The first OO-systems in Lisp were either Smalltalk-like
(message-passing) like Flavors or very different (Object Lisp was based
on prototypes, FRL (Frame Representation Language) was based on the
frame theory. Later Flavors migrated over New Flavors (generic
functions) to CLOS (generic functions with multi-dispatch). CLOS is
less Smalltalk-like in that it is not class-centric. The CLOS model
fits better into the Lisp world, where functions (which are objects)
and classes (which are also objects) are the building blocks.

>
> ([*] I have a personal opinion of a language which needs a macro system just to
> express simple control-flow, and it isn't too complementary ;-)
>
>     -- chris

Jeff,

> Professionally, I develop console games for a living. And, typically, I
> get to mentor a lot of new, out-of-college, programmers and teach them
> good and bad programming practices before they dive into a (rather
> large) code base.

Sounds fun...

(Actually, it /does/ sound fun -- but not without a large measure of
frustration too.)


> Most of the time, we have a funny saying about the non-senior
> programmers: they tend to "C++ themselves into a corner." :-)

A good phrase -- I hope you don't mind if (when) I steal it ;-)


> 1. OOP (in my experience) makes it extremely easy for someone to "live
> in header files". Meaning that they can design, design, design, and
> abstract, abstract, abstract, forever (seemingly), without ever writing
> one line of code that actually tests what they've done.

Yup.  A recognised problem with any form of abstraction, and probably worse for
OO than other forms (simply because OO is -- as abstractions go -- less
abstract ;-).  Some of the principles underling the "agile" methodologies
attempt to preempt this tendency by getting concrete very early.

Speaking for myself, I have found this to be less of a problem for me in
Smalltalk than other OO-ish languages I use (which is rather surprising).  I
think it may be because Smalltalk programming doesn't have a phase where I'm
essentially telling the compiler what code I'm /going/ to write later (if I
don't change my mind first).  Or maybe it's because I know that I don't have to
get everything right first time.  The compiler isn't going to be peering over
my shoulder carping about every little bit of sloppiness...

OTOH, in C++, once you have invented a suitable abstraction (in itself a
necessary and irreducible task, whether it is expressed as OO, Lisp, or just as
undocumented conventions in low-level code), you are then faced with the
necessity to convert it into C++ which the compiler will accept.  And that
is -- I think -- a major drag and easily confused with the cost of finding the
abstraction itself.  C++ isn't at all hostile to abstraction (it has several
abstraction mechanisms) but it does make /expressing/ an abstraction as robust,
efficient, code a distinctly non-trivial activity.


> 2. In my programming career (C/C++ on Xbox, PS2, and assembly code on
> 8- and 32-bit handhelds - GB/GBA),

Noted unusual target hardware -- that will definitely change the equations.


> it is *extremely* important to
> iterate very fast. [...]
> 3. It is infinitely more productive to just code in straight C, hack in
> what's needed, mold it to get what they want with as little "code
> design" and as I get closer to the final goal, I'll discover what the
> design should actually be. Once found, then code it up nicely with
> abstractions, etc.

You and I seem to think differently here.  For me, just dumping lots of
low-level code is the /slowest/ way to work.

(As an aside: IMO the XP manta -- which is often cited by non-XPers too -- is
just wrong.
    Make it work
    Make it right
    Make it fast
is a terrible waste of time.  Make it right /first/ -- otherwise you'll end up
chasing your own tail trying to make something broken work, and most of the
fixes you add will be discarded when you do finally "make it right")


> 4. In large code bases with a very deep class hierarchy and lots of
> message passing going on, it can make it very difficult to debug and
> extend. Especially if the programmer doing to debugging/extending isn't
> the original author (which happens a lot in my business), even more so
> if he's a new guy.

Hmm....   That, I'm afraid, I just plain disagree with.  Even in C++.


> 5. Not everything is an object (yes, I know this is controversial). :-)

Hmm....   ;-)



Yes, remembering the kind of hardware you are targeting, the costs of object
creation can be very significant (especially if expressed badly).

It's worth mentioning (though I imagine you know it already) that object
creation costs vary dramatically between languages.  For instance the corrected
version of the above class would be almost free if the objects were allocated
on the stack in C++.  In current Java they would be much more expensive since
Java's objects (like Smalltalk's) are always allocated on the heap.   (I'm very
much looking forward to seeing how [well] the upcoming escape analysis
optimisation in the JVM will work).  OTOH, the cost of allocating an object
from the heap is typically quite a bit higher in C++ than it is in real GCed
languages, so C++ programmers get a distorted idea of the costs of allocation
(relative to other languages).  Object creation times (on "normal" hardware) is
simply not an issue for most (not all) applications.


> So, this is my experience with OOP. Dolphin has allowed me to try many
> other things within the paradigm that are slowly opening my eyes a
> little. I don't know that I'm a convert (I don't know that I ever will
> be), but I'm starting to believe that many of the problems I see with
> OO are problems with the language I'm using and not OO, itself.

I think that /some/ of them are.  I wouldn't consider using unadulterated OO to
implement the engine for a multi-player shoot-em-up running on a mobile phones,
for instance ;-)


> However, I do think that some of the problems I've had are
> (potentially) still there. Dolphin allows me to edit a running game,
> which is awesome! But, it still requires the OO design up front. I
> haven't found a way to just slap a group of functions together easily
> to test out ideas. I still have to subclass here and there, and try and
> see just how everything will talk to each other before I even know what
> I'm doing.

Well, you have to know (in some sense) how the bits fit together, whether you
are banging some preliminary code out as objects or as old-fashioned functional
decomposition (or anything else (except perhaps Prolog's Horn clauses).
Personally I find it /easier/ if I can tear the problem apart into
non-overlapping bits before I start.  But if you prefer to do it the other way,
then that's your business.

BTW, if you do want to experiment in Smalltalk, but still using an initial
approach nearer to the one you prefer, then one way to do it is:
    Create a class (the name doesn't matter 'cos it isn't expected to mean
        anything).
    Create a method in the class (e.g. #main).
    Create an instance of the class in some workspace.
    Send #main to that instance.
And then you can create (in the debugger if you wish) as many other methods as
you like in that class.  They can call each other ad-lib, and -- as long as you
don't start making use of architecturally significant other objects (i.e. not
trivia like Stings, Integers, and so on)  -- then you can hack out whatever
non-OO code you like.

I'm not sure I'd recommend that way of working -- after all you are here to
find out more about how OO works (or doesn't) -- but it might make a less
daunting half-way house than full-on OO, and less inconvenient than trying to
use workspaces as if they were script files (which is not what they are for).

    -- chris

Chris Uppal wrote:
> Jeff,
>
> > Professionally, I develop console games for a living. And, typically, I
> > get to mentor a lot of new, out-of-college, programmers and teach them
> > good and bad programming practices before they dive into a (rather
> > large) code base.
>
> Sounds fun...
>

It certainly can be. :-)

> > Most of the time, we have a funny saying about the non-senior
> > programmers: they tend to "C++ themselves into a corner." :-)
>
> A good phrase -- I hope you don't mind if (when) I steal it ;-)

Hehe. Feel free. I've often though about adding it as a random .sig
every once in a while.

> > 1. OOP (in my experience) makes it extremely easy for someone to "live
> > in header files". Meaning that they can design, design, design, and
> > abstract, abstract, abstract, forever (seemingly), without ever writing
> > one line of code that actually tests what they've done.
>
> Speaking for myself, I have found this to be less of a problem for me in
> Smalltalk than other OO-ish languages I use (which is rather surprising).

The more I use Smalltalk, the more I'm agreeing with you. I think 90%
of this is because of the workspace. Being able to subclass ShellView
(for example), and then instantly create an instance of it and play
with it is very nice. Even better is being able to edit the class while
an instance is up and running and see the changes happen immediately.

> > 3. It is infinitely more productive to just code in straight C, hack in
> > what's needed, mold it to get what they want with as little "code
> > design" and as I get closer to the final goal, I'll discover what the
> > design should actually be. Once found, then code it up nicely with
> > abstractions, etc.
>
> You and I seem to think differently here.  For me, just dumping lots of
> low-level code is the /slowest/ way to work.

I understand exactly what you are saying, but I think there is a
disconnect here. Keep in mind that most of the time, I'm working from
within an existing code base. There is already a scripting system in
existence. So, when a designer says they'd like to see X implemented in
the scripting system, it's much easier for me to hack it in real fast
for two main reasons:

1. It allows the designer to see quickly if this is really what they
want (and believe me, either way, my changes will get undone via source
control).

2. It allows me to get a good feel for what the pitfalls are going to
be when I actually implement it for real. I might whiteboard it out
ahead of time, implement 5 abstractions, get half done and suddenly
realize "whoops, I forgot about Y". Then comes the question of redoing
it properly, or pulling out the sledgehammer (which, sadly, is usually
answered by time constraints more than it should be).

If, however, I'm writing the scripting system from scratch, and there
is nothing there to begin with, I whole-heartedly agree with your
statements.

>     Make it work
>     Make it right
>     Make it fast
> is a terrible waste of time.  Make it right /first/ -- otherwise you'll end up
> chasing your own tail trying to make something broken work, and most of the
> fixes you add will be discarded when you do finally "make it right")

Again, just a different setting. I do agree with you, but I have also
experienced time where this is the right way to do things as well. I
don't think one mantra fits all cases. :-)

Well, in console games, there is no new and delete. We do use dynamic
memory for some things, but it's a sad day when you are 1 week from
shipping to find that a tester that has been playing your game for 10
hours straight just ran up against a memory fragmentation problem. :-(

Aside from that, even objects created on the stack can cause lots of
undesirable overhead. Consider a class "Matrix3x3", which happens to
have 3 "Vector3d"s inside of it (m_rvec, m_uvec, and m_fvec).
Instantiating this object on the stack (unless coded very properly)
results in the matrix constructor calling 3 vector constructors, each
setting x, y, and z to 0, only to later have a copy operator bash over
them.

I'll be the first to admit that this is just bad programming and needs
to be avoided at all costs, but in my experience not many programmers
really know this (sadly). I shake my head every time I have to teach
another programmer what byte-ordering and data alignment are. And that
doesn't even begin to cover things like the instruction pipeline,
branch prediction, and cache misses. What do they teach in schools
these days?

Well, that last paragraph has almost nothing to do with OO, and was
strictly a rant. Sorry. But it does give a little foundation into my
background for what I'm thinking about when it comes to OO design vs.
just getting it done. :-)

Jeff M.

Jeff,

> > You and I seem to think differently here.  For me, just dumping lots of
> > low-level code is the /slowest/ way to work.
>
> I understand exactly what you are saying, but I think there is a
> disconnect here. Keep in mind that most of the time, I'm working from
> within an existing code base. There is already a scripting system in
> existence. So, when a designer says they'd like to see X implemented in
> the scripting system, it's much easier for me to hack it in real fast
> for two main reasons:

Ah, I see what you mean (I think).  Kick a gaping great hole in the existing
abstraction and plug it with a bucketload of newly cranked-out code just to see
how well it works.  Not caring if it breaks virtually everything else, as long
as it runs well enough for the new code to be properly executed.  Discard
changes (just close the image in Smalltalk ;-) and start writing real code with
benefit of newly gained knowledge....

Yes, I do that too, though probably nowhere near as much as you.  More often I
/remove/ code in that mode -- delete what I want to run without, patch
(brutally) anything which turns out to depend on it, and run.  Useful for
putting upper-bounds on potential performance tweaks, isolating bugs, and the
like.

But I don't see that practise as a reason to avoid OO, quite the reverse.
Personally, I wouldn't be able to violate an existing code base like that
without understanding it reasonably well first (at least in outline).  For me,
that means that it should have well-designed abstractions, and not too much
cross-coupling.  And my own preferred approach to that state is OO...


> I'll be the first to admit that this is just bad programming and needs
> to be avoided at all costs, but in my experience not many programmers
> really know this (sadly). I shake my head every time I have to teach
> another programmer what byte-ordering and data alignment are. And that
> doesn't even begin to cover things like the instruction pipeline,
> branch prediction, and cache misses. What do they teach in schools
> these days?

Java, SQL, and UML ;-)

    -- chris