A Programmer's Isogloss

One of my coworkers has a degree in linguistics and this idea comes from talking with her about language and isolation. Call it my you should really go to that conference rant if you like. The topic of conversation give me a stark realization that I think anyone that is responsible for the care an feeding of programmers should be cautious of.

Naturally, computer programmers use programming languages and the more complex the language and free form it is the more likely it is to have dialect, idiom, and isogloss just like natural languages.

In particular if a speaker or group of speakers live in isolation long enough they will develop their own little quirky habits. These quirks start off as innocent inside jokes which include conventions that we recognize in API. Given time the isolated group can start to invent new idioms which approach an unintelligible complexity to an outsider. The divisions between various frameworks that share Java as a base language and their definitions of terms is a good example.

So how do you break this cycle of main languages fragmenting and breaking up into new languages? You go out and regularly talk to others about your code, your architecture, and you get a feel for how others say words or convey meanings. You make your community of language larger. Every company needs to get its programmers out there and talking to other developers. One of the best ways is through conferences.

The benefits will be that your corporate architecture will stay closer to the wider world's interpretation of the language and idioms you use (think: style, practice, and API). Your developer's will be more creative and valuable as they benefit from the exchange of ideas. And you will know that you have a pool of similarly talented consultants and developers to seek out when you need them.

Other good ways to let your programmers get out there and learn more is to encourage the use of social networking in responsible and applicable ways. I used this recently to help think about const versus final in our code base.

Another idea I've been toying with is to have at least one small company backed Open Source project that your people are encouraged to contribute to that you can also use for getting outside feedback and perhaps to recruit new people into your company from. This is a novel idea but I think with some sensible boundaries it can pay off even for closed source companies.

Those are just some of my thoughts on the topic. But essentially you want to avoid putting your programmers in the position that all they ever do is "talk" (via programming) to the computer and themselves. You need to talk with other people whether in code or English to keep your skills sharp and to avoid drifting off into your own strange dialect. The dangers to both the company and the employee of drifting off into your own little world are profound. It can mean obsolescence for both parties and that doesn't help anyone ... except maybe your competitors.

It is all UI even API

It is all UI and UI leads us down certain paths.

This is an idea I've had for a long time but it hasn't been posted here before so let me lay down for you the why behind the tag line of this blog: "The power of software is the power of thoughts and ideas."

These are important concepts: The purpose of the UI is to aid the user in thinking about what they are doing inside their machine. The UI should match what they are thinking about as closely as possible.

This is all well and good for users. It gives them pretty looking sites that are easy to use and understand. It leads to ideas about making user customization of content a certain flavor of easy that involves allowing for graphical interaction with the system.

But, the programming language is UI too.

I have recently graduated into a tier of programmers that write programs for other programmers to use. But, I have always known that unless you are building the system from nothing then you are the user of another person's UI. It may be called an API but it is still UI.

Programming languages are UI too, they are UI with a limited audience, developers. Just as EE folks design CPU with a "programmer's model" in mind so too should library developers develop software with application developers in mind.

The best way to do this is through "dog-fooding" which is to say that a developer should be forced to eat their own dog-food. When you develop something you should have to use it. If you can't use it you can't really make well informed decisions about how that product should work.

As a developer I try to get inside the minds of the people who use my products. I try to anticipate what they will do, how they will do it, and what ways they may want to do things differently. I can operate this way because after nearly two decades of working with computers in one fashion or another I am convinced there is no right or wrong intrinsic in the machines themselves.

Any meaning, purpose, or sense of working or brokenness is determined by the user. To make a system that is bug free you have to know the user. The technology therefore must be designed from the user back to the machine.

The problem is compounded by the fact that there are multiple types of users. You can build classifications for each of them profiling what their expectations are and building their view of the system around that. Working for one user is broken for another. To design a truly beautiful system you need to account for as many of your user classes as possible.

Often what system designers and developers leave out of their design consideration is themselves. Developers are users too. The must live with their own design choices over time and are prone to the same flaws that other user classifications are prone to as well.

The reasons technologies succeed and fail are tied up in the intersections of actual functionality and perceived function and value. These are emotional decisions as much as logical ones. Very technically speaking any Turing complete language is capable of any task that any other Turing complete language can do.

