(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Sunday, November 25, 2007
Can expressive languages make code more accessible to the masses?
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?
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.
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?
Comments on “Can expressive languages make code more accessible to the masses?”:
<< Home
This is a very interesting read for me. I dugg it:
http://digg.com/programming/Can_expressive_languages_make_code_more_accessible_to_the_masses/blog
And stumbled it ;)
http://digg.com/programming/Can_expressive_languages_make_code_more_accessible_to_the_masses/blog
And stumbled it ;)
I don't consider myself an all-or-nothing dynamic languages weenie, although at times I've found myself (regrettably) acting like one when provoked. Jones's tone on this issue is that of the enterprisey crowd rather than the academic theorist crowd -- he may be mostly wrong, but at least he's civil. This community, at least, we may be able to reason with, and to do so would be more fruitful. In the end, what I think we'd like to see in industry isn't necessarily dynamic languages, just better languages.
Excellent post, but I'm thinking of what the enterprisey type people would love to hear. To me, dynamic languages like Python have a few major advantages over static languages: developer time.
Dynamic languages save developer time on two fronts, one you hit on already. The first is actual development of the code, and the second is maintaining the code.
When it takes one line in python to do what it would take 100 lines in C, 120 lines in C++, and 75 lines in Java... you see a huge benefit.
Granted, not every line of python is that expressive, but over the course of an entire development project, the total savings are half the time or more than it would take in Java.
Thats huge. Then there is maintainability like you mentioned. When it takes less time for a maintainer to grok the purpose of the code, thats more time they can spend on actually fixing the code.
Together that grants a huge benefit, which can be expressed to the PHB's.
Dynamic languages save developer time on two fronts, one you hit on already. The first is actual development of the code, and the second is maintaining the code.
When it takes one line in python to do what it would take 100 lines in C, 120 lines in C++, and 75 lines in Java... you see a huge benefit.
Granted, not every line of python is that expressive, but over the course of an entire development project, the total savings are half the time or more than it would take in Java.
Thats huge. Then there is maintainability like you mentioned. When it takes less time for a maintainer to grok the purpose of the code, thats more time they can spend on actually fixing the code.
Together that grants a huge benefit, which can be expressed to the PHB's.
True story: before I learned Ocaml, I read some academic papers that, in describing their algorithms and data structures, used what looked to me like a beautiful pseudo-code- concise, elegant, clear (once you understood the notation), and short. It expressed just the "core thoughts", leaving all the extraneous details out. It was only later, after I had learned Ocaml (and a smattering of SML and Haskell), and went back and reread those papers, that I recognized that's not pseudo-code, that's code.
So I can definitely understand the thrill that comes from realizing that most of the crap you've had to deal with for years as a programmer you don't have to deal with anymore. But I'd like to offer a theory I have, on why I think "bad" languages (like Java and C++, and Cobol and Fortran) survive and even thrive in business for years or decades after better languages come along, and even become popular.
You need to have an attraction to and interest in complexity, I beleive, to stick with learning to program long enough to be any good at it at all. While the money is good, it's not that good, especially compared to the other careers reasonably bright people can apply themselves to, such as managers or doctors or lawyers or investment bankers (trust me, a lot of investment types working on Wall Street aren't that bright). We're problem solvers at heart.
Unfortunately, much of programming, especially in the "enterprisey" realm, isn't all that interesting of a problem domain. Fire this query off to the database, make the button cornflower blue, that sort of stuff. Trivial problems, in some sense- but it's hard to be proud of trivial work. Not to mention it being hard to cost-justify your job.
I think part of the attraction these "unnecessarily complicated" languages have is just that- unnecessary complexity. Adding complexity and challenge to a task that ordinarily is nothing but boilerplate.
So I can definitely understand the thrill that comes from realizing that most of the crap you've had to deal with for years as a programmer you don't have to deal with anymore. But I'd like to offer a theory I have, on why I think "bad" languages (like Java and C++, and Cobol and Fortran) survive and even thrive in business for years or decades after better languages come along, and even become popular.
You need to have an attraction to and interest in complexity, I beleive, to stick with learning to program long enough to be any good at it at all. While the money is good, it's not that good, especially compared to the other careers reasonably bright people can apply themselves to, such as managers or doctors or lawyers or investment bankers (trust me, a lot of investment types working on Wall Street aren't that bright). We're problem solvers at heart.
Unfortunately, much of programming, especially in the "enterprisey" realm, isn't all that interesting of a problem domain. Fire this query off to the database, make the button cornflower blue, that sort of stuff. Trivial problems, in some sense- but it's hard to be proud of trivial work. Not to mention it being hard to cost-justify your job.
I think part of the attraction these "unnecessarily complicated" languages have is just that- unnecessary complexity. Adding complexity and challenge to a task that ordinarily is nothing but boilerplate.
bhurt,
Not to be argumentative, but I somewhat disagree about your point as to why persons choose these "popular" languages.
I actually believe that for many, that resistance to learning a supposedly 'dynamic' language comes from a simple fear of the unknown. Imagine spending some years in school (or somewhere else), learning how to write effective Java, for example. You go through growing pains, making many of the common learning mistakes, and putting a lot of time and effort into becoming somewhat proficient at that language. Subconsciously, you will always remember the pain that you went through to reach the skill level that you currently are at. You remember all the gotcha's in the Java language that you had to overcome... design patterns that you had to learn to avoid certain problems, etc.
From my observation though, what most people who preach against dynamic languages don't seem to realise is that dynamic languages are NOT like 'languages without type declarations'. Ruby is not Java without int declarations. Python is not C# without the necessity of String s = "string".
People who complain that dynamic languages are dangerous have not actually fully used them. I'm not talking about some little snippet of code, or a small inconsequential pet project. I fully believe that a major part of the problem those persons have with dynamic languages is misunderstanding exactly what such languages bring to the table.
As raganwald said, it's about abstraction - some dynamic languages can create greater abstractions, at the 'cost' of type declarations.
Of course, having spent so much time and effort learning to avoid Java's pitfalls, it's hard to see beyond the fact that many design patterns and Java coding techniques are simply not necessary in Python or Ruby - those coding techniques and patterns avoid problems that do not exist in the dynamic language space.
Not to be argumentative, but I somewhat disagree about your point as to why persons choose these "popular" languages.
I actually believe that for many, that resistance to learning a supposedly 'dynamic' language comes from a simple fear of the unknown. Imagine spending some years in school (or somewhere else), learning how to write effective Java, for example. You go through growing pains, making many of the common learning mistakes, and putting a lot of time and effort into becoming somewhat proficient at that language. Subconsciously, you will always remember the pain that you went through to reach the skill level that you currently are at. You remember all the gotcha's in the Java language that you had to overcome... design patterns that you had to learn to avoid certain problems, etc.
From my observation though, what most people who preach against dynamic languages don't seem to realise is that dynamic languages are NOT like 'languages without type declarations'. Ruby is not Java without int declarations. Python is not C# without the necessity of String s = "string".
People who complain that dynamic languages are dangerous have not actually fully used them. I'm not talking about some little snippet of code, or a small inconsequential pet project. I fully believe that a major part of the problem those persons have with dynamic languages is misunderstanding exactly what such languages bring to the table.
As raganwald said, it's about abstraction - some dynamic languages can create greater abstractions, at the 'cost' of type declarations.
Of course, having spent so much time and effort learning to avoid Java's pitfalls, it's hard to see beyond the fact that many design patterns and Java coding techniques are simply not necessary in Python or Ruby - those coding techniques and patterns avoid problems that do not exist in the dynamic language space.
<< Home
