The Internet is Broken

After a discussion with Diarmuid about the state of computing, its become pretty clear to me that the Internet is broken. Not only that, but applications are broken, software frameworks are broken, operating systems are broken and hardware is broken too.

Sure, they all work, but they work in an I-need-to-sit-beside-my-toaster-with-duct-tape sense of work. A true appliance does not bother the user with so much low level detail, so much implementation detail and so much meaningless management. A real appliance just does its work without bothering the user about how. Computers are far from being an appliance, in this sense.

Mobile phones are a lot better here, but even they could be better still.

Ok, let me start from the beginning. Why is the Internet broken?

Come see The Dark Knight today at 7pm in Cineworld.

Every time I see a message like this, I’m reminded that the Internet is broken.Every time I’m shown old, outdated or plain irrelevant information, I know that the Internet is broken. Its 8pm! Theres no Cineworld near me. The Dark Night hasn’t been screened in a year! Yep, the Internet is definitely broken.

I have nothing against archived data. In fact, I think its a good thing, but the Internet (or rather, the applications and protocols used to implement the Internet) should be smart enough to know when I require archived information or up-to-date information. Alongside this, the Internet should be a lot less manual, I don’t care about web sites and URL’s and all those meaningless details. I just want to accomplish my task, get my information. We’re already heading this way – the average user (who really does not want to be bothered with low level details at all) already seems to use Google to find their websites instead of remembering the URL and typing it into the address bar. Does your girlfriend/grandparents/dog even know what an address bar is? Hell, 92% of people don’t know what an Internet browser is… (My apologies to the tech savvy girlfriends/grandparent/dogs out there)

I’d love to rant about the Internet longer (actually, I wouldn’t, which is why I’m promptly changing the subject), but I feel its time to take a step back and watch how this phenomenon affects the rest of the computing environment. In fact, this should really be evaluated and fixed before the Internet is tackled.

My biggest problem with computers is that the bother me with details which I just don’t care about. What do you mean I need to start an application to edit my presentation? Why should I have to care about that! Applications, programs, services, web sites, filesystems and all those other things which take up such a large portion of my computer time – why am I constantly being bothered about this? Surely the computer is in a better position to manage these boring, monotonous operations for me, transparently, in the background – letting me get on with my work so that I can leave the office sooner and enjoy some sunshine for once…

Lets say I want to calculate some tax returns, generate a pretty table and graph, put some information underneath, in bullet point format, email it to my boss and send a copy to some archive in the office. On a current system, the procedure to accomplish this task might be something like this:

1. Start the spreadsheet application
2. Enter the data and formulas
3. Generate a graph
4. Export data and graph as an image (Yeah, I’m aware that often I can actually embed the spreadsheet in other tools and this is certainly a step in the right direction, but it suffers severe interoperability issues currently…)
5. Start the presentation application
6. Add the text
7. Import the image
8. Save/export in some suitable format
9. Open my email application or web browser to access my emails
10. Write an email to the boss, attach the presentation, send email
11. Mount shared drive/start FTP client/whatever I need to do
12. Send file to archive

Thats 12 steps – without dealing with the issues of closing applications after I;m done with them… I also left out details such as where do I save/export these files to? and load them from again.. This is ridiculous. Thats too much management taking up my time. Obviously these things still need to happen, but they should be as transparent as possible. Maybe something like this:

1. I browse to my new work item (more commonly known as a file, I am renaming it because I want to emphasise that its a higher level idea) widget (the meaning of browse depends on the user interface, of course)
2. I begin entering spreadsheet data, as I enter, the system tries to detect what kind of data I’m entering and provides me with an unobtrusive menu, in case it guessed incorrectly
3. From inside this environment, I should be able to perform all types of editing tasks. An unobtrusive panel or menu should allow me to switch between tasks. The system may start and stop applications behind the scenes to accommodate these tasks.
4. When I’m done, I simply browse away from the work item. The system stores it for me, without my interaction, unless I tell it not to. There should also be some means of naming, tagging and categorizing work items.
5. I tell the system, perhaps through some glorified terminal, to “email work_item_1 to boss” and it will try and predict who this is and provide a prompt of relevant choices.
6. I tell the system, again, using my glorified terminal, or whatever the user interface would be, to “archive work_item_1“

Actually, we can do better than that. Because we know that the user was working on that item, we can assume that this is the item they want to interact with, unless told otherwise. So a simple “email to boss” and “archive” (or “send to archive” or whatever) should be enough. Of course, theres no reason all of this cannot be done with some graphical interface for the typing-averse people out there.

