The proposal to add closures to Java continue to move along. Neal Gafter has posted an update on the closure proposal.
Archive for the 'java' Category
Patterns
It’s interesting how simple patterns reappear in the most unexpected places, and how they often the similarity goes unnoticed. For example, take this simple pattern condensed from A Pattern Language.
179. Alcoves**
. . . many large rooms are not complete unless they have smaller rooms and alcoves opening off them. . .
* * *
No homogeneous room, of homogeneous height, can serve a group of people well. To give a group a chance to be together, as a group, a room must also give them the chance to be alone, in one’s and two’s in the same space.
This problem is felt most acutely in the common rooms of a house—the kitchen, the family room, the living room. In fact, it is so critical there, that the house can drive the family apart when it remains unsolved. . . .
In modern life, the main function of a family is emotional; it is a source of security and love. But these qualities will only come into existence if the members of the house are physically able to be together as a family.
This is often difficult. The various members of the family come and go at different times of day; even when they are in the house, each has his own private interests. . . . In many houses, these interests force people to go off to their own rooms, away from the family. This happens for two reasons. First, in a normal family room, one person can easily be disturbed by what the others are doing. . . .Second, the family room does not usually have any space where people can leave things and not have them disturbed. . . .
To solve the problem, there must be some way in which the members of the family can be together, even when they are doing different things.
Therefore:
Make small places at the edge of any common room, usually no more than 6 feet wide and 3 to 6 feet deep and possibly much smaller. These alcoves should be large enough for two people to sit, chat, or play and sometimes large enough to contain a desk or table.
Give the alcove a ceiling, which is markedly lower than the ceiling height in the main room. . . . (Alexander 1977b)
CLR – Multiple Languages
Reading this for a second time invoked a number of thoughts. The first was to relate this pattern to virtual machines, like the .NET CLR. In this first example, I was thinking of how they serve as a nexus for different programming languages. The CLR (or JVM) itself is much like the room at the center, and the languages the alcoves. Much like height of ceilings, no one language can meet the needs of all developers or development tasks. Different developers require languages of different complexity. More importantly, different development tasks require languages of different complexity (and possibly developers of different complexity too).
But developers are best as a community to avoid solving the same problems more times than necessary. Without a central (intermediary) language, it’s not possible to share libraries seamlessly, and communication is more difficult. The CLR serves as a common center. IL establishes sets a level of maximum complexity, and each language retains some autonomy while enjoying the benefits of the CLR.
It’s worth noting that the CLR must be more complex than all other languages by nature of having to support the primitives of those languages. In principle, languages using the CLR could be more complex, but they would have to dumb down their behaviors and fake that complexity within IL. But by doing so, that complexity would become inaccessible to other language consumers. Ideally, you want the IL to support the same or greater level of complexity.
I use the CLR as the example here, because Microsoft was first to popularize the concept, but the JVM is just as capable of this. There are some minor differences, but I won’t waste time (today) trying to discover which is better. Instead, I’d prefer to move on to a similar example that the JVM popularized.
JVM – WORA
One goal of the JVM was to unite multiple operating systems. The concept was Write Once Run Anywhere (WORA). You can see the similarity, where the JVM acts as a center. Operating systems would share applications, not just libraries, and communication would be less difficult. However, like language interoperability you’d want the central room to have the highest ceiling, because otherwise you would be limited by the JVM.
But whereas writing a high level, nonuser language like Java bytecode or IL relaxed many constraints of design, due to not having to worry much about the user, multiple operating system support did not have the same advantage.
For simple actions that were already common to operating systems, the process worked well. For more complicated areas, like user interfaces, where different operating systems had significantly different implementations, it did not. Java has tried very hard to address this, but while Java 6 is set to address many outstanding UI issues, Microsoft is set to release a new UI framework. Beyond this, what about the unique UI features of the OS X, both today and tomorrow? In order to be the center for all operating systems, Java would need to be an operating system, bigger and more complex than all others.
Of course, a more practical approach is to rely upon WORA only in application domains that rely mostly upon simple common features. In these areas, the JVM serves portability needs very well.
It’s interesting to note that such portability is as possible with the CLR. Mono for example runs most .NET applications that don’t make use of user interface libraries tightly coupled to the Windows operating system. But cross platform user interface libraries are just as possible under the CLR as under the JVM. GTK# is an excellent example of one. But of course, the same difficulties with taking advantage of OS specific features arise, but if portability is more important than the latest features then this is an option.
It’s also interesting to note that other operating systems can have direct support of their own, like with Cocoa#. The Java community has generally discouraged this type of development, but it is just as possible under the JVM.
Integrated Development Environments – Language Workbenches
A few weeks ago, I was writing about the importance of metadata. Serendipitously, a reader of another post linked me into an essay of Martin Fowler’s that tuned into what I’ve been thinking about for a while, but haven’t quite so eloquently written. To sum it up, Martin talks about “language workbenches”. He defines a workbench as:
- Users can freely define new languages, which are fully integrated with each other.
- The primary source of information is a persistent abstract representation.
- Language designers define a DSL in three main parts: schema, editor(s), and generator(s).
- Language users manipulate a DSL through a projectional editor.
- A language workbench can persist incomplete or contradictory information in its abstract representation.
Since that might not make too much sense out of context, I’ll sum it up. The idea is the workbench maintains a central abstract representation of code. Editors, instead of being simple text editors interact with this representation. The overall user experience could be similar or the same, but the underlying mechanics totally different.
This is however, another example of the alcove pattern, where the workbench is defining a high ceiling abstract representation, but you can use multiple editors and sublanguages to satisfy the needs of individual domains. This takes the inter project cross language compatibility established by the JVM/CLR and extends it to intra project activities.
There’s more to this topic however, which I will cover in another post.
Other examples
There are plenty of other examples of this pattern. Operating Systems themselves are a good example. Applications need their own process space, but they also need a standard system for communication with hardware, other software, and the user.
Pieces of networks are good examples as well. The network itself isn’t a very good example, but anywhere that users have both a private and shared space, such as sites like digg and reddit are good examples.
This is an important concept to remember in designing network applications because it’s important not only that you give users a place to communicate, but also that you allow them enough isolation that they don’t wander off to their own rooms, or feel constrained within the one room.
It’s nice to be right. Not to toot my own horn too much, but today Sun announced a proposal for closures in Java, in the Dolphin (JDK 7) release. I uncovered the hints of this in the JSE6 documentation about a week ago.
I suppose that isn’t a really stunning scoop. The writing was on the wall anyhow. Almost every other modern language either always had support for functional programming, or already had plans to support it. Therefore it could only be a matter of time before smart people like Gilad convinced the pointy haired bosses to listen to reason. I have to agree with him when he say’s “what took so long”.
I haven’t had a chance to review the whole spec yet, but if you’d prefer it in non-HTML format, Neal Gafter, one of the other co-authors has a copy (Updates: 0.1, 0.2).
Anyhow, this is great news, even if you use other languages like Ruby. Making functional programming a standard language feature, as ubiquitous (or more so) as the class, can only make it easier for all developers to communicate.
The only downer is that JDK 7 is a long way off still, so there will be a bit of a wait.
I’ve been doing a lot of reading lately, and lot of it has been about functional programming. There are many well known writers out there with quite a bit to say on the topic. For example, Steve Yegge and Paul Graham talk about the virtues of functional languages a lot. What I don’t understand is why neither has even once mentioned C# 3.0. They and many others talk a lot about Ruby, and how important functional programming is there, and they are right. But I can’t understand how someone who values functional programming so much can ignore the functional features in C# 3.0. Sure, they might like Ruby more, but when Microsoft releases C# 3.0, functional programming will finally be mainstream in a way that Ruby would take years to reach. And for an advocate of functional programming, that should be an event of astounding importance. But not one single mention of it is made on either site, or many others that advocate LISP, ML, Hakell, OCaml, etc. Will C# 3.0 do everything these languages do? No, but I think it hits the most important points, at least as in the area of functional programming. Why do these writers completely fail to mention such a momentous turn of events for one of their most dear principles? I can only conclude it is a hatred of Microsoft, which causes them to think irrationally when it comes to anything from Microsoft. If it was just a few writers, this wouldn’t trouble me so much, but it’s not just a few writers. I see so many people who will simply pretend as all Microsoft’s products with less than 90% market share are insignificant. I expect the reaction will be different when Sun announces that they intend to support functional programming in Java as well. I’m not sure when it will happen but I am sure they are thinking about it. If you look at the specs for the pluggable annotation API closely, it talks “new language features”, and visitor classes. This can only mean one thing, lambda functions with closures. Of course, unless Sun is being very tight lipped about this support, Microsoft will beat them to the punch. It’s unlikely that Sun is hiding anything because the JCP process does not really allow for that. It’s nice to see that Sun has woken up, and isn’t ignoring what .NET is doing, as they once did. J2SE5 was a litany of copycat features, for which I applaud Sun, rather than deride them. And of course, functional programming in general is a copycat of what LISP did long ago. But that’s ok, because with programming languages it’s not all about which language was first. We programmers are more practical than that.. Aren’t we?
Dynamic languages have been gaining support and interest over the last few years. Static languages however still dominate usage, and have benefits, like performance and verifiability, that some dynamic languages would like to replicate. At the same time, some static languages are realizing the value of dynamic languages and are attempting to replicate some of those benefits, while retaining the static capabilities. I have attempted to create a list of the dynamic features that static languages are picking up on, and how they are addressing them. I am sure this list is not yet complete as most there are a great deal of interesting languages out there these days, and I have not had a chance to review them all. If you know of a few more features or implementations, let me know. If your interested in static/dynamic crossover, you might be interested in three earlier posts. Inform, Suggest Safety and Allow Freedom, Static/Dynamic? Why not both? and Principles of Language Design – Semantic Capture Safe features do not require late binding and retain all static type checking ability, while shortening syntactical definition. Sometimes this results in a clearer syntax as well. Safe features stretch from syntactic translations, like type inference, to functional extensions like lambda expressions. Found in: C# 3.0, Visual Basic 9, F#, Fortress, ML, OCaml, Haskell, Boo, Nemerle, Groovy?, CleanSafe Features
Type Inference
Type inference is the simulation of dynamic syntax while maintaining static typing. A variables type is not explicit, the compiler infers it from the context. The depth of inference can vary, but usually takes into account at least constructors for local variables.
Note: I could not really tell whether the def statement in Groovy was a dynamic variable or a type inference mechanism.
Structural Subtyping
Found in: Haskell, ML, OCaml
Also know as: ad hoc interfaces
Structural subtyping can be thought of type inference, where the name of the type is not taken into account, but only the structure of the type. The ultimate result is very similar to duck typing, while remaining completely statically typed.
Found in: C# 3.0, Visual Basic 9, haXe, OCaml
Anonymous types
Also know as: immediate objects
Anonymous types allow using dynamic syntax for temporary types or data structures. Under the covers, these are just another type with an implicit name.
Tuples
Tuples are very similar to anonymous types, but tuple members do not have names. Technically I believe the term tuple could be used to refer to anonymous types as well, but in practice where the term tuple was used it was with unnamed members.
Lambda Expressions
Found in: C# 3.0, Nemerle, ML, OCaml, Groovy, Boo, Nice
Generics
Found in: C# 2.0 Visual Basic.NET, Java 5, Managed C++, Nemerle, ML, OCaml, etc.
It is somewhat debatable if generics are a dynamic feature. They fulfill a very specific piece of the self-generating program capability available from many dynamic languages, but do it in a very different way.
Unsafe Features
Unsafe features shift evaluation to runtime through techniques such as reflection, lazy evaluation, or runtime interpretation.
Runtime Casts
Found in: C#, Visual Basic, Java, C++, Nemerle, Boo, etc.
Not commonly considered a dynamic feature, casts that evaluate type coercion to at runtime are a dynamic feature. In statically typed languages, runtime casts usually only result from explicit casting, yet the two terms are not synonymous.
Dynamic variables (a.k.a. Duck Typing)
Found in: Visual Basic.NET, haXe, Nemerle, Boo
A dynamic variable is quite simply a variable that not only can hold an object of any type, but allows any member name or signature to be valid at compile time. Some languages like Visual Basic enable/disable this globally or per file. Other languages have a specific dynamic type.
Dynamic interfaces
Found in: Visual Basic 9, Nice
A dynamic interface allows for after the fact interface definition. A dynamic interface is similar to a dynamic variable, but defines some restrictions. Like a dynamic variable, a dynamic interface at compile time accepts assignment from variables of any type.
Dynamic blocks
Found in: haXe
A dynamic block allows evaluation of a series of statements to either partially or fully at runtime.
Known implementation techniques
Generate reflection code. Miniature interpreter.
Dynamic identifiers
Found in: Visual Basic 9
A dynamic identifier allows evaluation of individual identifiers at runtime. In many ways, dynamic identifiers are reflection short hand, but their syntax is similar to that of dynamic languages.
Recent Comments