You say Python, and I say Perl …

Last week, I shared my reluctance to blindly accept the abstractions found in languages and frameworks like Ruby on Rails. This sparked quite a bit of discussion on and offline, as well as more than a few notes from angry developers. There were lots of pish-tosh-type comments, such as, well then, why I didn’t write my own operating system? Or that using curl was somehow the same as using Capistrano to automate deployments.

Let’s unbunch our collective Huggies and take another look at this, shall we?

[ Fatal abstraction: A bottom-up view of high-level languages | Work smarter, not harder — download the Developers’ Survival Guide from InfoWorld for all the tips and trends programmers need to know. | Keep up with the latest developer news with InfoWorld’s Developer World newsletter. ]

First off, let’s set a baseline. If you choose to be so obtuse as to compare my mistrust of high-level development frameworks with the use of a command-line database client, we’re probably done here. There’s no real discussion to be had with that mindset.

I’m clearly not talking about reinventing every wheel, writing my own database, or any such nonsense. I’m talking about languages and frameworks that completely obfuscate what’s actually happening below the surface. Their ideal is to hide all the machinery and present a slick, glossy interface to working with those elements. If you look at it one way, you can definitely write database-driven apps without ever really looking at or touching the actual database.

In theory, this might seem really neat. I mean, it does make things easier and sleeker. If I need to perform certain low-level functions, I just look up how the developers of the framework accounted for those low-level functions, then I use their interface — easy-peasy.

But when there’s nothing in the framework that does what I need it to do, I’m suddenly abandoned. My carefully constructed sleek interface now needs some ugly real-world code bolted onto it to make it work right. That particular wart is likely to join several others during the course of the development, and I will end up with a hodgepodge of code, which was ostensibly the very thing that framework was trying to prevent.

This isn’t necessarily anyone’s fault. Nobody can predict the requirements of a given development project with 100 percent accuracy. That’s sort of the whole point of languages like C and Perl. They can be used to do just about anything because they offer tools, not interfaces. You can build anything you want with a fully stocked toolbox, but you’ll have a hard time making a bookcase if your only tools are a screwdriver and an awl.

That might be a bit of an oversimplification, but it’s definitely true. There have been and will be many times when small problems become huge due to the failings of the framework. As reader Ramon S. put it last week: “How many times did I hear from developers, ‘We cannot do this because the framework does not support it.’ Seriously?”

When I start a project and choose my language, I do so with some knowledge of what I’m getting myself into. I realize that my choice of one language will present challenges that I might not have to face if I chose another, but I also know that I am much less likely to paint myself into a corner. That freedom and flexibility may be more important than the time required to slug through code that another choice may have handled in a simpler way. This is why different languages and development frameworks exist. If a solution existed that provided the best of all worlds, we’d all be using that, wouldn’t we? (This is the part where the Python devs raise their hands anxiously.)

That’s where we should finally realize that all of these things can coexist together. I can choose my language, and you can choose yours. My choice is likely to be different depending on the task at hand and — here’s the important part — so should yours. We should be able to look at the various languages and frameworks available to us, look at what we’re setting out to build, and arrive at a clear choice. We shouldn’t all wield hammers, and we shouldn’t see everything as a nail.

There are a boatload of projects that are absolutely perfect for Ruby, and tons that are great for Rails. There are myriad places where you could write something in Perl or Python. You could use Python or PHP for untold numbers of other projects. By the same token, you could use PostgreSQL here and MariaDB there. Heck, you could also leverage NoSQL databases in many places. We have a wide range of choices, all of them open source, that can provide whatever we need. We just need to be cognizant of the rules those choices bind us to when we make them.

I firmly believe that development is best if the developer is not glued to one language or the other. The multilingual developer has a much better chance of simultaneously producing a solid application and retaining their sanity than the developer who is convinced that their chosen language is the only way to fly.

And so, as with so very many things in IT and software development, YMMV. That’s the way it should be.

This story, “You say Python, and I say Perl …,” was originally published at InfoWorld.com. Read more of Paul Venezia’s The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.