Minimizing the language tax
Avdi Grimm
I noticed in re-reading Steve's piece that he saw multi-lingual
programming imposing a large tax on organizations he's worked for in
the past, in terms of support infrastructure. Now, I haven't run into
this problem yet, but I believe Steve when he says he has... so, what
are people's thoughts on minimizing the cost of polyglot programming?
Personally, the first thing that comes to mind is emphasizing making
projects self-contained - try to, as much as possible, put
*everything* under version control with the project - libraries, build
tools, etc. - possibly even the language runtime itself. This is a
good idea anyway, because it isolates a project from being
unexpectedly broken by system updates. But I think having projects be
batteries-included out of the box is especially important when dealing
with multiple languages that not everyone is familiar with.
--
Avdi
Home: http://avdi.org
Developer Blog: http://avdi.org/devblog/
Twitter: http://twitter.com/avdi
Journal: http://avdi.livejournal.com
Mike Pence
many large corporations see an Enterprise Service Bus -- a suite of
high level services -- as the path to sanity. By writing to standard
interfaces, like SOAP or REST, some companies are finding a path to
sanity.
Best,
Mike Pence
James Tucker
On 10 Apr 2008, at 16:13, Avdi Grimm wrote:
>
> On a tangent...
Definitely an interesting one... :)
> I noticed in re-reading Steve's piece that he saw multi-lingual
> programming imposing a large tax on organizations he's worked for in
> the past, in terms of support infrastructure. Now, I haven't run into
> this problem yet, but I believe Steve when he says he has... so, what
> are people's thoughts on minimizing the cost of polyglot programming?
We ran into this some time ago. We run a small shop that will actively
choose 'the tool'. The issue comes in when you're low on
infrastructure maintainers (in our case 'me' (although a few others
also 'could')) and/or you have varying infrastructure policies (user
account per customer vs a /var splash or something (yup...)).
Platforms are a major area here. We're currently running OS X,
Windows, Linux (in three flavours), and BSD (in two flavours). The
language list is just silly, as you might imagine.
The problem comes when you 'just need it' on another platform, and it
takes out a man-day sorting that out. Whilst it's loosely "OK" to say
this is a build script issue, the demand in an agile style procedure,
comes 'late in the game'. Combined with 'the simplest thing that could
possibly work', this can lead to terrible loss of time during platform
shifts, under certain circumstances.
> Personally, the first thing that comes to mind is emphasising making
> projects self-contained - try to, as much as possible, put
> *everything* under version control with the project - libraries, build
> tools, etc. - possibly even the language runtime itself. This is a
> good idea anyway, because it isolates a project from being
> unexpectedly broken by system updates. But I think having projects be
> batteries-included out of the box is especially important when dealing
> with multiple languages that not everyone is familiar with.
Absolutely, although I'd go one step further and say that focused
cross-platform well abstracted configuration, build and installation
management of all dependencies and internal software is key. This gets
increasingly difficult the more Open-Source you use (where often the
OSS nature leads to complex dependency chains and typically awful
build scripts). There can be a major advantage to carrying stock
'platforms' around, and this is where Java, pkgsrc, and some pieces
like that come into play. Hell, flash has played a role like this for
us in one project.
With regard to platform differences, I've started going very much more
polygot with that too now. I learn the paradigms and philosophies of a
particular say, linux distro, and then follow them. So when choosing a
DNS server, I'll check what 'the distro' prefers, and unless
diabolical, I will use that product. The idea is in the hope that
someone can hit the system, and decide how it will be set-up based on
what it really is (POLS). Issues still come up here however, as some
users / developers simply can't adapt so fast, or miss the history and
as such, suffer a massive reduction in POLS (FreeBSD ports to Debian
apt, for example).
We're slowly moving towards a CI *everything* kind of set-up,
carefully chaining update & build jobs for not just internal software,
but our external dependencies too. Early warnings really really help
to reduce the time impact of new versions, build script alterations,
and so on. You also get 'documentation for free' if you do this job
well. :-)