XP and choosing a language for a project

I'm trying to sell a client on having a new project done using XP, and I'm
thinking ahead to what I'll be trying to do in the inception of the project.

One question that comes to mind is what programming language to use.  Asking
that begs the question the best language for what?  That's a good question,
and with XP we're not supposed to have to look too far ahead.  Without BDUF,
though, how can we guess what is the best language to pick?

I was thinking that perhaps, the choice of language should be allowed to
change later, since the one of the points of TDD is to make change possible 
to
do safely and confidently, but doesn't that mean translating all the tests
into another language?  That doesn't sound trivial to me.

Any thoughts or experiences related to this question?

Steve Jorgensen wrote:

> I'm trying to sell a client on having a new project done using XP, and I'm
> thinking ahead to what I'll be trying to do in the inception of the
project.
>
> One question that comes to mind is what programming language to use.
Asking
> that begs the question the best language for what?  That's a good
question,
> and with XP we're not supposed to have to look too far ahead.  Without
BDUF,
> though, how can we guess what is the best language to pick?

TDD works best with dynamic typing. That means the compiler can compile
object.method() where object is any object in any inheritance hierarchy, not
just one sharing a 'method()' function. Late binding makes a language work
as if all objects inherited an invisible Object class containing every
possible method.

The big vendors push static typing - C#, Java, VB - because they make
wizards, form painters, and intellisense easier to add to IDEs. That allows
the big vendors to push their language by adding programmers to their IDE
projects until these become the selling point.

Think of how many pointy-haired bosses have been told, "see, with VB you can
just paint an app - no more coding!"

> I was thinking that perhaps, the choice of language should be allowed to
> change later, since the one of the points of TDD is to make change
possible to
> do safely and confidently, but doesn't that mean translating all the tests
> into another language?  That doesn't sound trivial to me.

To change languages, start with a binding layer between the two languages.
Then migrate functionality - over many releases - into the language that
best supports it. The loser language's modules should then shrivel up.

--
Phlip
http://industrialxp.org/community/b...tUserInterfaces

Phlip <phlip_cpp@yahoo.com> wrote:
> Steve Jorgensen wrote:
 
 

Careful: This can easily develop into a semi-religious flamewar.

IMHO, it's more important that your programmers are comfortable with
some language and the libraries. If most of them have to learn
a new language and new libraries, that will eat up a lot of any
advantages this new language will have. Finally, most languages
support some way to communicate with, or link with, other languages;
so you can still change your mind later on, XP style.
 

Exactly.
 

But you have some knowledge what this project will be about. This
is enough to choose the initial language.

> TDD works best with dynamic typing.

Or with "proper" static typing, i.e. not the kind found in C++ or Java,
where static types often "get in the way". In a language with static
type inference (say), you can think of types as automatic dataflow tests
generated by some tool, so you have an additional "meta-language" to
express some kinds of tests in. Additionally, there are tools
(e.g. QuickCheck for Haskell) which can automatically generate tests
with random values for you, made to fit the type signature. Then,
you do TDD in "predicate" style, e.g. to specify a sort routine
you say "I require that the values are sorted after the routine
finishes", and use pseudo-random sets of input values to verify this.

> To change languages, start with a binding layer between the two languages.
> Then migrate functionality - over many releases - into the language that
> best supports it. The loser language's modules should then shrivel up.

Exactly. Also, it's ok to use different languages in the same app.
For example, many games use some scripting language for the higher
level game description, and some other language to do the time-critical
stuff with.

- Dirk

On Fri, 3 Sep 2004 15:12:08 +0200, Dirk Thierbach <dthierbach@gmx.de> wrote:

>Phlip <phlip_cpp@yahoo.com> wrote: 
> 
> 
>
>Careful: This can easily develop into a semi-religious flamewar.
>
>IMHO, it's more important that your programmers are comfortable with
>some language and the libraries. If most of them have to learn
>a new language and new libraries, that will eat up a lot of any
>advantages this new language will have. Finally, most languages
>support some way to communicate with, or link with, other languages;
>so you can still change your mind later on, XP style.
> 
>
>Exactly.
> 
>
>But you have some knowledge what this project will be about. This
>is enough to choose the initial language.
> 
>
>Or with "proper" static typing, i.e. not the kind found in C++ or Java,
>where static types often "get in the way". In a language with static
>type inference (say), you can think of types as automatic dataflow tests
>generated by some tool, so you have an additional "meta-language" to
>express some kinds of tests in. Additionally, there are tools
>(e.g. QuickCheck for Haskell) which can automatically generate tests
>with random values for you, made to fit the type signature. Then,
>you do TDD in "predicate" style, e.g. to specify a sort routine
>you say "I require that the values are sorted after the routine
>finishes", and use pseudo-random sets of input values to verify this.
> 
>
>Exactly. Also, it's ok to use different languages in the same app.
>For example, many games use some scripting language for the higher
>level game description, and some other language to do the time-critical
>stuff with.
>
>- Dirk

Thanks to you both.

I'm not afraid of trying a new language.  So far, my experience with TDD is
that it makes it pretty easy to learn the important aspects of the language
for each piece of the problem domain as you go.  Learning Java using TDD has
so far been a breeze, and the tests showed me right away when I misunderstoo
d
something.

