JustAnotherProgrammingLanguage

WhatThreeLanguagesWouldYouRecommend

I reckon not: though from an aesthetic point of view, some languages are more pleasant to read/write than others.

Anyone else care to (re)start the language wars?!

yes I would (IvanM). programming language matters for at least two reasons:

• the language can make a difference to how hard code is to change. hard to change = bad for XP
• it can effect the way you think

I (DaveKirby) agree. I am currently working in C++ and Python, and it makes a huge difference which language I use. XP is possible in C++, but painful in comparison to more agile languages.

--- so XP is such a brittle methodology that it is only applicable when using specific languages? (SomeAnonymousPerson)

'Sometimes smart people have the hardest time trading the "Guess Right" game for close communication and continuous evolution.' -- OliBye quoting KentBeck

there are certainly things in XP that are harder in some languages (e.g. refactoring) but other things that are very applicable whatever the language (e.g. Testing, ConstantBuild ...) (IvanM) And many things which don't even need a computer (Planning Game, On-site Customer, Stand-up Meetings ...)

---

so what makes refactoring harder in some languages? can anyone give me a concrete example, say Python easy as opposed to C++ hard?

Languages that have duplication in them are more work to refactor in. Can't speak to Python, but in C++ certain trivial refactorings typically require a lot more work than they should. In most C++ shops the class declarations are kept in one file (usually SomeClass.h or some such), the member function definitions in another (SomeClass.cpp or similar), with the scope resolution operator used to tie them together. This is reccommended practice with C++, it makes handling compile dependencies easier, amongst other things. In this sort of case, changing the name of a class, for instance, means changing many, many instances of the class name in SomeClass.cpp Some C++ shops keep in-line functions definitions in yet a third file, so they have to change a bunch of strings in two files. In Java (and, I imagine, Python), all the class is in one place, so may be renamed by changing one string, modulo the number of constructors there are.

Once the name of a class, to continue that example, has been changed in all the places it's used in the mechanics of defining that class, then it has to be changed in all the places it's refered to in use. If the language in question has a manifest typesystem (as C++ does), then that can mean a lot of declarations all over the system. In a language with an implicit type system (like Smalltalk) then it probably means a very few places where the class is refered to explicitly. -- KeithB

To answer the original question 'does the programming language we use actually matter when we program with XP?': Yes. The programming language matters when we program with XP. Note: the programming language also matters when we don't program with XP! IvanM

Indeed. Take Java, for instance. There are several forms of abstraction that standard Java does not support, or supports weakly--it has no genericity, it only just supports closures/blocks (whatever you want to call them) but in a very cawkward fashion, only the most recent edition (very likely not available on your palform yet) has support for contracts, and that very weak, its package system is very poor, as is its reflection mechanism and so on. C++ does a much better job with genericity and packages and Ada is better still, the Lisps and Smalltalk do much better with closures/blocks and reflection, a whole bunch of languages do contracts better one way or another and so on. By working in a given language, one chooses which abstraction techniques will be easier for you, and which harder.

Choose, for whatever reason, to use Fortran 77, for instance, and you rule out using recusion. That's ok if your problem is best expressed iteratively, otherwise it's going to make your life harder than it might be. But using Fortran 77 might have advantages that outweigh that anyway.

Returning to XP: XP's coding practices place a premium on clear expression of ideas, on changing existing code to improve it, and on making code easier to change in future. There are numerous features that a language can have which make that style of programming easier, so XP will be easier to do if those languages are used. As it happens, many of those features are amongst those that Java doesn't do particularly well. That makes Java a less good language for XP than some others, but also better that some others again--XP style will be easier with Java than with COBOL. But as Ivan hints, that's mainly because almost any kind of development will be easier with Java than with COBOL.

It seems clear that choice of language will have an impact on project velocity, but not simply that a team using Smalltalk can go faster than one use C++ for mechanical reaons. Languages that support a wide range of abstraction mechanisms (and do them well) lend themselves to writing smaller, cleaner, easier to maintain and more likely to be correct programs than do languages that support a smaller range. A poor fit of language features to problem area will result, I suspect, not just in a team that can't go as quickly, everything else being equal, but a team that slows to a stop.-- KeithB