So the power we find in expressive software is actually the ability to cleanly express some thought or idea. We are attempting to communicate both to the machine and the user some expression of action, computation, art, or logic that will achieve the goal of the user. The software is most effective when the developer and the user understand each other through the lens of the software.

This is true for your web application, mobile application, programming language, or your developer API.

The web framework developer is working for their user which is the web application developer. The persistence layer developer is working for their user which is both the framework developer and the application developer. The application developer is working for the end users of their system.

The most effective developers will be the ones that realize this and deliberately cross as many disciplines as appropriate for their application space. This kind of renaissance developer will be most effective at knowing how what they will write will be received. This kind of developer will know implicitly that it is all about user interface and developers are users too.

Just as architects have known for generations that a building must be beautiful both on the outside and the inside yet still respect the laws of nature so too must computing grow up. So in my phrase "the power of software is the power of thoughts and ideas" is nestled the concept that not only power but beauty and value of software is the beauty and value of thoughts and ideas.

The metrics of our beauty in software is the cognitive dissonance we create in attempting to enable our users to create their art with our tools. When you create software you are implicitly directing the thoughts of another person or machine. Just as an Orwellian language could forbade certain thoughts your API could forbid a design or direct users down a path. The challenge is to match your design to the users' thoughts and direct them toward good solutions without imposing a mental fascism.

The converse is side of this is that you want to direct your users toward maintainable and workable designs. The goal should be to guide not to force. So working out an good design is a balancing act.

Just some thoughts that I've had while looking at possible improvements to an existing development framework.

Edit: Oh yes, I saw this shiny "follow" gadget and added it to the upper right hand corner. Won't you do me a favor and click it a few dozen times so I don't feel too bad about having "0" followers. Thanks.

Programming Language as Human Computer Interface

Programming Languages are in fact Human Computer Interfaces and should be treated as such. The design of a DSL should match the thought patterns of the domain experts in a way that creates as little cognitive dissonance as possible. The result should be that a DSL can become a systems interface point between domain experts, programmers, and systems of systems themselves. We are already seeing this. We will continue to see this. The at the very tip of this idea are the DSL which Java and Groovy make so simple to build.

Programming is a human activity that occurs on multiple levels of thought. Thought tools assist in thinking. We call these metaphor. Why shouldn't programming language tools also help assist programming. The framework level language should therefore be used to create as thoughtful and targeted a set of metaphors for the application level programmer... who in turn is creating tools for the problem-domain experts to use.

Language is a Cognitive Technology

Making the rounds is a story out of the MIT news office about the Piraha tribe whose language does not include any counting numbers. They do have the concepts of more than and greater than and the concepts of few and many. Counting isn't a useful skill for them.

What is most intriguing to me is not the missing counting concepts but this odd quote from the end of the article:

One other discovery of the project is that the Piraha can perform exact matching tasks as long as there is no memory component to them, but once there is a memory component, they approximate their matches. This suggests that language is a cognitive technology that aids humans in memory tasks.

That is an interesting phrase to me: language is a cognitive technology.

Programming languages represent cognitive tools to work with a computer. That is definitely true. If you can consider language itself a technology of the mind or a cognitive tool that is an intriguing idea. Is your ability to only use one language or one programming language akin to only being able to use a screw driver?

If we can consider language itself a technology then we have an interesting new time-line for the progress of technology. We can go back to prehistory tracing the advent of the basic concepts of mathematics building up to today's computers which ostensibly hold the fruit of tens of thousands of years of cognitive technological effort.

And this begs me to question... what if we had started on the wrong path all those millenia ago. What if there are better cognitive platforms to build our systems of thought on top of but we couldn't explore them because our tools of cognition effectively created a platform of thought that prevented us exploring other methods of thinking. There could be ways of thinking and computing we can't even look directly at because they are so alien to us.

This idea cuts both ways. It tells me that if a paradigm is too far removed from mainstream thought it could die because not enough minds can (or will) adopt it. That means there are undoubtedly modern linguistic paradigms that are limiting but also unavoidably entrenched. This is good and bad. One language helps people to be mobile even as it limits them.