Given all that has been said above, what are some of your favorite languages
for writing MRP-type apps using XP?  What you say about static typing seems
valid, but I'm also concerned that a client may be uncomfortable not using o
ne
of the big 2, Java or *.NET.  Beyond that, Ruby looks nice.  I was also
thinking, if I made sure all teh tests passed under JRuby, then I could say
that the software was J2EE compatible.

Also, you mentioned type inferrence, but all the information I can pull up
with Google seems to be about this as a research topic, not something that's
implemented anywere.  Do you know of any actual implementations?

With respect to Haskell, I'd be concerned that it's non-oop (O'Haskell,
perhaps?) and that there aren't a lot of functional programmers out there to
maintain the software once it's in place.  Not saying I wouldn't choose it,
just that's a concern.

With respect to Design by Contract, to me, a distinguishing factor of TDD is
the fact that the tests define the app more so than the code, so putting
contracts within the code seems like moving in the wrong direction, unless t
he
contracts are never used instead of the tests, but in addition to the tests,
to verify the code more generally instead of just by example as with the uni
t
tests.

Steve Jorgensen <nospam@nospam.nospam> wrote:
> Also, you mentioned type inferrence, but all the information I can pull up
> with Google seems to be about this as a research topic, not something that
's
> implemented anywere.  Do you know of any actual implementations?

Haskell, OCaml and SML are perhaps the ones who have been around longest,
so they are quite mature. There's a bunch of others, more experimental
languages.

> With respect to Haskell, I'd be concerned that it's non-oop (O'Haskell,
> perhaps?)

O'Haskell is not mature enough. OCaml has objects, if you really need
them. Most things that are done with objects can be done in a different
way in functional languages.

> and that there aren't a lot of functional programmers out there to
> maintain the software once it's in place.

Yes. That's why I said you should choose a language your programmers
are comfortable with, even if, as you say:

> I'm not afraid of trying a new language.

[...]
> With respect to Design by Contract, to me, a distinguishing factor
> of TDD is the fact that the tests define the app more so than the
> code,

But it's the same idea in this respect: In DbC, the contracts define
the app more so than the code. The only difference is that tests are
more specific.

And BTW, I wasn't talking about DbC (which focuses on the *contract*),
but really about testing, only in a more general way. The tests
you write with tools like QuickCheck rarely form the types of contracts
you start with in DbC (but of course you could do them this way).
Instead, you check properties of your code. But instead of pinning
down these properties on one particular example ("specification
by example"), you can now test them for many random examples.
In contrast, DbC is normally not testable -- all you can do is
check that the contract is never violated during the actual execution.
But you'd still have to write all the tests yourself.

> so putting contracts within the code seems like moving in the wrong
> direction,

Huh? Why should you put contracts within the code? QuickCheck tests
are external to the application code, like TDD tests.

It's nice to have them close to the actual code, for documentation
purpose, if you want; but you don't have to do that.

- Dirk

On 2004-09-03 04:39:10 -0700, "Phlip" <phlip_cpp@yahoo.com> said:
> The big vendors push static typing - C#, Java, VB - because they make
> wizards, form painters, and intellisense easier to add to IDEs.

Actually, dynamic types support interface design tools -- which you
continue to insist on calling "form painters" -- very well.  Cocoa and
Objective-C are built to use Smalltalk-style dynamic dispatch, and
that's where they get a lot of their power.  Interface Builder *relies*
on it!

> Think of how many pointy-haired bosses have been told, "see, with VB you c
an
> just paint an app - no more coding!"

This is not a reason to avoid solid human interface design tools like
Interface Builder.  Not at all.

With Interface Builder, I can't create a good application without
coding.  What I can do is create a good application without writing --
*or generating* -- lots of tedious interface layout and wiring code.
That interface layout and wiring is all handled by the tool and its
interaction with the dynamic runtime, letting me focus on the rest of
the application.

This provides significant benefits for speed of development and doesn't
get in the way of test-driven development.  It also improves the
reusability and refactorability of applications, because there's simply
less code to deal with and better-defined interfaces in what code there
is, at least when it comes to interfacing between the model,
controller, and view objects.

Phlip, you should get some sort of access to a Mac running Mac OS X
10.3 and try out Objective-C, Cocoa, Interface Builder, and Cocoa
Bindings.  I think you'd really take to it.

-- Chris

--
Chris Hanson <cmh@mac.com>
http://www.livejournal.com/users/chanson/

Chris Hanson wrote:

> Phlip, you should get some sort of access to a Mac running Mac OS X
> 10.3 and try out Objective-C, Cocoa, Interface Builder, and Cocoa
> Bindings.  I think you'd really take to it.

A> Macs suck. I hit <Alt+Tab>, nothing happens, and I get too pissed
off to grab the stinkin' mouse

B> GUI Toolkits often augment their form painters with a "Class Wizard",
to manage lists of links between controls and their event handlers. In
my parables, form painters and wizards will often play the role of the
"Big Bad Wolf". These tools are not the problem. Enabling
programmers to neglect tests is the problem. Beefing tests up with
application-specific features that exceed generic form painters and
wizards' ability to propel development is the solution.

C> does intellisense work on this platform?

--
Phlip
http://industrialxp.org/community/b...tUserInterfaces

On 2004-09-05 08:13:18 -0700, "Phlip" <phlip_cpp@yahoo.com> said:

> Chris Hanson wrote:
> 
>
> A> Macs suck. I hit <Alt+Tab>, nothing happens, and I get too pissed
>      off to grab the stinkin' mouse

Wow, you should probably work on that anger-management then.  ;)