It's an interesting question, OliBye started off thinking it does matter, then wrote something, then realised that if you're really "DoingIt". It doesn't matter that much. All that matters is that you want to do XP, and you will find a way. ChrisCottee and I once wanted to write some tests for some JavaScript in a webpage (JsUnit), we didn't start off using tests as we didn't know how to, and JsUnit didn't exist, so what do you do when something doesn't exist? You go and write it, we didn't do a full port of JUnit, we only needed to check the order somethings were getting called. The point is that you "can" do XP in any language, it's just harder in some languages as you may have to write the tools to do it, or invent some new coding style TimMackinnon and OliBye invented MockObjects in this way. -- OliBye

But this "is" the XP way, you bump into something which slows you down, you some up with a clever tool to go faster (once upon a time the clever tool that people wrote was a compiler). At the end of the day people (PhilipCraig?) have even recoded everything in another language, this can actually be really easy if you have all the tests, as I've not come across a language that can't make calls to another language, and therefore be able to run tests. Yes it may be appear difficult, the SimplestThing? often is ;-) -- OliBye

I have a last example, KevinHutchinson and I worked as JamesCapelAndCo?, we weren't allowed to use C++ classes but I really wanted to use inheritance and overriding for something I was doing, so I ended up coding in a C style that passed virtual call tables, full of function pointers in the same way that the C++ compiler does. --OliBye

IMHO if you see stumbling blocks like "change language" instead of seeing opportunities for improvement, like "change language" :-) then XP isn't for you. Pessimism is the job of the other guy in the pair! --OliBye