Consider how English is changing as speakers in many countries begin to change English to match the paradigms of the local tongues it mingles with. The resultant language may become a world tongue called Panglish in some breathless articles. It's all speculation right now.

But, we see this all the time in Programming languages. We see programmers transplanted from one language into another that bring with them the idioms of the languages they left behind. When this becomes laughable is when what is changing is far more than syntax but entire ways of thinking through problems that are being butchered by forcing the new language to work like the old one.

Here is a counter intuitive idea, but, some limitations are actually liberating. When children play in an open field they will cluster together. If you fence in an area larger than what they are actually occupying they will spread out to fill the space. The same is true about how you think about things.

Too broad a programming framework means that you can't effectively address any specific problem. It means you have too wide open a field. Instead the more a framework leads you to an answer the faster you will move toward a goal. Too efficient and limiting of a framework and you can't steer toward an appropriate design and must instead work around your framework.

Think of it as a volume of space where each point represents a system design. Your framework is like a channel or road driving you toward a region of all the possible system designs you can imagine. There is a volume inside that huge space of all possible systems that contains designs that fulfill your requirements (stated and otherwise) and your framework drives you in the direction of a handful of these. If your framework is too strict there could be a problem where the volume of answers lie in one direction and your framework drives you in another.

That would be an impedance mismatch between the problem and the framework. You would need to modify the problem or the framework to bring them into concert. Or you would have to abandon your framework entirely.

Most of us today are working in a world where our frameworks are pulling us toward solutions that are wholly web-based. That is just a fact of what is in fashion today. It isn't wrong either. The web will finally disassociate the cognitive and the physical. Just as MP3 is slowly killing the CD so too will the web slowly kill off certain legacy computing paradigms.

What do the Piraha know and can think about that we can't? Perhaps they have some insights of genius that are not evident to us who are encumbered with numbered thoughts? I wonder how many of us are like the Piraha happy in our own world but are fast colliding with a world that is driven by new thoughts and ideas utterly alien to us. As alien as numbers are to the Piraha the concepts behind cloud computing and massively parallel computing systems are headed our way. What will the programming languages that help us get there look like? How far off course have we drifted along in the channels of thought carved by our programming infrastructure?

It's just a thought.

Seven Sins of Bad Groovy Programming

Jörg Staudemeyer has posted on the groovy-user forum at nabble a list of seven sins committed in groovy and why they are bad. A good read for anyone new to groovy.

Deep Structure

Deep Structure is a term from linguistics. Specifically Chomsky and his work with Universal Grammar. The term when used in computer science usually refers to meta-design-patterns or deeper computational constructs than those typically generalized by a pattern.

Programming language frameworks supposedly give us implementations of design patterns which are themselves expressions of deep structure computational models. Some people argue that the programming language should obviate design patterns... I don't agree.

A programming language should allow for the creation of design patterns organized into frame works that can be plumbed by specific implementations. The better job your design pattern implementations do of sticking near deeper structures the better you do to create an useful framework. The framework might even be better programmed in a different language.

By population...

I just happened to run across this statistic that makes me wonder what kinds of effects the additional one billion computers expected in the next five years will have if they are mostly owned by Asian users. Programming languages today are structured around western languages. In particular English. If you are not a native English speaker I wouldn't be surprised if some of the prevalent programming constructs aren't alien because they are tailored to an English speaking mind.

helper helpers

While trying to solve a problem in code you go about finding the generic, abstract, or reusable and refactoring it out into units that can be adapted to a number of similar tasks using configuration or minimal programming. In a language like Java this is usually about finding parent classes and helper methods... or even aspects.

For example, you pull out a private helper method out of a public method. The private helper takes three parameters while the public method only takes two. Now you can create new public method that only has two parameters and uses the private helper with a different third parameter. The benefit is that your second method only took one line of code and you saved yourself from cut and paste hell.

When does this stop?

When it's appropriate to stop. At some point the helper helper helper pushes the code's function so far down that you can't tell what the public method is supposed to do... or you end up with hundreds of one parameter methods that call two parameter methods that call three parameter methods. At this point abstraction stops helping and starts hurting the cause. Too much abstraction simply becomes obfuscation.