The point is that the computer should worry about loading and saving my work for me (ie orthogonal persistence), starting and stopping programs, applications and services and determining what I want using some context sensitive heuristics.

The entire system stack should be built like this: from hardware, to operating system, to inter-application communication, to application framework, to application to internet. Everything should be context sensitive and should be tuned to my needs. Think Google search with its suggestions, only applied to everything. The computer should simply work.

One possible user interface could be something like this

• A zoomable desktop with a Google-like search bar at the bottom of the screen which doubles as a temrinal command input area.
• When I finish editing a work item, a screenshot of it is placed on the desktop, where I was working on it. I can drag this screenshot to another place on the desktop, if I should want to.
• I can pan around the desktop as well as zoom in and out, hence zoomable desktop.
• When I zoom in on a work item screenshot, the application needed to edit this type of item is automagically started up (transparently, behind the scenes) and I can edit that item.
• When I zoom out again or pan away, then an updated screenshot is generated and the application is stopped again,
• I can tag these items with blog-like tags and categories to aid sorting and searching and add different metadata to it so that the system knows how to deal with it.
• The search box at the bottom of the screen allows me to search for items by name, pattern, tag, metadata, category, general location on the desktop etc.
• The search box can also be used to enter specific commands, ike you would in a temrinal now.
• The search box would also allow you to enter context sensitive smart-commands, like “send to bob”, in which case the send command would send the last work item which you edited/viewed to bob. Bob would be looked up in my user profile list of destinations (email contacts, IM contacts, FTP server, whatever) to find where it should be sent to. An unobstrusive popup dialog would prompt me with the matching items, so I can correct it if it guessed incorrectly.

Theres obviously more to it than that, but it should be a good enough start to get everyone thinking about the problem and potenital solutions a bit. If you have any ideas, comments, queries or feedback, please comment! I’d love to hear other peoples ideas on this.

Of course, the real problem can be seen with a simple question, which will be asked when trying to transition users to a new, fixed and working system:

Thats all very well and good, but does it run Microsoft Word?

Which is completely in line with what I have already said.

Language Concept

I was digging through my external drive yesterday and I discovered some notes on a programming language concept. I will briefly talk about it here.

There are a few things I really like in programming languages:

1. Parametric recursive data types
2. Automatically checked type constraints
3. Pattern matching and guards
4. Automatic event management
5. A concise and simple syntax (point free, if possible)
6. Restartable/Resumable exceptions
7. Type inference

This language concept features, at a minimum, numbers 4, 5 and 7.

In this language, just like in Java, everything is an object, of sorts. Also, just like in Java, you define each “class” inside its own file and the file name must match the class name. In the spirit of being short and concise, however, the language eliminates the redundancy and boilerplate: you do not need to define the class or give it a name, we already know its name is the same as the file name. We also already know that everything inside that file belongs in that class.

This is only a minor, cosmetic change, though. The more interesting features are the automatic event and dependency management.

Lets start with some sample code:

[Filename: ButtonClick.lang]

public
    reset click -> false
    click_count <- local_click_count
private
    local local_click_count = 0
    react click: local_click_count += 1

in some other file:

import io
import .ButtonClick
private
    local clicker = ButtonClick
    display: io.print “Button clicked ”
                      clicker.click_count
                      “ times.\n”
    main: times [clicker.click = true, yield] 3

What this does is creates a number of cells which contain data:

• click, a cell which will reset to false every time it gets set

     >>> clicker.click = true
     >>> io.print clicker.click
     --- false

• click_count, a cell which is bound to the value of local_click_count
• local_click_count, a local variable. This is a standard integer variable, “bound” to click_count
• react click, a function which reacts to click being modified

When click is set to true, the react click code is run. This will change the value of the local state variable. In turn, this causes the public cell to change.
The other file creates an instance of this class as the object clicker and defines two functions: display, which displays the current click count and main which is run on program start. Because of the automatic event management system, any time clicker.click_count changes, the display function gets rerun. As I stated above, setting click to true, will increment click_count, so if you set clicker.click to true, the value for click_count is incremented, click is reset to false and display is executed.

The main function simply sets clicker.click to true three times, waiting for events to be handled in between.

The concept is simple enough – modules/objects may contain mutable local state, but communications between modules can only be done through automatically managed events. Any code which relies on these events (by referencing a cell or because its a reactor) will be automatically evaluated any time the event occurs (that is, any time the dependents change).

The language could be visually enhanced too:

Visual representation of code

At this point, I’d like to point out that this is not the language I have envisioned and is not what this blog aims to be about, but it is a step in that direction. So bear with me, I will slowly transition into dataflow and hopefully design a useful, intuitive and powerful dataflow language in the process. Or at the very least, learn something useful.

Concurrent or Parallel?

I just realised that I made a bit of a mistake with my “Concurrent Programming” post. Concurrent programming and parallel programming are not really the same things, yet in my post, I talked about both under the one term: concurrent programming.

Instead of editing the post, I’ll just clarify here:

• Concurrent programming is programming in a way that multiple events happen, conceptually, at the same time. That is, we impose no sequence or order on operations because we do not need to or because we want to avoid one long-running action from blocking others. For example, when you save a large file, it may be useful to run the user interface concurrently to the code which writes the file to disk. On mult core or CPU systems, these things could actually run in parallel, but they don’t need to – they could be interleaved, for example.
• Parallel programming is about executing tasks in parallel as a performance optimisation or for redundancy. The goal of parallel programming is either to perform calculations quicker, by splitting them into sub-calculations which can be run at the same time or to achieve fault-tolerance through redundant calculations happening at the same time.

The difference between the two is that concurrent programming doesn’t actually need to be parallel programming, but must give that illusion because the concurrency serves some other purpose. Parallel programming does this for performance or redundancy and therefore does need to be run in parallel. Obviously, the two may be mixed and mashed together. It is worth noting that there is a difference, however.

In this blog, when I speak of concurrent programming and concurrency, I’m really referring to both of these and I also usually mean that tasks will actually run in parallel, at the same time, though this may not always be a requirement.

Just something to be aware of when reading my insanity

Upcoming…

Ok, its been a few days since my last post. I really want to post about dataflow, but not until I have a prototype interpreter up and running. I had hoped to have a simple one written over the weekend, but other things got in the way. I’ve been insanely busy with work at the moment too.. (we are in the middle of a deployment in the middle-east, so its a bit hectic here at the moment).

Since I’m not quite ready to write about datalow and I don’t really have the time to write a detailed post about anything else right now, I’ll instead try to outline the topics I hope to cover over the coming weeks in order to give you a taster of what I have planned.

So here goes:

• Dataflow, concepts, ideas, techniques, advantages
• Dataflow implementation based on my prototype interpreter, how it can be improved, what I intend on doing with it
• Mixing dataflow and other paradigms, compiling other code to dataflow
• Hierarchies, flat vs stacked (credit goes to Cleo Saulnier for this one)
• Anonymous message passing event system for component based software
• Ideas for operating systems, application interoperability, user interfaces, etc
• Some unrelated stuff:
  • Musca tiled window manager
  • Vim scripting
  • Python programming
  • Factor programming
  • Miscellaneous programming topics

I will edit more into this post as I think of it. Also, if anyone has any requests or questions, feel fre to comment on this post and let me know.

Concurrent Programming

Since the advent of inexpensive multicore processors, there has been a lot of buzz about how concurrent programming is hard. So hard, in fact, that we are in a software crisis because Moores Law is coming to an end, being replaced by systems with many parallel cores. This means that, in order to take advantage of these systems, concurrent programming is a must. Yet concurrent programming is extremely difficult.

Let me ask you, is concurrent programming actually hard? Does it need to be?

My answers are yes, concurrent programming IS, indeed, hard and no, it DOESN’T need to be. Let me explain.

In my own professional experience, concurrent programming has proven itself to be hard.

I work on core network services for the telecommunications industry, with clients in the middle-east and southeast asia, amongst other areas. We develop value added services for SMS networks for mobile operators – SMS anti spam, blacklisting, throttling and so on. On a medium sized network, we must be able to cope with 2000+ messages per second – this includes a large number of rules and processes which must be applied to each message.

When our current product was still in its infancy, the architecture was very much different than it is now. We wrapped each rule and process inside a “task” and we had a “Sequential Task Processor” which processed these tasks individually, but sequentially. One day it was decided that its time to “optimise” this system by “parallelising it”. Time estimate? About 2 hours – the tasks are there, they “only” needed to be made execute concurrently! To cut a long and painful story short, about two weeks later, we were still ironing out bugs and issues and wondering why it was slow and why we had so many intermittent problems. Not to mention how difficult this made tracing through logs – the entries could now be in any order! Eventually, months later, the entire task code was thrown out and replaced with a much much simpler system where messages are processed concurrently, but the rules were all sequential. The code was suddenly easy to understand, fast and stable. Logs were now predictable too!