All of which is engagingly up-beat and gratifyingly macho, and actually supports the contention that yes the choice of language does matter (and does matter whether you're doing XP or not).

Doubtless an uber-geek like Oli can fake up vtbls and such in fairly short order, but what about the average programmer? Or even the merely above average ones?

Time spent concocting frameworks to get round limitation in the development environment is time spent not delivering business benefit (hence my "change langage... " doctored KentBeck quote --OliBye). So you'd better be able to give a convincing argument as to why you're doing that. This framework built to support some abstraction mechanism that you happen to like better than the ones provided might provide benefits to the customer in the future, or then again it might not. To mention compilers in this context is disingenuous. Can you imagine saying to a client, well there's a bunch of stuff that hasn't been done yet, but once we've implemented this other language that we'd rather be working in here, boy you'll see us go fast! It may very well turn out to be true, but they'd be right to show you the door. If, on the other hand, the environment already supports the mechanisms you like, plus some more, then the risk isn't there. It doesn't matter that the environment supports mechanisms you don't want to use right now, becuse the next developer to work on this thing may very well. The richer the environment is "out of the box", the less the risk in all but the shortest short term.

(OliBye agrees somewhat, but thinks that OO programming is about making new languages, so XP works better with an OO language. But it doesn't absolutely require it, it just requires that you understand the business benefits of any code you write)

Now it surely is the XP way to build tools to go faster. For example, we have a bunch of perl scripts to create branches, bring changes from the mainline into a branch, and integrate a branch back onto the mainline. These scripts enhance the capabilities of our configuration management tool. There is an existing tool that does pretty much what we want, and more: TeamStreams. For various reasons, it's not avilable to us. But if it were, we'd be getting the same (if not more) speed-up in doing CM tasks that we get from the scripts, plus we would have saved the time taken to develop the scripts. So not having access to TeamStreams did matter Maybe not by much, but some. Now these scripts don't added any functionality to the tool we've got, they just automate already well understood manual processes. The cost of developing them was easy to justify, since the time lost in doing merges etc. manually (and the time spent untangling the mess if someone got a bit of the process wrong, as happened occasionally) was plain to see, and the task was bounded: automate this process. The cost of tuning up J2meunit for our platform was justified in a similar way.

We also have some scripts written in NT .bat files They also automate some fiddly, error prone processes, in the build, this time, rather than CM. But the build is changes from time to time. So these scripts are rapidly becoming more trouble than they're worth, since they are very hard to understand even for the pair that wrote them, and very brittle. Some time soon the pain will become too much and we'll re-write them in perl, probably (or maybe Python). The time spent struggling with .bat, rather than the problem in hand, is time that could have been spent on adding value to the customer if we had written the scripts in perl the first time round.

OliBye -- I thought this was the whole point of XP, you don't know this cost until later. Then and only then, can you justify spending more time on it, as you have a good idea of what it's costing you. Surely anybody who ever says "...if we had done X the first time it would have saved time..." is not adding any information to discussion. Ofcourse if you make the correct decision at any point you won't have to back track, the key is not to decide on anything to big (like changing languages) unless you really have to, and you have spiked out a few of the bits your unsure of (as you've said you actually do).

The observation that we would have saved time if we'd used perl first time round captures crucially important information. The next time we come to write some scripts (which, as it happens was today) we know to go immediately to perl, which we did. When perl starts causing us pain, we'll try spiking a task with some other language. If language didn't matter, we'd have no need to go round this loop. Another point of XP is that aftger you'de done it a few time, you do know the cost.

Choice of language, tools, environment does matter. It matters by differing amounts depending on who's doing the programming, what the problem being addressed is, and a bunch of other stuff. In one engagement it might turn out to matter very little. Another, it could make or break the project. But always, it does matter.

It only matters in the end, but have YouReachedTheEnd. Have you hit all the problems that will cause you to change languages. Can you say for certain that there won't be something down the line that causes you to change language. OliBye's point is JustFuckingDoIt as you'll never reach the end anyway. Don't be scared to start with any language that you're confident with. And don't be scared to toss it if it's not working for you.

Here's a quick reductio: if the choice of language truly didn't matter, then it would be perfectly valid to begin every project with nothing more than a hex editor and a photocopy of the machine instruction set and OS entrypoints. Any higher level constructs that that would just get written as needed. Hell, just give us a boot monitor and we'll roll our own OS.

OliBye would go further, Charles started with idea's about cogs. He didn't choose Java, but if he'd worried about that we wouldn't be trying to choose between java and something is. The only thing that matters about your choice of language is that you shouldn't be afraid to change your choice if you made the wrong choice. Since at any point in time, you can't go forward in time to check you made the right choice it doesn't really matter too much. If you've got this far on this page, stop reading and wasting customer time. It doesn't matter this much!

Now that would be a shit load of fun! That's the kind of project that people who like programming qua programming have wet-dreams about. But what kind of client is going to pay us to recapitulate the highlights of fifty-odd years of industry development when what they want, lets say, is to be able to flog their product to anyone with a modem and a credit card number. And they want that before the oppo has it.

On the other hand, to refuse to allow developers to innovate, to stop them spending any of the client's money on tools to help them do a better job faster (for the client) would be equally bad. Well, maybe not equally bad, but bad.

So the balance lies somewhere between the two. Where that balance lies must surely depend on what facilities the language and toolset gives you natively, and also how easy it is to change or extend. So either way, choice of language does matter.

Yes if you choose a language that you can't change from then you're in trouble, but that according to Church would be impossible, so JustFuckingDoIt -- OliBye hehe (I'm I talking to IvanM or KeithB).

He he yourself. There's change and there's change. Speaking of Mr Church, someone in the FP world once said "Even Alonzo Church himself would not have chosen lambda if he'd had to type it out each time."

OliBye finally agrees with the pedantic statement "choice of language does matter", but he maintains you'll only really find out why in the end. I was taking exception to the statement "so XP is such a brittle methodology that it is only applicable when using specific languages? (SomeAnonymousPerson)". In that I personally thing you can apply the process to any team. It may well be the first thing you do is to change languages, but I'd rather have a good build process and some functional tests in place first. Understand why we need to change, then migrate parts of it. I.e. JustFuckingDoIt and don't worry, the process will tell you if you're using the wrong language, JustFuckingDoIt, you'll end up using the right combination of languages to deliver this iteration. JustFuckingDoIt, have somebody go wild and spend a GoldCard playing with trying a different language.

Chapter 25 of the good book is about when you shouldn't do XP, it mentions "technology that doesn't support graceful change". But my point is along the lines of Kent's point in this chapter. The biggest barrier is the culture, if you can't accept that your choice of language maybe wrong and you ""Won't change"" then don't do XP.

'Sometimes smart people have the hardest time trading the "Guess Right" game for close communication and continuous evolution.'

Which is true enough. Luckily though, choice of language isn't even mostly about guess work, it's mostly about applying what you learned last time. Tommorrow's weather will likely be very similar to todays: if C++ caused you a royal pain in the arse on the last project, it likely will on the next one too.

OliBye asks KeithB WouldYouUseJavaOnEmbeddedDevices³host³³date³January 31, 2002³agent³Opera/6.0 (Windows 2000; U) en?³JustAnotherProgrammingLanguage