Programming: Into a Language and Outside of the Box
If you have ever read Code Complete, you have heard of programming into a language. I think it’s one of the most important points that Steve McConnell raises. In the book, McConnell says that
Programmers who program “into” a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.
Alternatively, he states that
Programmers who program “in” a language limit their thoughts to constructs that the language directly supports. If the language tools are primitive, the programmer’s thoughts will also be primitive.
McConnell advocates for programming into a language, and I agree. By programming outside of a language, you allow yourself to develop your best solution, and then figure out how to make it happen in your language of choice. Thinking about problems away from the computer always leads to better solutions, and this article will explain how I approach programming into a language and how you might be able to start.
Outside the Box
Some argue against the programming-into-a-language theory. They argue that language idioms and other language specific features will get in the way. In 2008, Jon Skeet made the claim that programming styles make programming into a language suboptimal, illustrated by Java written in a C++ style.
It’s a valid point, but I think of this concept a little differently. For me, it has less to do with style and more to do with tools. Without the constraints of a programming language telling you what you can and can’t do, you will generate a better design. Thinking less about the tools you have available to you, and more about the best solution, allows your creative juices to flow. Programming is an extremely creative endeavor; some even say programming is art.
Technique for Programming into a Language
All programming starts with a problem. The typical flow might go something like this:
Problem definition. — Think about what we are trying to solve. Ask a bunch of questions. When you think you have found the core problem, ask more questions. Really get to the root of the issue. It’s easy to stop at the surface. It’s easy to think you have found the issue that needs to be solved, only to find out you didn’t dig deep enough. The five whys are key here.
Design the solution. — Once I’ve really found the root cause of my problem, I can start to design a solution. Grab a piece of paper and start connecting lines and objects. I work primarily with OOP, so I always have classes and objects. But these are just representations of data. It could be anything. I don’t know a lot about functional programming, but I’m confident this technique could translate.
I ask myself questions like What could go wrong? What haven’t I accounted for? Will there be performance issues? This is the stage where I draw a lot of lines. Sometimes I draw sequence diagrams or flowcharts. I know — crazy, right?
I continue this process until I think I have a good solution. I would be doing Code Complete a disservice if I didn’t mention the Pseudocode Programming Process. I am a fan, and use it semi-regularly. This is where the programming-into-a-language concept starts to show up. As I dive deeper and deeper into pseudocode, I start to look for ways to make what I want to happen, happen in the language I have chosen. At the end of this process, I almost have a working solution. I’m really close to code.
Program the solution. — By now, I’ve thought about the problem, thought some more about the problem, designed something worthy, started writing pseudocode, and I’m ready to either write some tests or just start applying the structure that I want.
Given that most languages are just syntax on top of the same data structures and controls, I can simply look for what I need in the language’s standard library or plugins/modules, or write my own.
Which brings me to another point. Look for existing solutions. If you find one that fits and you have evaluated it, use it. Evaluating dependencies is another topic entirely. The key is not to be tied down to a language’s tools.
If you can’t find a something in the language or framework, you need to back up and make sure the design uses something that is available.
Embracing Constraints
But what about embracing constraints? Surely that can be a good thing. That’s true. Sometimes it can. Maybe you’re limited in what can be implemented. Maybe as a time constraint, you have to stick with a framework or language.
The same process is applicable. What changes is the design step. If you can’t find something in the language or framework, you need to back up and make sure the design uses something that is available.
There isn’t one right way to develop a solution, but I find programming into a language to be superior. I feel like it gives me the freedom to embrace creativity, approach my craft as an art form, and develop the best solution I can.
Co-written by: Caroline Jobe
