Friday, May 20, 2011

What makes programming so boring?

This is one of those late night thoughts, so forgive it if it is stupid.

In terms of structure, and complexity, programming has moved forward significantly. We have many new and exciting control structures that (arguably) help us to tackle greater levels of complexity. While individuals may disagree about exactly which control structures (observers, callbacks, object oriented programming, functional programming, event based programming, whatever) actually advance us, I think most agree that the level of abstraction that a programmer can deal with has gone up from the level it was in the past, thanks in large part to these control structures.

However, in terms of relatedness, that is, interaction of a programmer to his program, very little has been done. By and large, it is still just entering text. I will expand.

There is the physical act of programming a machine. This is done by entering text, executing/compiling said text, and observing the result. This has been the same for quite some time.

However, programming is not just about entering text. It is also about setting up a rhythm such that you can work. Finding a flow, that is, being interested and alert enough to tackle the next problem. This is more difficult than it sounds. Writers find flow when they are relating to their characters, when the plot interest them, when the story is intiging. Programmers constantly have jump from one idea/module/structure/file to another. These context switches are interruptions, and make it difficult to find flow. If you could "relate" somehow to the next bit of work, you might have a easier time switching to it.

Because all I do to get my program to work is enter text, I relate to my program as text. But does this have to be the case? Is there some other way I could relate to my program? Perhaps we  could anthropomorphize aspects of programming? Maybe individual modules of code could be "skinned" in some way such that they appear to be sick or healthy (depending on how many unit test they pass). Or maybe they appear confused when they aren't properly commented? Or walk around unbalanced when their code blocks don't align very well? How about bloated when a function gets too large?

I am aware that these ideas seem kind of stupid, and perhaps they are individually, but I think they point to the theme I am trying to get at. Simply stated, it is, "Can we make programmers care more about their programs if we present the program in such a way that programmers relate to them?" Currently programmers are forced to interact with pieces of text. If we could transform this text into something that could be more easily related to, anthropomorphize, or compete upon, then that would seem to be a good thing.

What your eyes physically view are only tiny little pinpricks of what you think you can see: your brain fills in a great deal of the detail. Similarly, you imagination can fill in a worlds of details, as long as it is given a few things to run with. If we could just give a few things to spark [interest/ a competitive streak/ a completionist desire] from the source code that we program, I think we could significantly increase the diligence and care that people put towards creating software.

Tuesday, May 17, 2011

A expandable editable list in Sproutcore

This is a continuation of yesterdays code.

Yesterday I built something that allowed one to have a list of items in a list wherein one and only one item could be expanded in said list. Today, I am going to expand and refine upon that idea. Specifically, I am building a list of items, where each item is a bit of editable text. Because each item is a bit of editable text, the vertical height can vary depending on how much text is entered.

Side Note: Sproutcore has the concept of a lazily loaded view container. This is very cool. It allows you to have a list of items that might contain hundreds of thousands of items, but only end up loading the ones you actually see. The catch is that each item needs to be equal in height, because the list calculates which views to display based upon the distance of the currently scrolled view area from the top. Because of this, the list being built today will not really work with lazy loading. This is because each view item in this list does not have a standard height. This really is not a issue if you are dealing with a small list of items, but it is something to keep in mind if you tried to use today's list with a huge list and using lazy loading.

What do we want?
A list, maybe 10 items or so, where each item in the list is a piece of text. Clicking on any item in the list will cause it to become editable. When editable, a item switches to a html textArea, and focus is placed in the textArea. This is a special textArea that resizes depending on how much text you put in it. Clicking outside of the editable item at any time causes it to switch from our textArea back into regular text. The size of the textArea should be roughly comparable to the size of the text when focus is removed. This allows people to gauge what their text will look like when they are done editing.

Work In Progress