Since my last post where I presented a number of ideas on a declarative domain specific language for implementing web applications, I learned about the language oriented programming paradigm.
I recommend reading “Language Oriented Programming” by M. P. Ward. It also claims programmer productivity as a benefit of what it calls the “middle-out” development style.
In a couple of recent posts I have argued that a higher level language is needed to
provide a significant boost to programmer productivity in the area of web applications. This is a topic I have been thinking about for many years. I’ve worked out some aspects of what I think the language should be. A little over a year ago I even started implementing a parser for the language in ANTLR. I worked on it for a few weeks before moving on to other higher priority projects. Higher priority simply means something more interesting caught my eye. It’s finally dawning on me that I’m not going to get a big enough block of free time to work on this any time soon. I guess I prioritize the smaller projects that have a better chance of getting finished.
Instead of mothballing the project completely I’m going to share some ideas from it. This his may be of interest to others and who knows, I may get back to it from time to time.
Continue reading…
Tools, languages or frameworks — which will have the biggest impact on developer productivity? I previously said that I thought languages could do better than frameworks in this regard. Now I’ll talk about at least one class of tools.
A good deal of focus around developer productivity is on visual editing tools. I think these efforts are misguided and unlikely to produce major benefits to developers. Clearly tools are useful. Humans are natural tool makers and users. Written language is arguably the most important tool invented by humans. Programming languages are tools.
So what do I mean by visual editing tools? My definition may be a little fuzzy but here it is: I’m talking about tools for creating software that don’t have an underlying text based language or completely hide it. They usually involve working with pictures, diagrams, or forms. Some examples:
These are some of the general problems I have found with visual editors. Not all of them have all these problems and I’m not signaling out a specific tool.
Good editing tools assist you while working with a text based language. The most basic editing such as random access to the text, insert, delete, cut, copy, paste etc. is sufficient to get the job done and has the benefit of working equally well for all text languages. Advanced features such as syntax coloring, unobtrusive flagging of errors and warnings, context sensitive completion, access to language and API help, type based searching and navigation, refactoring, template insertion/completion, bracket pair matching, indenting etc. are very useful and don’t replace or get in the way of the text.
Diagrams can help visualize aspects of programs but programs are too complex and multidimensional to be fully represented in any picture or diagram so it is a mistake to think that the visualization is the program and can be edited directly. Being able to draw (or even edit) diagrams is a nice add on for a language but the language must come first and stand on its own.
Some tools claim to have an editable underlying text format when in fact it is just the tool’s internal model serialized as XML. This doesn’t count. Not because its XML but because it tends to favor ease of serialization and the needs of the tool over the ease with which humans can read and write it. XSLT is a good example of a language that uses XML syntax. It was clearly designed to be edited directly by humans. The fact that it can’t be fully described with XML schema is probably a good indication of this. I like XSLT but I also agree with Terence Parr when he says “I implore everyone to please stop using XML as a human interface!” (see his excellent book “The Definitive ANTLR Reference”) .
The best development productivity tools help the user write in a given language not replace language.
My first computer was a Texas Instruments TI-99/4A. I got it just before going to college. I had been interested in computers since junior high but this was the first time I could afford one. The primary programming options were Extended BASIC and assembly. Writing interesting programs required assembly (because BASIC was too slow) so I learned TI TMS9900 assembly language. I went on to learn a few others including PDP-11 and 8080.
If you have programmed in any assembly language you know how tedious it is. There are so many details to be concerned with that have nothing to do with the problem you are trying to solve — simple instructions, addressing modes, managing registers, and maintaining the call stack to name a few. Because the instructions are so simple you write volumes to accomplish little. Often you would be dealing directly with hardware devices so at the same time as dealing with the many details of the processor’s instruction set you had to understand the idiosyncrasies of the device IO registers.
Once you got some small useful thing working like writing a character to the screen you made it into a reusable library routine so that you didn’t have to write that code again. Libraries helped but the big leap in productivity came with higher level languages. Frederic Brooks wrote in No Silver Bullet: Essence and Accidents of Software Engineering:
“Surely the most powerful stroke for software productivity, reliability, and simplicity has been the progressive use of high-level languages for programming.”
Structured statements replaced compares and jumps. Expressions took the place of numerous instructions. The vast (well not so vast by todays standards) stretches of memory locations were replaced by data structures. The compiler took care of pushing values onto the call stack and popping them on return.
The details were interesting to a point and there was satisfaction in having the level of knowledge needed to program in assembly language. Making the switch to a language like C meant giving up some control but it was well worth it because of the productivity gain.
The switch from assembly to high-level languages didn’t happen instantaneously. Trust had to be won. Early compilers had bugs. People thought they could do better optimization than the compiler, and at first they could, but compilers got better and better. Compilers could also do something that assembly programs couldn’t — they could compile your program so it could run on different types of CPUs.
Writing web applications today reminds me of assembly language programming because there are so many details to be concerned with: HTML, CSS, JavaScript, HTTP, and browser incompatibilities and idiosyncrasies. Then there is the server side technology; pick one of Java servlets, CGI, PHP, .NET etc. and perhaps a framework or two. Also you probably need to know SQL if your application data is stored in a database. Cross cutting issues such as usability, accessibility, security, performance and internationalization add additional dimensions.
The details can be interesting and sometimes frustrating. Do I really need to know that IE make the href attribute an absolute URL when inserting an anchor into the DOM while Firefox does not? (This usually doesn’t matter since if you use the href property you always get the absolute URL but it bit me once.)
I would like to create web applications without having to worry about many of these details. When I say HTML is the assembly language of the web I’m including CSS and JavaScript. I see the Browser as the processor (CPU) and HTML, CSS, and JavaScript as the instruction set. I get the feeling that we should be programming at some higher level.
There are plenty of libraries and frameworks available that help. Some are getting to the point where you don’t need to know much about HTML or JavaScript (GWT, JSF come to mind). JavaScript libraries like jQuery or Dojo are making it much easier to write cross browser code.
So whats wrong? Like I said, some of these frameworks abstract away HTML so you can think in terms of higher level “components”. The problem is they are still just libraries (for the purposes of this article frameworks are just really big libraries). I believe that larger productivity gains are possible from languages rather than libraries. The languages may be domain specific — for creating web applications — but thats OK. The languages could be compiled or interpreted or some combination of both.
One very important thing that happened with the move from assembly to high-level languages is that one relatively small group of people were able to focus on implementing compilers that did great optimization following the best practices for the particular CPU type while another much larger group of people focused on building their applications.
Imagine if best practices like using a hidden token to protect against CSRF or using the POST-Redirect-GET pattern were built into the language.
Imagine if cross cutting concerns and decisions that usually have to be made up front were compiler switches or runtime options. Examples:
There are huge opportunities for performance optimizations – on the client, over the wire, and on the server. The optimizations can improve over time independent of the applications. Imagine if css, js, and images were automatically combined, minified, and compressed such that overall response time was minimized.
Yes the abstractions will leak. It will take time for the language implementations to get good enough and for programmers to trust them. I would like to see this happen.
Some may wonder if I actually read “No Silver Bullet” or just pulled a quote from it. After all it says that languages are not a silver bullet. I’m not arguing that they are. I’m saying that they can do better than frameworks. There is enough accidental complexity in building web apps today that a domain specific language could be a big help.
So why hasn’t it happened yet? Perhaps its just that the right framework hasn’t come along yet. Thats the thinking that has given us at least 57 frameworks in Java alone. I think some believe that tools are the answer. It used to be that you could charge money for a compiler. Not so anymore. But that can’t be the problem since most of the frameworks are also free.
Perhaps it is already happening. I have not dug into Links but it sounds just like what I’m talking about.
I plan to write more on this topic in the future.
I don’t expect my kids to become programmers like their dad. I wouldn’t wish it for them unless it is what they want for themselves. Still, I think there is value in getting exposure to programming for a number of reasons – thinking logically, planning, designing, applying math, understanding how things work and fostering creativity to name a few.
The question is when and how to introduce kids to programming. Scratch may be the answer to how and right about now the answer to when. Scratch is a new language from the Lifelong Kindergarten group at the MIT Media Lab designed to make it fun and easy for kids 8 and up to create programs. My kids and I found Scratch instantly compelling. Everything about Scratch, from the friendly looking cartoon cat that starts out in each new project, to the building block style programming, to the sharing of projects on the Scratch web site has been designed for and appeals to the youngest possible audience.
My kids are at the young end of the target age range for Scratch so I don’t expect too much programming from them at this point. The important thing is that they are really excited to use the program. They create projects to collect, edit and arrange pictures. They are interested in seeing and trying the projects that other people have created. It provides a context for me to talk to them about things like the X, Y coordinate system in terms of the number line they already know and what it is used for in moving things around on the screen.
Just the other night I was sitting with my youngest and she had chosen a cartoon girl sprite and a bedroom background. Then she asked “can we make her jump up and down on the bed”. I said “sure” and in a few minutes I showed her how. A block to move up. Click, a block to move down. Put them in a repeat loop, click. How many times do you want her to Jump? Twenty, OK. Oops, too fast. Click, add a wait block. Done. Then I introduced her to variables so she could control how many times the girl jumped.
The Scratch web site provides a social network where people (I say people because it is not just kids playing with Scratch) can share their projects and ideas. Any uploaded project can be downloaded by anyone so they can open it up and learn how it works or simply just play with it. This really fosters learning and building on the ideas of others. You will see some comments complain of copying or ripping off ideas but overall the site promotes an attitude of sharing. Knowledge and ideas are not a scarce resource to be horded and protected they are abundant and should be shared. Many people share projects that demonstrate a particular technique and encourage others to use it in their own projects.
I am very impressed with the projects on the Scratch web site. There are over 32,000 projects as of this writing, which is impressive since the program only came out in May of 2007. Some projects are artistic perhaps using color cycling or other graphic effects to make their pictures come to life. Some are animated stories. Some are musical. Some interactive. There are plenty of video game style projects ranging from imitations of classics like Pac-Man or Donkey Kong to original ideas. There are projects exploring science and math and many show a great deal of sophistication.
The usability of the development environment is superb. It is well organized and intuitive. It is also visually attractive. What I find most impressive, for such a new product, is that it is rock solid. I used it a number of hours over the course of a week often leaving it running for days without a single crash, glitch or loss of data.
Programming is done by putting together statement blocks such as 
and control blocks such as 
. As far as I can tell it is not possible to get an error message no matter how you put the blocks together. It may not do what you want but it will not complain that you did something wrong. Feedback is immediate. Just double click a block to see what it will do. Another great feature is that you can change your program while it is running.
Scratch is implemented in squeak. When the projects are uploaded to the web site they run as a Java applet. I have noticed some differences between the behavior of my project when run in Scratch and as an applet but the differences are minor. Probably just display glitches in the Java graphics routines.
How about the Scratch language itself? Well from an experienced programmer’s point of view the language is extremely limited. For example, variables can only hold numbers, there are no string manipulation operations, and there are no arrays or collection data types. Not surprisingly the programs are event driven. Groups of statement or control blocks are run when the start flag is pressed, a key is pressed, when a sprite is clicked or when a message is received. Messages are broadcast and all handlers act on the message. You can define as many messages as you like. Messages cannot have arguments which is one of the most limiting things. The message handlers are the closest thing to a subroutine but because there is no argument passing all information flows through global variables. I would say that it is a strongly typed language in the sense that the round edges of a numeric value will not fit where the sharp edges of a Boolean expression are expected. Variables must be declared.
Simple things like prompting for a name and then outputting "Hello " + name is very difficult due to lack of input/output and string manipulation primitives. However things that would be complex in other environments like hit tests between two moving sprites are trivial. I had to remind myself that I am not their target audience and everything left out was probably left out for a good reason – usability.
I am not a big fan of graphical programming languages. I quickly got tired of the Lego Mindstorms block programming language and switched to NQC. I found the Mindstorms programming environment to be slow, noisy, and inefficient. All of the graphical programming languages I have ever tried I found to be far inferior to text. Scratch is no exception but it is the best interface I have see yet. I also think it is just the right thing for young kids. Having visual blocks to move around really maps well to the physical world they are used to manipulating.
I do hope the language gets extended. I would like to see advanced users be able to explore programming concepts such as recursion.
Like I said, its not just my kids that find Scratch compelling. I wanted to play with it as well. I rationalized that by learning it I would be better able to help explain it to my kids but I like creating things no matter what the medium.
My first project is Addition Tutor. It is an interactive program to learn and practice addition of up to 3 digit numbers. I decided on this project because of the challenge of inputing and displaying numbers in Scratch and because it is something that I’m teaching my kids now.
Scratch is not the first programming language with kids in mind. Way back when there was Logo and more recently KPL. I took a quick look at KPL and it looks like visual basic to me. Unlike Scratch there was nothing enticing me to try it out. The first thing you may ask about a language is what can I do with it. What better way to answer that question than with a web site with thousands of examples all of which you can download and try.
I recently started learning Python and to my surprise find it to be a very nice language.
I had heard good things about it years ago but never gave it a look. I noticed that Joel Spolsky gave Python half credit as a safe choice of language to develop enterprise applications in. Still, I was (and still am) happy working in Java.
What prompted me to look at Python is my new Job. I now work at BEA. The BEA WebLogic Server has a tool for configuring and managing domains called WebLogic Scripting Tool (WLST). WLST is based on Jython (Jython is Python implemented in Java).
I started reading a Python tutorial. The first thing I noticed is that code blocks are identified by indenting. This seemed very strange and uncomfortable after years of using curly brackets. Now it makes sense to me. I was going to indent my code anyway so why shouldn’t the language make use of that fact. A side benefit is no more arguing over if the curly brackets belong on the same line or a new line. If arguing about code style floats your boat be comforted that you can still argue over how many spaces to indent.
So far I have created two small utility programs in Python. One gathers some information about files and outputs an XML file. The other processes an XML file using SAX and outputs a new XML file. (I didn’t use XSLT because I needed to write files, run a program and include it’s output as new element content.) Even with the learning curve I was able to write these programs faster then I could have in Java. Also the code is much smaller than their Java counter parts would be.
Some things I like about Python:
fruit = { "apples": [ "Cortland", "Braeburn"], 'pears': [ "Bartlett", "Bosc" ] }
Than it is to do this:
HashMap fruit = new HashMap();
ArrayList apples = new ArrayList();
apples.add("Cortland");
apples.add("Braeburn");
ArrayList pears = new ArrayList();
pears.add("Bartlett");
pears.add("Bosc");
fruit.put("apples", apples);
fruit.put("pears", pears);
Python will replace Perl as my scripting language of choice.
Entries (RSS) |
Comments (RSS) |
Entries (Atom)
Copyright © 2006, 2007 John Snyders
Powered by WordPress | Theme by: John Snyders
