Ron Hitchens's Blog

The End of the Beginning?

I love Java. I love writing Java code. I've even written a Java book. I've used zillions of programming languages and Java is the one I like the best. But there's a question that's been nagging at me lately: Does Java, or any programming language, really matter any more?

Having been in the computer business for a very long time - the first computer I ever worked with used punched cards and was as big as my first apartment - I've seen a lot of changes in the nature and public perception of computing. And I can't shake this feeling that we're in the midst of a profound, evolutionary change.

In his now famous article IT Doesn't Matter, Nicholas G. Carr makes the argument that the IT industry is maturing and has become effectively irrelevant to a company's competitive strategy. In and of itself, Information Technology no longer has any intrinsic competitive advantage. It's simply one of the essential ingredients needed to run a modern corporation - like electricity, telephones and foosball tables.

But my nagging feeling is not so much about business trends as it is about similar evolutionary forces acting on the technology of software itself. Carr refers to earlier technologies that have transformed industry (steam engine, railroad, telephone, etc). Throughout their lifecycles, each has initially transformed - or disrupted - their environment and then themselves been transformed because of the changes they brought about.

I believe software development is entering such a mid-life, transformative stage - it's changing because of the changes it's caused in business and society.

Computers are no longer exotic, science-fictional wonders, they're a part of our everyday lives. And, as the off-shoring trend of recent years has made excruciatingly clear, programming is no longer a rarefied skill exclusive to a gifted few. To a large extent it's become a routine trade that almost anyone - anywhere - can perform. A commodity.

But the shifting economics of earning a living as a programmer is not what I'm talking about either. That's a political and sociological discussion. The thing that's nagging at me has to do with the programming itself. The way we as humans communicate what we want a computer (or a system of computers) to do.

Software has historically been inextricably linked to computer hardware design. Assembler languages gave us a one-to-one translation of mnemonic symbols to the numeric codes that a CPU understands. Higher level languages brought a more semantically rich set of symbols, and a more complex compiler to do the translation, but we're still essentially expressing ourselves in terms a CPU can understand.

Object technology helps us conceptualize things a little better. We don't feel so constrained to the lock-step, linear instruction execution model. But when you look inside an object method, it's still made up of those fine-grained marching orders for a CPU. We still seem to be tied to the paradigm of writing text that's translated to the CPU's native language.

I've been wondering lately if this notion, abstracted though it may be, of people writing text that's then translated into opcodes isn't something we've outgrown. It's the 21st Century but the way we as programmers communicate instructions to computers hasn't changed fundamentally since Grace Hopper started doing it nearly 60 years ago.

I saw a demo at SD West 2003 of the work Intentional Software is doing and have read a little about the Ace and Jackpot projects at Sun, all of which are exploring alternate ways of representing code. But I've actually been intrigued by this concept since I decided to switch to IntelliJ/IDEA as my Java development environment.

IntelliJ was the first IDE I used that was designed around the concept of language understanding rather than text editing (it may not have been the first, it doesn't matter, it was the first one I encountered). IntelliJ is such a great tool to use because it understands the Java language. It instantly checks code as you type it both syntactically (is it well-formed) and semantically (does this make sense in the context in which you're using it). It's the latter that's really valuable - manipulating text is not what I care about, it's getting the code right that matters.

Once I got up to speed with IntelliJ, I noticed a subtle but profound shift in my thought process. I began to think of coding less as a text editing activity and more as an object crafting activity. Because the tool understood the language I could trust it to do the mundane editing tasks while I concentrated on the higher-level meaning of the code. This has far-reaching implications.

Rather than thinking of the code as lines of text, I now conceptualize it as chunks of functionality that can be split, combined or reshaped as needed. The chore of making changes to the text files is handled by the tool. I'm able to devote my concentration to the more important aspects of programming: responsibilities, relationships, cohesion, coupling, patterns, and all the other stuff that makes for well engineered software. And when I see that something needs to be changed I don't hesitate because the tool can make the change easily - even if that change may affect a hundred source files. This makes for better code and it makes me a better coder.

Tools like this use a sophisticated internal model to represent the code. Where there's a model, there's usually a view of that model. And if there's one view, why can't there be others? When a tool can present your code to you as UML diagrams, color selectors, tables, live GUI widgets or whatever, the textual view we're all so familiar with starts to feel rather constraining.

So this begs the question: If tools can liberate us from mundane text editing and we code so much better when interacting with a more wholistic model, why do we bother to keep the text file representations at all? In today's world, it certainly seems as though building programs by manually munging text files is one of the least efficient - and most expensive - ways to go about it.

I don't know what the next great innovation in programming will be. It may be here already for all I know. But I do know that the labor-intensive, text-based programming method we've been using for the last half century will wane - it's simply not going to be economically viable much longer.

A friend of mine once pointed out that the majority of business programming is done not in Java, C/C++, Cobol or even Visual Basic, but in Microsoft Excel. I wouldn't consider a spreadsheet a programming language, but it certainly is an effective way for humans to communicate to a computer what they want done.

This, I think, is where the future lies. Finding the most appropriate way to communicate for any given problem domain. The era of humans translating their thoughts into sequential steps for the CPU to execute is ending. Just as high level languages supplanted assembler because they were more expressive and hid more of the details of the execution environment, I believe the next phase will be to move beyond the textual representation of programming logic for most applications.

Of course, conventional programming languages are not going away overnight. I suppose what I'm really talking about here is a new sedimentary layer being laid down atop what's come before. The future is alway built on the foundation of the past. The programming languages of today will beget the next generation of programming tools.

I believe we've reached the end of the beginning of the computer revolution. But we're nowhere near the end. Just as printing technology evolved from letterpress to linotype to offset to laser printer, the nature of programming must also evolve. It's going to be interesting to see which mutations survive in this brave new Darwinian world. In any case, I'll be sad when I finally have to say goodbye to my old friend, Java.

Comments

• don't think so
  The end of programming has been pronounced so many times I think most of us have lost count.

  Last year it was tools that could (according to the marketing hype) translate business rules into working programs.
  The idea was that managers could just enter in (using diagrams like they are used to in Powerpoint etc.) their business processes and a complete program would come out.
  Of course this never worked as advertised. At most a skeleton could be produced requiring a lot of adaptation and coding to make it work. The input also required finetuning by editing scripts by hand if the rules were more than trivial, effectively attempting to make managers into coders.

  And even IF it had worked, someone would still have to write the generators and compilers...

  When Logo (the language) was announced that too was thought to be the end of programming. Soon anyone with a mouse (at the time a novelty) could just point and click a program together and never see a line of code.
  The same was said of Visual Basic and languages like it. The code editor was deemed to be there mainly to do the last few things that would be replaced with more click and drop components in later versions (while in fact the code editor has in all such tools become ever more important).

  We might in the end move away from typing in code to dictating it using voice recognition software that might even be intelligent enough to translate human language into computer code, but someone will still have to write that voice recognition software.
  Even if an AI were to write that, who would write the AI?

  Posted by: jwenting on December 31, 2003 at 01:36 AM

• Or, the beginning of the end
  As I have told Dave (pragmatic) Thomas, I've gotten a lot of millage out of his recomendation to develop small scripting languages to solve business problems. It is amazing that a technique as simple as this can radically change the face of a problem. Instead of having to use some abstract notation, one can revert to the vocabulary of the business. A very useful transformation.

  move the coding problem into the users vocabulary. As you've stated, it shifts the the focus away from manipulatingproblem altogether as it allows one to focus on the problem and not on manipulating the computer.

  Posted by: kcpeppe on December 31, 2003 at 03:46 AM

• don't think so
  Agreed, we hear the "we've coded ourselves out of a job" line at least once a year. As Hitchens is claiming a move away from coding, there is actually a move towards focusing on the code more and more as tools improve. Consider the plethora of refactoring books on the market. These books focus on the task of coding, in an editor.

  Let's look at one final thought presented by Hitchens -
  "The era of humans translating their thoughts into sequential execution steps is ending."

  Try making a peanut butter sandwich without translating your thoughts into sequential execution steps. The translation of goals into a set of sequential steps is the basis for all human activity on earth. The mistake we often make is in underestimating the complexities in this process.

  Taylor

  Posted by: tcowan on December 31, 2003 at 07:37 AM

• not all software created equal
  We always talk about software as a whole, but the reality is that there are different types of software that deserve different types of treatment. For example, business applications require different skill sets and use different programming constructs/tools than operating systems, infrastructure software, or games. Raising the abstraction level in a general IDE or 3GL language can only go so far until you start focusing on the specifics of the target software type and the target programming audience.

  For example, in the late 80s, 4GLs had great success focusing on business applications by identifying the most common programming constructs (i.e. data/database structures and user interface forms) and offering tools (higher level abstractions) to streamline the development of these constructs. Accordingly, most of that era's business applications (and even today's largest business application suites--like SAP and Oracle Applications) are built with 4GLs. Unfortunately today, with the popularity of Java and web technologies, developers went back to 3GL constructs to build business applications, and are experiencing a high rate of failure (in terms of projects finishing on time and reasonable budget).

  Don't misunderstand me, 4GLs as we know them had fundamental problems and limitations: no standardization, outdated constructs for representing data structures (tables/columns), outdated constructs for representing user interface forms (took a while to get on the web interface bandwagon), and no clean and coherent constructs for addressing everything else (too much scripting).

  As somebody that has developed a complete 4GL platform in the 80s (using good old Turbo Pascal:-), and architected the first comprehensive platform for executable UML (Intelliun's VE), here is my two cents:

  - we have to think of software in different categories (which a lot of people already do), and business/web applications are way behind the curve in terms of raising the abstraction level.

  - expressing business (or domain) objects in UML Class Diagrams is far better construct than text-based code or text-based forms (like data dictionaries in 4GLs)

  - a lot of the logic that traditionally ends up in text-based code/scripts can be moved into declarative rules (expressions or Excel like formulas) around domain objects and their members.

  - I used to think that UML Activity Diagram is a good way to represent low-level (i.e. object operation level) dynamic behavior or sequential flow of control, but after using them for years in this manner, I now believe that text-based scripts are far more effective. However, the abstraction level of the script can significantly be improved (compare LOC in Smalltalk vs. Java, C++ or C for example).

  - You have to separate application logic into two categories: domain logic and interface logic. Then separate the interface logic into two categories: user interface (where the system responds to external entity's/actor's requests), and resource interface (where the system uses an external entity like a database or another application). The result is the 3-tier architecture applied to application construction.

  - Such separation already exists and is common practice. Unfortunately, text-based code like HTML, JSP, Java, SQL, etc., is still the predominant construct, which leaves a lot of room for improvement.

  - The domain logic must be the focal point and the main area of concern in application development, while the interface logic is kept as transparent and automated as possible.

  - And finally, we have to significantly reduce the time and number of steps between changing the logic and seeing its impact. Consider making a single change to a domain object, and all the manual changes you have to make to the dependent interface logic, the code-generation steps (if you're using more advanced IDE/frameworks), compilation, deployment, and restart of whatever server you're using. That is a lot of time (and in some cases effort), which significantly reduces the number of times you can iterate over and refine your domain logic.

  Posted by: ijabri on December 31, 2003 at 09:42 AM

• don't think so
  OK, I've edited that line to read "The era
  of humans translating their thoughts into sequential steps for the CPU to execute is ending. ". I obviously wasn't referring to all human activity on earth
  But in reference to your example: yes, when I make a peanut butter sandwich I follow a sequence of steps. But when I order a sandwich at a restaurant, I don't give step-by-step instructions to the waiter. I invoke a standardized PBJ solution via a well-known interface.
  And neither am I saying we've programmed ourselves out of our jobs. I'm saying that the software industry has matured to the point that it's less about the "how" and more about the "what".
  Over time, the "how" consolidates into widely used components that become the foundation for the next layer of "what". I'm saying that as we move to higher levels of abstraction, the vocabularies we need to express solutions become very different in nature.
  I expect to be programming in ten years. But I doubt I'll be using Java then. Ten years ago I was doing unix kernel work exclusively in C. Today, I never use C and I haven't even looked at kernel code in at least three years.
  

  Posted by: ronhitchens on December 31, 2003 at 01:22 PM

• don't think so
  This "how" and "what" debate has been running around in circles for a long time. You are right when you say: 'Over time, the "how" consolidates into widely used components that become the foundation for the next layer of "what"'. But the interesting question is if the "what" is described in a fundamentally different way than the "how" or if we are just talking of components that make use of each other but are based on the same language model.

  Maybe you are referring to exactly this when you say: 'the vocabularies we need to express solutions become very different in nature'. But I think "vocabularies" is too vague a term because it could mean domain specific library as well as domain specific language. Of course we write libraries for this and that and other poeple use them but there is no real "higher" level of abstraction. We just keep running after ever changing problem domains and fix them with the same basic tools as before.

  It doesn't really make a difference in terms of level of abstraction if we manipulate the same conceptual model as lines of text or diagrams or tables or natural language. We need to think in terms of the model anyway and these views just make the ensuing manipulations of the model more or less convenient. Another way to put it is that no matter if you write the string of characters "MyClass implements MyInterface" or if you draw a line from one box to another, the semantics of interface implementation stay the same. It's just a syntactical difference.

  And this is the reason why someone using a basic text editor will not be tremendously less productive than someone using Eclipse or a UML painter when both have to grasp the problem domain in terms of the Java language model. On the other hand, someone who has to implement the semantics of an atomic concurrent transaction by hand _will_ be immensely less productive than someone who can make use of predefined begin transaction - end transaction abstractions.

  So if there is to be a productivity revolution, mainstream software development will need to make use of different conceptual abstractions not merely better refactoring tools or fancy syntactical forms such as UML diagrams. The Excel "coder" is more productive for certain kinds of problems because he thinks in formulas and relationships between cells, not because Excel is very effective view on top of an object oriented language model.

  Posted by: ajeru on January 01, 2004 at 04:57 AM

• Or what
  Pictures are good at presenting certain types of information but they can't convey everything. For instance they don't show object state over time well. If pictures could convey everything then we wouldn't have Shakespeare in text but instead we would just have picture books. Don't get me wrong I am a strong supporter of UML and whiteboards. And I really like good old paper drawings. But text is still essential.

  In the end, I think some of the problems I see in the business app area is simply from having too many people enter the field during the BOOM years and poor IT management which has largely mishandled training for these people. And the recession doesn't help.

  Lastly, I am confident good programmers will always have jobs for the simple reason that too many executive types don't really have a clear idea about what they want or need. Sure there are some great ones out there but there are about 30% who are just coasting and don't have the leadership skills to make decisions. And us programmers (and busines analyst and Project Managers) are often the ones who can pull together an application.

  Posted by: themashby on January 06, 2004 at 04:58 PM

• wow power leveling
  wow powerleveling
  wow power leveling
  wow gold
  wow items
  feelingame.com
  wow tips
  Most Valuable WOW Power Leveling Service
  wow power leveling faq
  cheap wow power leveling
  wow power leveling
  wow powerleveling
  wow power lvl

  Posted by: wowleveling3 on December 13, 2007 at 07:11 PM

• 网络营销软件
  网络营销软件
  网络营销软件
  群发软件
  群发软件
  ---
  群发软件
  网络营销软件
  论坛群发软件
  网站排名软件
  群发软件
  推广小助手破解版
  论坛群发软件
  网站排名软件
  群发软件
  推荐给你很好的群发软件和信息群发软件和供求群发软件
  推荐给你很好的群发软件和信息群发软件和供求群发软件博客群发软件网络营销软件网络营销软件
  网站排名软件网站排名软件网站优化软件信息群发软件信息群发软件信息群发软件论坛群发软件网站推广软件网站推广软件博客群发软件博客群发软件

  群发软件群发软件博客群发软件论坛群发软件网络营销软件论坛群发软件
  信息群发软件推广软件网站推广软件网络营销软件网站推广软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件
  网站排名软件
  博客群发软件
  网站排名软件
  网站推广软件
  群发软件信息群发软件
  免费论坛群发软件
  论坛群发软件
  网站排名软件
  免费博客群发软件
  网站推广软件

  群发软件
  博客群发软件
  网站排名软件
  网站推广软件
  群发软件信息群发软件
  免费论坛群发软件
  论坛群发软件
  网站排名软件
  免费博客群发软件
  博客群发软件
  信息群发软件
  论坛群发软件
  信息群发软件
  博客群发软件
  qq群发软件
  邮件群发软件
  博客群建软件
  企业名录搜索软件
  信息群发软件
  邮件群发软件
  论坛群发软件
  博客群发软件
  网站推广软件
  网络营销软件
  全能营销破解版
  网络营销软件
  论坛群发软件
  论坛群发软件
  论坛群发软件
  网络营销软件
  信息群发软件
  信息群发软件
  信息群发软件
  群发软件
  论坛群发软件
  群发软件
  网络营销软件
  网站推广软件

  Posted by: u89io98 on December 26, 2007 at 12:01 AM

This work is licensed under a Creative Commons License.