Why Linguistic Abstraction is a Winning Strategy

I want to highlight a couple of things that Bob Warfield has pointed out in a recent blog entry on the “small vs large” team size debate. My very small experiences observing and participating in development projects in the thick of the small and medium sized business environment have lead me to suspect these things, but it’s always good to hear someone that can articulate this stuff concisely:

“There are two ways to think about this. Chris takes the path that says the example is irrelevant because most software isn’t that way. I take the path of saying that the example is spot on because all software should become a language if done right. The benefit? Your small team is enormously more productive as are your customers if you can actually make the language something they can grasp and use. There is a reason these small teams built languages (though I’m not sure I view Linus as a tool/language). In fact, Quattro Pro had no less than 18 interpreters buried in the guts. Very few of them were surfaced for end users, most were there to make the code simpler and the product more powerful.”

So if you’re building something complex that has to meet a lot of different people’s needs (and whose needs are constantly changing) then you need to see through the cloud of conflicting requirements to the generic tools that would enable solutions to actually emerge. And the most powerful tools are actually going to be languages.

“Don’t kid yourself that a giant team running around gathering requirements and hacking out use cases in monolithic modules is building software, business or otherwise. It’s creating an unmaintainable mess that makes nobody but the IT guys that assembled that laundry list happy. Certainly the business users who it lands on are going to find it isn’t what they thought they were getting and it is almost impossible to change it into what they wanted.”

If we solve today’s problem, we’re hosed. Today’s problem isn’t the real problem… it’s just one iteration of it. So we shouldn’t give into the temptation to “hard code” stuff for the check-list people just to please them in the short term. The requirements and use cases of today have to be expressed in terms of our tools and linguistic abstractions: we need to invest efforts in expanding their scope and expressiveness.

5 Responses to “Why Linguistic Abstraction is a Winning Strategy”

  1. Daniel Bernier Says:

    By the way, I really enjoy reading another average programmer’s notes as he learns the hard stuff. I’ve been reading SICP, The Little Schemer, PCL, and On Lisp on-and-off for about a year. The tough part for me is finding other programmers who’ve moved far enough up the programming language power continuum to get it, finding people aware of the Blub paradox. Good luck, and keep going…

  2. Daniel Bernier Says:

    It doesn’t even have to be a language that you create; there are other ways for an end-user to control and configure the software you make for them. Just look at Excel…with just numbers, formulae, sorting, and formatting, you get all this functionality. It affords a whole slew of uses.

    The essence of it is to find the primitive elements the user wants to manipulate, and let them do it.

  3. John Says:

    Daniel, Excel is essentially a data flow language (making it functional as well).

  4. Daniel Bernier Says:

    That goes to show that functional programming isn’t necessarily harder than imperative programming. =)

    Although my point is that if you make a great tool that lets people do something, it’s useful not because it’s a DSL, or drag-n-drop, or an API…it’s useful because you captured whatever concepts the user has in his head when he thinks about the task he uses the software for.

    That’s -why- DSLs are so useful, but I think the principle applies to whatever tool you’re building, whether it’s meant for programmers or end-users. You can even look at your own code this way: write low-level code that lets you manipulate the primitive concepts you’re concerned with, and then your high-level code will be clearer. When requirements change, your code should change minimally, because it’s not the primitive elements of the problem that changed, it’s the way they’re combined.

  5. lispy Says:

    Well said.

    It doesn’t take much to make a linuistic abstraction. Just supply some primitives and create a means of combining them and of naming (and referencing) the combinations. That’s it.

    In the case of a spreadsheet, your primitives are cells. All cells have names… and ranges of cells can be referenced as well. And of course, the expressions in the cells constitute a language in and of itself! The problem is that they don’t encourage their users to continue applying such principles at their level. They make quick-and-dirty “hard-coded” solutions that don’t evolve well or play well with other spreadsheet solutions.

    Having to juggle dozens of spreadsheets for a current project, I find myself wishing for linguistic techniques to access, manipulate, and link them. Spreadsheets violate the closure property– and the fact that the expression language, the implementation language, and the automation language are all different makes for even more problems! (If only all three were built On Lisp….) 😉

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: