Can expressive languages make code more accessible to the masses?
IT is no-longer a hackers paradise populated only by people with a background in Computer Science, it is a discipline for the masses and as such the IT technologies and standards that we adopt should recognise that stopping the majority doing something stupid is the goal.
An interesting read. The characterization of “dynamic languages == hackers doing programming as art” does not match my experience talking to people who use dynamic languages in commercial projects, so I’ll respond to that one point.
This quote shouldn’t be taken as the entire premise of his post: please read the whole thing and decide for yourself what he is and isn’t saying. And my response here isn’t really an argument with Mr. Jones, it’s more of a riff inspired by it. I’m going to talk about different ways to achieve a similar goal. Perhaps that is disagreement. Or perhaps it is violent agreement
.doing no wrong
One of the many things people do with languages like Python and Ruby is try to solve the exact problem he mentions, stopping someone from accidentally doing something wrong
. Obviously, not with static typing. So how else can this be done?
Let’s start with Python. What, do you suppose, is with the enforced indentation. Do you think it might have something to do with standardizing code style to make it readable? Which in turn lowers the bar for someone to come in and understand code and therefore fix it more easily and without accidentally breaking everything? Although this has nothing to do with Python’s “dynamic” nature, it has everything to do with the language’s design goals.
Sick of the false dichotomy of arguing strong, static typing vs. powerful, expressive languages? The Little MLer introduces ML (and its object-oriented variant Ocaml) through a series of entertaining and straightforward exercises working with lists, structures, and even deriving arithmetic from types.
ML and Ocaml provide pattern matching, higher-order functions, and a strong, static type system so expressive that it actually changes the way you think about programming with types. Yet it does so with type inference, so you get the brevity of languages like Ruby and Python.
And I am very sorry that type inference is not a common feature in “popular” statically typed languages. One of the reasons people like dynamic languages is making the boilerplate go away. And agreed, the baby goes out with the bathwater. But it’s more than just saving yourself typing, especially for someone like myself who spends more time thinking about what I’m going to write than typing it. Even if it takes me twice as long to type my code, I don’t become half as productive, not by a long shot.
The point is also readability, and readability directly drives application support. Code that is easier to read in the aggregate is easier to maintain. And dynamic languages can be used to make code very easy to read.
Put in this light, the “dynamic” nature of certain languages is not the goal, but rather a means to an end, or even an unhappy side-effect of the goal, which is making code more expressive
and therefore readable.
For example Regular Expressions could be considered an artful way to play “golf,” to reduce code from pages of loops to perform searches down to a few characters with some cryptic special features—[^a-z]* and so forth—but they could also be seen as a way to reduce errors by abstracting something that is error-prone and difficult for “the majority” to get right the first time, much less maintain when someone else has re-invented the text search wheel in their own idiosyncratic way.
Likewise, Ruby on Rails—which is a framework and includes several DSLs—could be DHH futzing about writing poetry in Ruby. Or it could be a way of stopping the majority from doing stupid things like getting relational databases wrong. reducing relations to conventional table and columns names plus readable “declarations” like “has_many :ideas” also serves to make it easier for the non-expert to write and maintain code.
This is not to say that bondage and discipline doesn’t have its place. Or that you can’t achieve all of the same goals with Java and
stop someone from accidentally calling .to_s on an object which actually responds to .toString. But I am definitely saying that writing code for others to maintain is both a laudable goal and one of the things that the current crop of dynamic languages can do well.
In the end, my suggestion to everyone is simply this: Programming is Art—to a programmer who is also an artist. And Programming is Engineering—to a programmer who is also an engineer. And finally, Programming is “A Means to Organize and Mold the Work of The Majority”—to a programmer who seeks to organize and mold the work of the majority.
In the hands of a programmer seeking these goals, each language has its own advantages and disadvantages, no doubt. And I will not argue with suggestions that a language with veryLongCamelCaseConventions using WidgetTemplateFactoryMethodFactoryFacadeFactoryVisitors is the preferred choice for certain projects in certain environments.
But I am pointing out that if you begin with the same ends in mind, such as writing code to be maintained by others, you can use radically different tools in radically different ways, yet wind up reaching the same objective.
p.s. A good read from Steve Jones: What is it with vendors’ view on time?