replicator.org ... continuous garbage collection

What I feel when I watch TV, the news, or my twitter / G+ stream today is extremely frustrating to me. The polarization that is going on inside the minds of the people I know, follow or even admire is starting to get noticeable bizarre. It is as if people are going to fight for their mental survival without even knowing it, without even noticing that their opinions get more ignorant and sharper day by day.

Often I see worlds of facts being ignored in one single statement, just for the single purpose to push out an angled perspective and hope for those ignorant minds to follow up on it.

It is as if the people who previously ran on linear gray levels (which is not great either) get more and more attracted to the two point polarization of just good and bad. Polarized statements are a successful viral meme. They lift us from thinking about details, thereby ignoring everything in between and nearby. I’ve complained about that before, but I suspect it is getting worse at times when all the media hype on current and upcoming crises closes up on us.

One of the most influencing factor is our environment, and that’s something we can actually get under control. We can decide what information we consume and when it is allowed to reach us. And we can strengthen our firewalls that define how information affects us.

Our world is complex and faceted. It’s a complicated, chaotic fractal we will never understand, and so are most ideas and concepts the human mind was capable of creating yet. In polarized terms, that is a very good thing. No one would say that the holistic experience of nature is a bad thing.

Simplification and differentiation is what makes this world understandable to us, or better: engineerable to us. But that does not mean that simplification should make you feel better. And that does not mean that complexity should make you feel bad. They are just two perspectives which can even coexist at the same time.

What we first-world people seem to forget these days, is that a lot of what is important to us are just human created “concepts”. These “concepts” affect our emotions by igniting neural connections that are man made, learned and trained. Some of these connections may be fine. But others, specifically the ones that react on higher “concepts”, may be the root cause of the polarization trending I observe.

I can think about two directions to counter that trend:

• We need to detect information that is polarized. The more it is polarized, the more it should be attacked with critical thinking.
• To stay sane in the long term and to communicate without bias and with free thinking, we may need to reevaluate our emotional reactions on constructed “concepts” and try to unlearn some of them.

“The first problem for all of us, men and women, is not to learn, but to unlearn.” – Gloria Steinem

While browsing through the DART language specification, I thought, why not write a blog post about my first impressions. So here it is:

In the following transcript I’d like to cover the perspective as seen from a language geek. Someone who likes to talk about language features and concepts. So don’t be disappointed if you won’t find any examples here. This post is just about the details, the distilled stuff that distinguishes DART from other object-oriented programming languages.

All the following notes are based on the Draft Version 0.0.1 of the language specification and the online code samples.

What is DART?

The specification describes DART as a class-based, single-inheritance, pure object-oriented programming language, optionally typed and with reified generics and interfaces. It is C-based and so looks very similar to most languages that use ‘{‘ and ‘}’ to enclose their classes and statement scopes.

So what is so exceptional about this language?

Optionally Typed

While I prefer static typing, the burden to wrap your mind around types for every class, method and variable introduces a steep learning curve for new programmers and is often an annoying overhead for smaller projects. So DART takes the concept of a type system to a new level: Everything is dynamically typed as long types are omitted. And as soon types are specified, declarations get statically typed and verifiable. This is not only a great feature from a runtime performance perspective, but also a great tool for larger software projects that depend on clearly defined interfaces.

In practice, this means that you are free to write a program without any types defined whatsoever and specify the types as soon the project requires it.

Concurrency through Isolates (3.3)

DART is always single threaded with Erlang style actors that support concurrent threads of execution. In DART, actors are called Isolates. The name clearly stresses  their most important property: There is no shared state.

Isolates are regular classes that are derived from the base class “Isolate” and are started by calling the member function spawn().

There are two different types of Isolates, “light” ones, that run in the thread that created the Isolate and “heavy” ones that run in their own thread.

When light Isolates are started from the main UI thread, they can access the “document” and “window” DOM variables.

Isolates use a ReceivePort to accept and dispatch messages. One or more SendPorts can be created from a ReceivePort. ReceivePort and SendPort represent the two ends of an asynchronous communication channel. A message that is sent to a SendPort is copied and delivered asynchronously (without blocking the sender) to the ReceivePort. A message can be sent together with another ReceivePort that is used to deliver a subsequent answer to.