For the past five years, if you hit Command-Tab on a Mac, it has
switched applications.  On modern releases of Mac OS X you even get a
nice overlay window while switching.

The Command key on a Mac is where the Alt key is on a PC.  It's the key
with an Apple logo and a "cloverleaf" on it, on either side of the
space bar.

> B> GUI Toolkits often augment their form painters with a "Class Wizard",
>       to manage lists of links between controls and their event handlers.

There is no "Class Wizard" in Cocoa or Interface Builder that does
this.  It also doesn't need to be done manually (though you can if you
really want to) except in one single specific case I can think of off
the top of my head.

Target-action connections between controls and their controllers are
part of the information that Interface Builder archives in a nib file
-- a serialized representation of your interface that can be easily
reconstituted at runtime.  ("Nib" stood for "NeXT Interface Builder"
once upon a time.)  As are outlet connections such as ivars that refer
to controls; they also get wired up automatically when a nib file is
loaded.  As are bindings between control properties and model object
properties; they also get wired up automatically when a nib file is
loaded.

> In
>       my parables, form painters and wizards will often play the role of t
he
>       "Big Bad Wolf".

Which is exactly my point!  They play the role of the "Big Bad Wolf" in
your parables even though -- at least on some platforms -- they are
completely undeserving of that role.

If you targeted *specific* such tools for your "Big Bad Wolf" role, it
wouldn't bother me so much.  But it really does bother me to see you
making general assertions about "form painters" that *just aren't true*
of major applications in that category.

> These tools are not the problem. Enabling
>       programmers to neglect tests is the problem. Beefing tests up with
>       application-specific features that exceed generic form painters and
>       wizards' ability to propel development is the solution.

My assertion is that *good* interface design tools, in combination with
good tests, will exceed even that.

In other words:

(1) The kinds of "form painters and wizards" that you set up as
strawmen will get you to point A in time T.

(2) Full-on TDD will get you to point A in time 0.5*T.

(3) A really good interface design tool and supporting framework will
also get you to point A in a time somewhere around time 0.5*T.

(4) Full-on TDD with a really good interface design tool and framework
will get you to point A in time 0.3*T.

That's why I say you should try Cocoa and Interface Builder.  They're
#2 by themselves, and they're #4 when combined with any of the
available Objective-C unit testing frameworks.  (There are several.)

> C> does intellisense work on this platform?

I believe IntelliSense is a trademark referring to a specific vendor's
specific technology for auto-completion in a code editor.  So no,
IntelliSense doesn't work on this platform.

However, if you mean "is there auto-completion in the code editor on
this platform" then yes, there is.  Xcode -- the IDE itself, Interface
Builder is a separate app -- has quite good auto-completion.  I don't
know what the default configuration for it is, but it's very easy to
set up (just a couple checkboxes) and on any reasonably modern hardware
will be plenty fast.

The full Xcode 1.5 tool suite, including the IDE, compilers, headers,
Interface Builder, performance tools, etc. is a free CD-image download
for anyone running with a free membership in the Apple Developer
Connection <http://developer.apple.com/>.  It requires Mac OS X 10.3.
(You can also order a CD of it if you don't want to download a few
hundred megabytes.)

-- Chris

--
Chris Hanson <cmh@mac.com>
http://www.livejournal.com/users/chanson/

"Steve Jorgensen" <nospam@nospam.nospam> wrote in message
 news:qmfgj09i7i9aivgh2dehb1ore1jke49mca@
4ax.com...
> I'm trying to sell a client on having a new project done using XP, and I'm
> thinking ahead to what I'll be trying to do in the inception of the
> project.
>
> One question that comes to mind is what programming language to use.
> Asking
> that begs the question the best language for what?  That's a good
> question,
> and with XP we're not supposed to have to look too far ahead.  Without
> BDUF,
> though, how can we guess what is the best language to pick?

Without getting too far into all the stuff, I wouldn't say you shouldn't
look ahead. You shouldn't look ahead in excruciating detail. You should
know the general shape of the project going in, though.

You don't have to go into a whole lot of depth to know what's
a good language for a particular project, especially since local
politics will certainly play a part.

> I was thinking that perhaps, the choice of language should be allowed to
> change later, since the one of the points of TDD is to make change
> possible to
> do safely and confidently, but doesn't that mean translating all the tests
> into another language?  That doesn't sound trivial to me.

Language is one of the things that I'd put some thought into, because
it isn't all that easy to change unless you plan on rewriting the entire
code base.

>
> Any thoughts or experiences related to this question?

John Roth