Another example, again from work, was that we run our system in a clustered environment. Both to increase overall throughput and to provide redundancy. To achieve this, we had a number of data structures (hash tables, trees, etc) which were globally accessible between all nodes. These “shared caches” were used to store all sorts of interesting information, including messages themselves (so that if the node died, another one can process the message instead). Conceptually, the system was brilliant! Fault tolerant, scalable, highly distributed… except not. All of these data structures needed to be manually locked. Changes needed to be pushed out to other nodes. It became our biggest source of problems and bugs. Again, eventually, after a lot of pain, we scrapped the entire concept and redesigned the system so that each node is as independent as possible. Again, doing this made the code easier to understand, faster and a lot more stable!

What did I learn from this? Simple – concurrency is extremely hard to get right! Well, I knew this already, since I read a lot of programming blogs, but this was the first time it really sunk in.

I’m sure that anyone who has ever worked on a large concurrent system has experienced similar pain. Anyone who still feels that traditional (monitor based shared state) concurrency is not hard probably hasn’t written a terribly large or complex concurrent system.

The question, however, is: does it have to be hard?

I don’t think it does. There are some techniques which can ease the pain of concurrency. The first is Transactional Memory. A good introduction can be found over on the Intel website. Transactional Memory aims to remove explicit locking by handling all synchronised accesses as a transaction and if theres a clash, the transaction can be rolled back and run again on clean data. This certainly simplifies concurrent programming, but it solves the symptom, not the cause by hiding the complexity. Brushing it under the rug, so to speak. One still needs to deal with the same issues.

Another method, which, IMHO, greatly improves concurrent programming, is a shared-nothing message passing system where messages are immutable. This works really well, because the logic can be completely lockless! If the data cannot change, once created, then theres no danger of concurrent writes. Brilliant! Concurrency is not so hard now, is it? Highly concurrent languages like Erlang use this model and they do it pretty well.

But no, shared-nothing message passing is far from a “Silver Bullet” of concurrency. Firstly, not all problems are suited to a shared-nothing model. Secondly, and more importantly, the programmer must still manually handle the concurrency. Must still manually decide what should be concurrent and what should be sequential. The programmer must still decide when to process messages or when to post messages. In fact, this is the real problem with concurrent programming – its too manual. Locking causes problems, but its not the root problem – as I said, locking can be elliminated using Transactional Memory or message passing.

So, is concurrency still hard? Yes, it most certainly is. How can this be solved? The answer to that is by eliminating the programmer from the decisions of what should be concurrent, when and how. The compiler should determine this and concurrency should be automatic and transparent.

Easier said than done, of course and this is the holy grail of concurrent programming research! Just take a look at recent ACM SIGPLAN publications. So far, there has been little real success…

But I said that I believe concurrency doesn’t need to be hard! I still believe this, even after all that. In fact, I actually believe that concurrency is a solved problem! Not only that, but that it was solved a long long time ago.

Outrageous claim? Maybe, but let me explain.

In the book, Concepts, Techniques and Models of Computer Programming , Peter Van Roy writes a few interesting words on the topic. In the chapter which deals with internal state (for example, in object oriented programming, objects contain internal mutable state) he writes that in the next chapter he will reintroduce concurrency to produce a stateful concurrent model not unlike what we are used to in mainstream languages. He then states that this is an extremely dificult model to program in. He agrees that concurrent programming is hard!

In the introduction to the chapter on declarative concurrency, however, he asserts that “concurrent programming need not be hard”. Wow! Where did that come from!? Reading on (or understanding the chapter title: “declarative concurrency”) provides the answer: dataflow.

Dataflow is an old, yet often forgotten or ignored, programming paradigm and I believe it holds the answers, where concurrent programming is concerned. Why? Because it can handle concurrency automatically, implicitly and transparently. Programmer not required! In effect, dataflow programming is the holy grail of concurrent programming. I won’t explain here why – dataflow deserves its own dedicated blog post – but I will assure you that dataflow is real and exists RIGHT NOW.

In fact, in certain circles, its even quite popular:

• LabVIEW, commonly used for data acquisition, instrument control, and industrial automation by industry and by the scientific community.
• SCADE & Lustre, this is used in the defence and aerospace industries and is also used to run big industry operations like nuclear power plants.
• VHDL & Verilog, hardware design languages used to program FPGA’s and ASIC’s.
• I almost forgot the most well known dataflow systems of all!! One everybody is familiar with: spreadsheets.

LabVIEW and SCADE are graphical dataflow systems. VHDL and Verilog are textual dataflow languages. All four are used fairly heavily and have existed for quite some time. There are many more. I find it interesting that dataflow was the chosen paradigm for critical applications such as defence, aerospace, hardware design and power plants! If its good enough for them, its surely good enough for us mere mortals.

This proves that not only is dataflow real and available RIGHT NOW, but it also implies that there is, indeed, value in using dataflow, or these languages wouldn’t be popular in their domains.