This separation of receiving and sending ports combined with the option to associate another reply port for every message sent, makes asynchronous messaging simple to use. For a concise example, take a look at the IsolateSample.dart source file line 74.

Privacy (3.2)

Interestingly, the designers of the DART language chose to bake the common convention to prefix private members with an underscore (‘_’) directly into their scoping rules. Meaning that every declaration that begins with an underscore is private and not accessible from outside the current scope.

Factories (7.5.2)

DART introduces a new kind of class constructor that is called Factory. These are constructors that look like static functions with one difference in that they explicitly return an instance of the class. A factory can be called like a constructor and its method body can fully control the instance that is returned.

A factory can be useful in situations where object instances need to be recycled and returned from a cache. They can also be used when additional processing code needs to be separated from the code that initializes the class instance.

Interfaces (8)

DART supports interfaces with optional type annotations. Interfaces can contain methods, operators, getters and setters.

Optionally, an interface can specify a factory class and a number of constructors. Together, they can be used to instantiate default implementations of the interface.

Numbers (10.3)

“Dart integers are true integers, not 32 bit or 64 bit or any other fixed range representation.”

Complex Types (10.6 ff.)

DART supports Lists (denoted by []) and Maps (denoted by {}) as native types. Maps always map strings to objects.

Function Expressions (also called lambdas or closures) are first class objects. It is possible to declare functions inline and pass them around.

String Interpolation (10.5.1)

Strings can contain expressions, like “hello world, I am online since ${days} days”. If the type inserted is not a string, the toString() method is called to convert it.

Libraries (12)

Libraries is the basis of DART’s module system. Libraries seem to be comparable to a package in Java or a namespace in C#.

The Cool Stuff

I like the decision to base DART on a single threaded execution model and move the concurrency abstraction to the actor level. Admittedly, some projects may not fit to DART just because they require concurrency and shared state, but for a large number of other applications, DART may be a great language choice.

You can translate DART to JavaScript today. But the resulting code may not look like you’d expect.

Functions do support optional parameters.

Generics support F-bounded quantification. Which effectively means that the generic type parameters can be constrained. This is similar to C#, Java and Scala.

The following operators can be user-defined: ==, <, >, <=,>=, -, +, *,~/, %, j, ^, &, <<, >>, >>>, []=, [], ~, negate

There is syntactic sugar to specify property getters and setters.

Type aliases are supported through the keyword typedef.

What’s Missing

For a first version, DART is a rather complete language, but there a some features I am missing:

• There is no method to access the types from within the language yet (i.e. like Reflections in Java or C#). This is planned for a future version.
• Labels are supported, but there no goto statement (11.11).
• No nested or inner classes.
• No value types or tuples.
• No scoping statement that controls symmetric resource usage (like the using() construct in C#).
• Pattern matching. This would be a nice addition to make Isolate receivers more concise.
• No Events.

Conclusion

DART is a modern object-oriented language with a fancy new type system, it supports actor based concurrency, interfaces, optional static typing and generics. Time will tell if DART is cool enough to replace JavaScript.

Despite the fact that Isolates are a great way to abstract over concurrency and that the type system supports optional static typing, I don’t think that DART can be used effectively for larger projects. For example, the compromise to support NULLs as a valid and default value for every type could be a big source of bugs in larger projects.

From a language evolution perspective, DART is a great language. It combines static and dynamic typing quite seamlessly. Future language designers may follow up on this idea and add strong type inferencing and tool support to create programming languages that enable programmers to write dynamically typed code that can later be refined towards static types, clear interfaces and refactoring options. Such a language would be easy to learn for an entry level programmer and a great fit for larger software projects.

Today, I’ve had some time to install Windows 8 in a Virtual Box to get a first impression of the Developer Preview.

And I am not impressed!

The Metro User Interface (Metroface?)

A tile based interface is probably a great choice for a phone or may be a tablet, but tiles don’t seem to be a good fit for the desktop experience.

For once, they all look alike. They don’t have clear characteristic properties that make them distinguishable. And animations make them even harder to remember.

And then, they are edged, which goes against every design study I’ve ever read about. Rounded corners are easier on the eye and resemble forms that occur in nature. I personally would take it even so far that I feel “offended” by this razor sharp user interface that may attack and cut me the very next moment.

The Full Screen Start Menu

Well, that is just another name for the Metro interface, Microsoft decided to remove the start menu and replaced it by the Metroface. Which means that every time you need to search for an application or a file, you are forced to switch from your desktop to Metroface in full screen. This happened all the time while I had my first Windows 8 session. I don’t want to imagine how much of a cognitive burden this would put on me when I use Windows 8 on my 3 screen setup. Fullscreen flash to Desktop, flash to Metro and back. Disgusting. Microsoft should not have removed the classic start menu from Windows 8 Desktop.

Update: Here is a tool that enables the classic start menu in Windows 8

Mouse Usability

The Metroface can not be effectively used with a mouse. There are (pretty ugly) scrollbars everywhere and the distances you need to move the mouse are often too far. And because everything scrolls in the horizontal direction, the mouse wheel can not be used to scroll the pages. Microsoft should have either supported direct mouse-down and drag gestures or vertical scrolling pages like in the WeTab user interface.

And the back-button experience is entirely confusing. Some apps do support a back button, but they only work inside the application, they never lead back to the start menu from where you started (or entered?) the app.

And on the desktop, even if no touch device is connected, the title bars look huge and ugly and the usually small title bars of the toolbar windows are as big as regular ones.

Development

Microsoft has created a completely new set of APIs to program against the Metroface. I think that Microsoft is making a huge error here by introducing yet another XAML API. They claim that one of their choices were that it is harder to create vivid apps with a managed language and so needed to create a new API that is accessible from the CLR, native C++ and JavaScript. But I doubt it. While JavaScript is a great language for making small apps in the short term, everything breaks down in the long term.

They should have used Silverlight as their base for Metroface, but I guess the kids that Microsoft employed to create the Metroface were just cheaper and more proficient in JavaScript. I hope that this does not end up like every large JavaScript project I’ve seen: as unmaintainable spaghetti code.

What I do like

The Explorer got its parent button back.

The Task Manager is better structured and cleaned up. You can see network traffic and IO transfers of each application individually in a well-arranged grid.

Conclusion

Either the Windows 8 Developer Preview is a very early beta, or Microsoft is taking a huge risk to introduce the next Vista. For a desktop user, the alieness in usability and style of the Metroface feels intensely distinct to the normal desktop experience and should not have been integrated into Windows at all. A better option would have been a clear separation between the two user interfaces. The Windows Phone 7 operating system and its Silverlight based application framework could have been extended to make a great tablet OS. And honestly, who wants to use Windows desktop apps on a small tablet screen?

Most details of user interfaces , for example, text, buttons, layout, and terminology, can be classified into how much prior knowledge is required to make them understandable:

Details that require Common Knowledge

That is, details that can be understood without having to learn anything new. The user is expected to have some form of prior knowledge that – in effect – creates a correct interpretation of what is being presented.

Examples are: The shape of buttons, or links that represent clickable elements, text written in the language the user knows about, or a layout that prioritizes information in terms of how the user scans the user interface visually.

Details that require New or Learned Knowledge

These are details or concepts that are specific to the domain of the user interface. The goal of the user interface is to communicate them to the user with the least amount of effort on both sides.

Examples are: New terminology, keyboard shortcuts, or graphical representations of concepts.

Creating a good user interface is largely dependent on how the details are working together to create a deep understanding of what the user interface represents.

If possible, simple user interfaces should use details that require common knowledge only, but any more advanced user interface needs to introduce details that need to be absorbed first.

Building a simple user interface that merely uses details of common knowledge often restricts your users from working efficiently. For example: Complex task can not be combined without introducing a new user interface element, or specific tasks may require a detailed understanding of the domain terminology before they should be used at all.

As soon the required knowledge level of each detail is defined, user interfaces can be built so that they start up with the simpler details and introduce the user to more efficient and natural abstractions over time.

So obviously, there are two steps to make a better user interface:

First, every little detail needs to be classified into “commonly known” or “new to learn” category. Details that are in the gray area should be placed in the “new to learn” category.

Remember, you are a developer or designer and you know this stuff, but – for example - most computer users may have never heard of a context menu, though they may use it all the time. You don’t need to envision a senior person who has recently learned to use a computer, but a conservative decision about what details need a introduction may be a good start to cover most users.

Second, every detail in the “new to learn” category needs an introduction. This is the hard, challenging and creative part. For once this can be implemented explicitly, by writing a textual introducing somewhere where a new detail appears. Or – and that is the most exciting part of user interface design – by a contextual introduction that automatically produces an aha-effect.

Producing The Aha-Effect by Contextual Introduction

One good example for a contextual introduction of a new user interface is the scrollbar of the iPhone. While the scrolling itself is a simple feature that every user gets as soon he touches the screen, the iPhone’s scrollbar, which shows how much of the current scrolling area lies outside of the screen, introduces itself by simply appearing and changing while the user is scrolling the list. Sooner or later, the user gets what the scrollbar represent. It clicks.

But often it’s not so simple. For example, more complex touch gestures may not be introduced at all and are buried in the manual that no one reads. These gestures will be overlooked by a lot of users. But when the same functionality is reachable by a menu, for example, a small transition animation that resembles the gesture in some abstract form may be introduced to the user.

I think that getting aware about what user interface details need an introduction and the implementation of contextual introductions that produces an Aha-Effect are the most important, challenging and creative part of user interface design.

Now that spatial queries are implemented, the Presentation Layer needs to access the Visuals stored in the R-Tree. The Presentation Layer consists of separate classes that handle the distinct visual layers. These are the Nodes, the Connectors, and the Labels. Additional layers are used for overlays and prototype Visuals, but these are not of importance right now.

BrainSharper supports dragging the whole canvas at once. Zooming is not yet supported, but will be soon.

Right now, the Presentation Layer receives the events that are dispatched by the domain and realizes them by creating or modifying (WPF) control objects. Obviously, this is a push-model: The domain pushes the events to the user interface.

To change the Presentation Layer from a stupid “I present you all Visuals” Canvas to one that manages the only the Visuals inside the Viewing Area, the following components need to be created:

• First of all, a component that can retrieve and present the Visuals directly from the R-Tree is needed. For the lack of ideas I call it the “Visual Presenter”.
• Another component, that coordinates the viewing area rectangle must be introduced. This component computes the model rectangle and forwards the dirty rectangles to the “Visual Presenter”. I will call that class the “Viewing Area”.
• A component that flushes unused visuals needs to be built. This component runs when the user is idle and instructs the visual layers to free Visuals that are not inside the viewing area. ”Visual Collector” is probably a nice name for it.

Additionally, I decided to split up the layer classes into a controlling part, that handles all domain events, and a viewing part, that displays the controls.

All in all, the Presentation Layer is going to morph towards a more pull-oriented nature. It watches the domain events to get notified when something changes. And whenever the view area changes, it queries the missing Visuals directly from the database.

Below is a rough visualization that covers only the node layer:

Some details of the implementation:

Visual Presenter

The Visual Presenter queries the Visuals from the R-Tree table. Obviously, this takes some time depending on the number of visuals that intersect with the Viewing Area. On my computer, the queries run in sub-millisecond time, but to avoid lags on slower computers, I decided to decouple the queries from the main thread. This should improve the scrolling experience, but may cause new Visuals to pop in while the user is dragging the document.

Visual Collector

Another advantage of introducing a Worker Thread, is that the Visual Collector can also use it. I’ve decided to implement the Visual Collector in a similar way like the Presenter: As soon the Viewing Area has changed and the user is inactive for some time, the Visual Collector runs a background task to find out what Visuals should be displayed inside the viewing area. It then instructs all layers to hide Visuals that are not visible. Of course, the Layer Views could decide autonomously to hide the visuals that are not inside the viewing area, but I wanted that the Presenter and the Collector use the same rectangle information for the intersection tests. This guarantees that the two mechanisms don’t contradict in their decisions. Another advantage is that the Presenter and the Collector are both independent of the user interface framework.