The next step, in my opinion, is a general purpose dataflow language which is tailored for mainstream programmers and caters for general programming tasks. This langauge must automatically scale across multiple cores (or even multiple computers), be easy to learn and use and be a productive language to develop software in.

I will talk about this in a lot more detail in future posts.

Whats wrong with technology?

Today I had an interesting discussion about the problems with techology. Put simply, I was observing how we had technologies five, ten, twenty, thirty years ago which, in some ways, were more advanced than what we use now. Sure, ideas eventually trickle into the mainstream and technology advances, but its at a much slower pace than it could be. Technology is always many years ahead of the mainstream. Great technologies often get overshadowed by the mediocre and does not resurface until many many years later. Examples of this happening include the Transputer T-9000, the Intel 432, the Burroughs Large System and AmigaOS’s interoperability functions.

AmigaOS’s interoperability is an interesting example as its something  I regularly wish I had. Put simply, it allowed one to automate GUI events so that you could create software by scripting multiple small tools and applications to work together towards some common function. This is exactly like unix utilities and shell scripts, except applied globally to all software, including GUI applications. This would not be too dificult to implement in current operating systems, yet it isn’t something I’ve really seen much, if anything, of on mainstream computers. In a way, AmigaOS, back in the eighties, was more advanced than the systems we have now – where interoperability between programs is concerned anyway.

There appears to be a trend where great technological ideas fade into obscurity only to have the concepts reappear in some form many many years later. This seems like a slow and inefficient way to progress technology. Why does this happen? I guess technology really can be too ahead  of its time.

The real reason this happens, however, in my opinion, is business interest. A large company pushes its, often inferior, software on the masses, knowing that they will buy whatever they are told is superior, rather than what is technologically superior. Most people don’t know the area well enough to really evaluate if a piece of software does caters for their need or not anyway. If they are told it does, they are happy enough. Ignorance is bliss – they have no reason to think otherwise, even though some forgotton technology may be much better suited. Its the same in all industries however and I know that I’m one of the sheep when it comes to other products which I buy. Software is not unique.

As a market become popular, business will try to exploit the opportunity to make money so they will push their own products. If the market gains enough poularity, more and more companies enter the market and inevitably cheaper and cheaper products get pushed as an attempt to undermine the competition. This sounds great for the consumer, though sometimes it backfires and overall quality drops to accomodate the low price. This way, the more interesting and useful technologies often get left behind in favour of the cheaper, more profitable technologies.

This happens everywhere, not just computers. A friend of mine said it best. Paraphrased slightly, he stated:

Same with cars,
Same with phones,
Same with TV,
Same with Music,
Same with Games,
Same with BBS,
Same with The internet,
Same with Email,
Same with Filesharing,
Same with Planes,
Same with Spaceships

Technology becomes popular, businesses see new markets to leverage, the market becomes saturated, the lowest common denominator becomes dominant, new technology is created to get away from the lowest common denominator and the cycle repeats

There definitely seems to be some truth in this.

Software Sucks!

Yes, thats right. Software sucks. It sucks big time. Its probably always sucked. At the rate we’re going, its always going to suck.

How does it suck? Well, its…

• unreliable. By this I mean its buggy, unstable, clunky.
• insecure. There are so many exploits available, its just not funny anymore.
• bloated. Too many large applications are giant monolithic messes.
• hard to extend. Usually. Unix pipes are nice, but they don’t apply to GUI applications. Some programs provide mechanisms to be extended, but theres no standard way of doing this.
• slow. Programmer time is more expensive than computer time, so programs tend to be written in less efficient ways that makes it easier for the programmer and the computer picks up the extra weight. This is fine, but with the shift towards multi-core, the computer can’t keep up as well anywmore because concurrent programming is hard.

Why does software suck though? Because…

• Programming is difficult.
• Interoperability sucks.
• Code reuse is difficult.
• Concurrent/multi-core programming is difficult.
• As code gets larger, complexity (and therefore bugs) creep in.

But why do these things happen???

• Programming implies sequential steps where ordering matters. Get the order wrong and the code misbehaves.
• Code reuse is dificult because usually code is too specific to be easily reused. Mainstream languages don’t make writing generic reusable code terribly easy.
• There are no easy to use, global means of interoperating between programs, so instead of using existing programs to implement functionality, we usually rewerite it.
• Manually managing concurrency is hard! Compilers are not very good at automating concurrency.

In his paper, No Silver Bullet, Fred Brooks states:

there is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity

So, according to Brooks, software development will never significantly improve and software therefore will always suck.

I believe he is wrong. In this blog, I will try to explain why.