I know I’ve mentioned Clojure now and again in this blog, but I haven’t actually talked that much about it. I feel it’s time to change that right now – Clojure is in the air and it’s looking really interesting. More and more people are talking about it, and after the great presentation Rich gave at the JVM language summit I feel that there might be some more converts in the world.

So what is it? Well, a new Lisp dialect for the JVM. It was originally targeting both the JVM and .NET but Rich ended up not going through with that (a decision I can understand after seeing the efforts Fan have to expend to continue providing this feature).

It’s specifically not an implementation of either Common Lisp nor Scheme, but instead a totally new language that’s got some interesting features. The most striking feature of it is the way it embraces functional programming. In comparison to Common Lisp who I characterize as being a multiparadigm language, Clojure has a heavy bent towards functional programming. This includes a focus on immutable data structures and support for good concurrency models. He’s even got an implementation of STM in there, which is really cool.

So what do I think about it? First of all, it’s definitely a very interesting language. It’s also taken the ideas of Lisp and twisting them a bit, adding some new ideas and refining some old ones. If I wanted to do concurrency programming for the JVM I would probably lean more towards Clojure than Scala, for example.

All that said, I am in two minds about the language. It is definitely extremely cool and it looks very useful. The libraries specifically have lots to say for them. But the other side of it for me is from the point of Lisp purity. One of the things I really like about Lisps is that they are very simple. The syntax is extremely small and in most cases everything will just be either lists or atoms and nothing else. Common Lisp can handle other syntax with reader macros – which end up with results that are still only lists and atoms. This is extremely powerful. Clojure has this to a degree, but adds several basic composite data structures that are not lists, such as sets, arrays and maps. From a pragmatic standpoint I can understand that, but the fact that they are basic syntax instead of reader macros mean that if I want to process Clojure code I will end up having to work with several kinds of composite data structures instead of just one.

This might seem like a small thing, and it’s definitely not something that would stop me from using the language. But the Lisp lover in me cringes a bit at this decision.

All in all Clojure is really cool and I recommend people to take a look at it. It’s getting lots of attention and people are writing about it. Stu Halloway is currently in the process of porting Practical Common Lisp to Clojure, and I recently saw a blog post about someone porting On Lisp to Clojure, so there is absolutely an interest in it. The question is how this will continue. As I’ve started saying more and more: these are interesting times for language geeks.

10 Comments | By Ola Bini | In: blogging | tags: clojure, lisp, programming, programming languages. | #

While writing the post yesterday about testing regular expressions, I realized that this problem is not really specific to regular expressions. I got a very good comment noting that testing any place that uses some kind of DSL is definitely prudent. SQL is another example.

But these examples are both about actually testing the usage of them, and the problem becomes that you have two languages, but you’re mostly only testing the code written in the outer language. This is due to several reasons. One of the most obvious ones is that our tools really doesn’t make it that easy to do.

Thinking about these issues made me start thinking about how we generally test languages. Having worked on several language implementations and worked on both new languages, and implementations of existing languages, I’ve come to the conclusion that the whole area of testing languages are actually quite complicated, and also there are no real best practices for doing it.

First, there is a problem of terminology. Many implementations of languages that are really executable specifications of how the language should work. What’s the difference? Well, testing the language according to such a spec, you are really only doing functional, black-box testing. I’ve looked at several of the open source language implementations, and I don’t really see much usage of anything else than such language spec tests. This means basically that some parts of the implementation can be implemented wrongly, and by some freak chance it still works correctly in all the cases you have tests for, but it might fail in other ways.

Unit tests for the actual implementation would help with this – it helps since you will be doing TDD on the unit level, it helps because you make a conscious decision about the implementation and what it should be doing in these cases. It still doesn’t make everything clear cut and simple, but it absolutely would help. So why don’t most implementations do unit testing of the internals? I don’t really know. Maybe it’s because implementations can be extremely complicated. But that should be a reason for testing more, not testing less. One reason I feel a bit about is that it makes larger changes quite hard. Large refactorings are one of the ways JRuby has used to get incredible performance improvements and new subsystems, but unit tests can sometimes act as inertia for these.

I’m totally disregarding the academic approaches here. Yeah, in soem cases for simple languages, you can actually prove that it does what you want it to do, and for small enough implementations using a suitable language, you can actually prove the same things about the implementation. The problem is that this approach doesn’t scale.

And since a language almost always is turing complete, that means that you can’t exhaustively test it. There is no way of testing all permutations – either manually or automatically. So what should a language spec do? The first thing that many languages do are to specify that whole areas of functionality result in undefined behavior. That makes it easier. But the real problems exist when you start combining different features which can interact in different ways.

At the end of the day, I have no idea how to actually do this well. I would like to know though – how should I test the implementation, and how should I write an executable language specification? And these questions doesn’t even touch on the question of testing the core libraries. Many of the some problems apply, but it gets even more complicated.

8 Comments | By Ola Bini | In: Uncategorized | tags: implementors, programming languages, test. | #

This is a continuation of my previous posts describing layers of code written in different programming languages. I have thought about the things involved for a while, and had several discussions with people about it. There were some parts that I didn’t describe as well as I thought in my posts, and I will try to do better in this one.

The core of these ideas are based on polyglot programming, the thinking that you should use several different languages in a project, based on which languages are better suited for different parts of it. Another term for this concept is Language-oriented programming. So how do you organize a polyglot system? The most natural way for me is to divide it into layers. In most cases you will find that different categories of languages will be better suited to different layers of the application.

In my original post I identified three layers that can be used to organize polyglot systems. These layers are the stable layer, the dynamic layer, and the domain layer. There are several reasons for organizing them this way, and I’ll take a harder look at each of the layers further down. But first let me note that these layers are usually depicted in the form of a pyramid, with the stable layer being that base. That is definitely not how I think about it. In fact, I see it as an inverted pyramid, where the stable layer is the tip of the pyramid, providing the base. The Dynamic layer is the middle part. The domain layer should be the largest part and will very often include more than one dynamic language. So in my mind I represent the different domain languages as smaller pyramids standing upside down, covering the base area. Now, the dynamic layer can also be divided into smaller parts like this, based on language or functionality. This is a bounded fractal representation, which is the reason for the title of this blog post.

This diagram shows how I think about it:Of course, the smaller pyramids can be all the same language and system, or several different ones. It all depends on the application or system you are building. So you can for example use a combination of Ruby, Java and external or internal DSLs:Or you could use Clojure, Scala and JavaScript:
Or any other combination you can imagine. As long as the combination is what’s best suited for the problem.

Let’s take a look at the definitions of the different layers. There have been some discussion about the names I’ve chosen for them, so let me describe a little more what the responsibility of each part is, and why it’s in that part of the system.

The Domain Layer
This layer is the simplest. This is where all the actual domain rules are defined. In general that means one or more domain specific languages. It doesn’t really matter if they are internal or external. This model see them as the same layer. This part of the system is what needs to be malleable enough that it should be possible to change rules in production, allow domain experts to do things with it, or just plain a very complicated configuration. The languages used in this layer are mostly external DSLs, but can also include extremely DSL-friendly languages like Ruby, Python or Groovy.

The Dynamic Layer
Neal Ford argues that this layer isn’t so uch about dynamic, as it is about essence. That was never my intention. The problem is that even if you take a language like Scala, which is usually classified as an essential language, Scala requires compilation. To me, compilation is ceremony, which means that it’s one extra thing you don’t want to care about when writing most of your application code. That’s why this layer needs to be dynamic. This is where languages like Ruby, Groovy, Python, JavaScript, Clojure and others live.

The Stable Layer
I view the stable layer as the core set of axioms, the hard kernel or the thin foundation that you can build the rest of your system in. There is definitely advantages to having this layer be written in an expressive language, but performance and static type checking is most interesting here. There is always a tradeof in giving up static typing, and the point of having this layer is to make that tradeof smaller. The dynamic layer runs on top of the stable layer, utilizing resources and services provided.

Another important feature of this layer is that this is where all interfaces are defined. By interfaces I mean external API’s. They need to be hard for other clients to be able to trust them. But the implementations for them lives in the dynamic layer, not in the stable. By doing it this way you can take advantage of static type information for your API’s while still retaining full flexbility in implementation of them. Languages in the stable layer can be Java, Scala or F#. It should be fairly small compared to the rest of the application, and just provide the base necessary services needed for everything to function.

The most common objection I hear from people about this strategy is the same as for the general polyglot programming idea: if we have a proliferation of languages in a system, it will be harder to find skilled programmers who can work with it.

This objection is true to a degree, but there are several ways around it. First, I have to say that I don’t believe this is such a big problem as many others think. Programmers nowadays depend on their tool chains quite heavily, all of them including many advanced features that takes lots of time to learn. But most programmers doesn’t even view their languages as tools. In my mind, the programming language is the most important tool. And once we start using better languages for systems, many of the things we need other tools for will disappear or become less of a problem.

I tend to believe that programming languages are quite easy to learn as soon as you understand the fundamental building blocks of programming languages. And if you don’t have a fair understanding of these building blocks, I would say that you probably aren’t using your current language as well as you should either. I see this as part of being responsible programmers.

I also believe quite strongly that if we used better languages for our code, many code bases would be smaller, easier to understand, easier to maintain and cost less – which means you could afford to find a more skilled programmer to do the work for you. This would mean that both parties win – the programmer gets more interesting work and better code, while the client gets more worth for his money in less time.

10 Comments | By Ola Bini | In: Uncategorized | tags: domain specific languages, fractal programming, polyglot, programming languages. | #

As some of you might have noticed I am not extremely fond of everything the Java language. I have spent some time lately trying to figure out how I would change the language if I could. These changes are of course breaking, and would never be included in regular Java. I’ve had several names for it, but my current favorite is unJava. You can call it Java .314 or minijava if you want. Anyway, here’s a quick breakdown of what I’d like to see done to make a better language out of Java without straying to far away from the current language:

• No primitives. No ints, bytes, chars, shorts, floats, booleans, doubles or longs. They are all evil and should not be in the language.
• No primitive arrays. Javas primitive arrays are not typesafe and are evil. With generics there is no real point in having them, especially since they interact so badly with generic collections. This point would mean that certain primitive collection types can’t be implemented in the language itself. This is a price I’m willing to pay.
• Scala style generics, with usage-defined contra/co-variance and more flexible type bounds.
• No anonymous inner classes. There is no need for them with the next points.
• First class methods.
• Anonymous methods (these obviously need to be closures).
• Interfaces that carries optional implementation.
• No abstract classes – since you don’t need them with the above.
• Limited type inference, to avoid some typing. Scala or C# style is fine.
• Annotations for many of the current keywords – accessibility specifically, but also things like transient, volatile and synchronized.
• No checked exceptions.
• No angle brackets for generics (they really hurt my eyes. are there XML induced illnesses? XII?). Square brackets look so much better.
• Explicit separation of nullable from non-nullable values.

These points are probably quite substantial together, but I still don’t think the language would be that difference from Java in syntax and semantics. The usage patterns would be extremely different though. You wouldn’t sacrifice any performance with these kinds of things – they wouldn’t change the characteristics of the output that much, and I believe these things could make the language smaller, cleaner, and easier to work with.

31 Comments | By Ola Bini | In: Uncategorized | tags: java, language design, programming languages, unJava. | #

(To protect the innocent, all names of programming languages have been changed. All likeness with existing names is purely for dramatic effect.)

I have heard many times now that LRM doesn’t scale. People have been telling it to me in all these different circumstances. They tell me that languages like Deep Throttle and Moulder have scaling but LRM doesn’t. Even the Scally language has scaling – you could understand that from the name I guess. So why doesn’t LRM has this feature?

Since I’m rather fond of LRM, and really don’t want to go back to either Deep Throttle or Moulder, I decided to add scaling to LRM. I mean, how hard could it be if all these other languages have it? I have implemented langauges before, so this should just be a case of finding the correct implementation of the feature, and grafting it onto LRM’s code base, and then provide a patch to the mailing lists.

Since I knew LRM didn’t have scaling, I decided to investigate other languages that have it. I began with the original language, the one people write operating systems in. Obviously a language like Deep Throttle has scaling. So I started reading the books, looking through the syntax. But I couldn’t find anything there. What was I missing? Was there some obscure syntactic element that wasn’t documented, that provided scaling? Or was it hidden somewhere? Maybe the pointers were in reality another word for scaling? But no, it didn’t seem that way. I decided to break open GDPC, the Gnu Deep Throttle Compiler, and see if this scaling thing was actually something the compiler did autoamtically for you – a bit like register allocation. But I didn’t find any scaling allocation. There was lots of other neat stuff there, but all of it was quite mundane translations from the Deep Throttle code into machine code.

Feeling utterly dejected I turned my attention to Moulder. I assume that you all are familiar with the language – it’s used in many places around the world and provides lots of really advanced features such as garbage collection, a virtual machine, and yes – scaling! Of course, this is where it would be. Maybe Deep Throttle had hidden the feature somewhere obscure, but I was sure Moulder would make it easier to find. I started out with the syntax again, looking through the things you could do with the language. Interestingly, Moulder is a really small language, when you get down to it. It’s small but you need to say lots of things to get anything done. I couldn’t find the syntax for scaling, so I started entertaining other ideas. Maybe all those extra words “protected final static Foo” was actually necessary. Maybe the scaling happened in the spaces between the words, or in some strange interaction between them? The only way to find out was to crack open the compiler and look what was happening. In this case it was actually easier, because the compiler did even less than Deep Throttle’s compiler. Frankly, the Moulder compiler just output something bytecodes. There were no hidden scaling inlining in the Moulder compiler.

You see where this is heading? Right, I had to investigate the bytecodes that Moulder use. Where is that precious scaling bytecode? I assume it would be called something like invoke_scaling or maybe ldscaled. But nothing. There was no scaling bytecode. All of the existing bytecodes just did the same mundane things that I know LRM already can do. I was now feeling ready to give up, but I came up with one final idea. Scally is famous for being a language with scaling. It’s creators even named it after that feature. So if both Moulder and Scally has scaling, maybe it’s somewhere in Moulders gigantic standard library?

But guess what? I didn’t find it. I still haven’t found anyone who knows how you implement Scaling in a language, so I guess that LRM will never have it… Anyone who care to enlighten me, please send me a detailed email with an implementation of Scaling. I really feel the need to know how this thing works.

21 Comments | By Ola Bini | In: Uncategorized | tags: deranged, programming languages, scaling. | #

Today I spent some time connecting two languages that are finding themselves popular for solving wildly different kinds of problems. I decided I wanted to see how easy it was and if it was a workable solution if you would want to take advantage of the strengths of both languages. The result is really up to you. My 15 minutes experiment is what I’ll discuss here.

If you’d like, you can see this as a practical example of the sticky part where two languages meet, in language-oriented programming.

The languages under consideration is Ruby and Erlang. The prerequisite reading is this eminent article by my colleague Dennis Byrne: Integrating Java and Erlang.

The only important part is in fact the mathserver.erl code, which you can see here:

-module(mathserver).
-export([start/0, add/2]).

start() ->
Pid = spawn(fun() -> loop() end),
register(mathserver, Pid).

loop() ->
receive
  {From, {add, First, Second}} ->
      From ! {mathserver, First + Second},
      loop()
end.

add(First, Second) ->
mathserver ! {self(), {add, First, Second}},
receive
  {mathserver, Reply} -> Reply
end.

Follow Dennis’ instructions to compile this code and start the server in an Erlang console, and then leave it there.

Now, to use this service is really easy from Erlang. You can really just use the mathserver:add/2 operation directly or remotely. But doing it from another language, in this case Ruby is a little bit more complicated. I will make use of JRuby to solve the problem.

So, the client file for using this code will look like this:

require 'erlang'

Erlang::client("clientnode", "cookie") do |client_node|
server_node = Erlang::OtpPeer.new("servernode@127.0.0.1")
connection = client_node.connect(server_node)

connection.sendRPC("mathserver", "add", Erlang::list(Erlang::num(42), Erlang::num(1)))

sum = connection.receiveRPC

p sum.int_value
end

OK, I confess. There is no erlang.rb yet, so I made one. It includes some very small things that make the interfacing with erlang a bit easier. But it’s actually still quite straight forward what’s going on. We’re creating a named node with a specific cookie, connecting to the server node, and then using sendRPC and receiveRPC to do the actual operation. The missing code for the erlang.rb file should look something like this (I did the minimal amount here):

require 'java'
require '/opt/local/lib/erlang/lib/jinterface/priv/OtpErlang.jar'

module Erlang
import com.ericsson.otp.erlang.OtpSelf
import com.ericsson.otp.erlang.OtpPeer
import com.ericsson.otp.erlang.OtpErlangLong
import com.ericsson.otp.erlang.OtpErlangObject
import com.ericsson.otp.erlang.OtpErlangList
import com.ericsson.otp.erlang.OtpErlangTuple

class << self
def tuple(*args)
  OtpErlangTuple.new(args.to_java(OtpErlangObject))
end

def list(*args)
  OtpErlangList.new(args.to_java(OtpErlangObject))
end

def client(name, cookie)
  yield OtpSelf.new(name, cookie)
end

def num(value)
  OtpErlangLong.new(value)
end

def server(name, cookie)
  server = OtpSelf.new(name, cookie)
  server.publish_port

  while true
    yield server, server.accept
  end
end
end
end

As you can see, this is regular simple code to interface with a Java library. Note that you need to find where JInterface is located in your Erlang installation and point to that (and if you’re on MacOS X, the JInterface that comes with ports doesn’t work. Download and build a new one instead).

There are many things I could have done to make the api MUCH easier to use. For example, I might add some methods to OtpErlangPid, so you could do something like:

pid << [:call, :mathserver, :add, [1, 2]]

where the left arrows sends a message after transforming the arguments.

In fact, it would be exceedingly simple to make the JInterface API downright nice to use, getting the goodies of Erlang while retaining the Ruby language. And oh yeah, this could work on MRI too. There is an equivalent C library for interacting with Erlang, and there could either be a native extension for doing this, or you could just wire it up with DL.

If you read the erlang.rb code carefully, you might have noticed that there are several methods not in use currently. Say, why are they there?

Well, it just so happens that we don’t actually have to use any Erlang code in this example at all. We could just use the Erlang runtime system as a large messaging bus (with fault tolerance and error handling and all that jazz of course). Which means we can create a server too:

require 'erlang'

Erlang::server("servernode", "cookie") do |server, connection|
 terms = connection.receive
 arguments = terms.element_at(1).element_at(3)
 first = arguments.element_at(0)
 second = arguments.element_at(1)

 sum = first.long_value + second.long_value
 connection.send(connection.peer.node, Erlang::tuple(server.pid, Erlang::num(sum)))
end

The way I created the server method, it will accept connections and invoke the block for every time it accepts a connection. This connection is yielded to the block together with the actual node object representing the server. The reason the terms are a little bit convoluted is because the sendRPC call actually adds some things that we can just ignore in this case. But if we wanted, we could check the first atoms and do different operations based on these.

You can run the above code in server, and use the exact same math code if you want. For ease of testing, switch the name to servernode2 in both server and client, and then run them. You have just sent Erlang messages from Ruby to Ruby, passing along Java on the way.

Getting different languages working together doesn’t need to be hard at all. In fact, it can be downright easy to switch to another language for a few operations that doesn’t suit the current language that well. Try it out. You might be surprised.

3 Comments | By Ola Bini | In: Uncategorized | tags: erlang, java, jruby, polyglot, programming languages, ruby. | #

This post is basically a follow up to Language explorations. That post had several statements about what I believe, and some of them have been a bit misunderstood, so I’ll try to substantiate them a bit more here. Specifically, I want to talk about the viability of the Java language and whether “the stable layer” should be a static or dynamic language.

Lets begin with the stable layer. First, notice that I didn’t have any specific definitions for the different layers when I wrote the post. In fact, I think that they are inherently a bit fuzzy. That’s OK. DSL’s are also quite fuzzy. The attributes I put at the stable layer is first of all that it shouldn’t need to change much. In a smaller application, you can actually look at supporting structures as the stable layer, things like application servers or web servers. But for larger applications I find that you usually need your own stable kernel.

The reasons I choose static typing for stable layer is for several reasons. Performance is absolutely one of these, since everything will run on this base it’s an advantage if that part is as performant as possible. Secondly, I am no dynamic language, TDD purist that says that static typing is totally unnecessary. Static type checking can be very helpful, but it stops you from having a malleable language. So the kernel should be stable, this means that as much checking as possible is necessary. None of these requirements explicitly preclude a dynamic language, but the specific features of dynamic languages doesn’t really come to their rights at this level, and also leading to performance and static type checking suffering.

The more contentious part about my post seems to have been my off hand comment that I don’t believe Java is really good for anything. I didn’t give much reason in that post, and people have reacted in different ways, from saying that “Java is really good” to “Why are you involved in JRuby if you think Java is so bad?”. So lets start with why Java is a bad language. (I am only talking about the language here, not the platform). Also, that Java is a bad doesn’t say anything about the worse alternatives, so no comments along the lines of “if you think Java is so bad, why don’t you use X instead”.

In short:

• Java is extremely verbose. This is really a few different problems in one:
• No type inference
• Verbose generic type signatures
• Anonymous class implementations
• There is no way to create new kinds of abstractions:
• No closures
• Anonymous classes are a really clunky way to handle “block” functionality
• Broken generics implementation
• Language is becoming bloated

A few notes. That Java is becoming bloated is one of those things that people have been blogging about lately. After 1.5 came out, the complexity of the language got very much larger, without actually adding much punch for it. The improvements of generics were mostly negated by the verbosity of them. Fixing all the problems above will bloat the language even more. And at the same time, programming in Java is needlessly painful right now.

So, lets look at the question about why I’m working on JRuby. Well, first, I believe the JVM is a very good place to be at. It’s the best platform out there, in my opinion. The libraries are great, the runtime is awesome, and it’s available basically everywhere. The bytecodes of the JVM spec is good enough for most purposes. There is some tweaking that can be done (which we are looking at in JSR292), but mostly it’s a very nice place. And working on JRuby is really one of the ways I’ve seen how bad Java as a language is. We are employing several different tricks to get away from the worst parts of it, though. Code generation is used in several places. We are generating byte codes at runtime. We are using annotations to centralize handling of JRuby methods. And we are moving parts of the implementation to Ruby. I believe that JRuby is important because it can run in the same environment as Java, but without the problems of Java.

What are the solutions to the problem with Java? There are basically two different ways. Either define a subset of Java, not necessarily totally compatible, that takes the best parts of Java syntax, does away with the problems and so on. That should be possible, but I don’t know anyone who has done it. Or, you can go with an existing static language on the JVM. Here you have two choices – either one of the ports of existing extremely static languages (like ML or Haskell), or you can go with something like Scala. I haven’t decided on the best solution here yet. The only thing I’m sure of is that Java in itself is a problem. I’m investigating Scala, but maybe Scala isn’t the right answer either. We’ll see.

18 Comments | By Ola Bini | In: Uncategorized | tags: java, language design, programming languages, scala, static typing. | #

I blogged about looking at languages a while back. At that point I didn’t know what my next language to explore would be. I got lots of excellent suggestions. In the end I decided to try OCaML, but gave that up quickly when I found out that half of the type system exists to cover up deficiencies in the other half of it. So I went back and decided to learn Scala. I haven’t really had time to start with it though. Until now, that is.

So let’s get back to the motivation here? Why do I want to learn another language? Aren’t I happy with Ruby? Well, yes and no. But that’s not really the point. You can always point to the Prags one-language-a-year, but that’s not it either. I mean, it’s really good advice, but there is a more urgent reason for me to learn Scala.

I know many people have said this before, but it bears repeating. Everyone doesn’t share this opinion, but have a firm belief that the end of big languages is very close. There won’t be a next big language. There might be some that are more popular than others, but the way development will happen will be much more divided into using different languages in the same project, where the different languages are suited for different things. This is the whole Polyglot idea. And my take on it is this: the JVM is the best platform there is for Polyglot platform, and I think we will see three language layers emerge in larger applications. Now, the languages won’t necessarily be built on top of each other, but they will all run on the JVM.

The first layer is what I called the stable layer. It’s not a very large part of the application in terms of functionality. But it’s the part that everything else builds on top off, and is as such a very important part of it. This layer is the layer where static type safety will really help. Currently, Java is really the only choice for this layer. More about that later, though.

The second layer is the dynamic layer. This is where maybe half the application code resides. The language types here are predominantly dynamic, strongly typed languages running on the JVM, like JRuby, Rhino and Jython. This is also the layer where I have spent most of my time lately, with JRuby and so on. It’s a nice and productive place to be, and obviously, with my fascination for JVM languages, I believe that it’s the interplay between this layer and the stable layer that is really powerful.

The third layer is the domain layer. It should be implemented in DSL’s, one or many depending on the needs of the system. In most cases it’s probably enough to implement it as an internal DSL within the dynamic layer, and in those cases the second and third layer are not as easily distinguishable. But in some cases it’s warranted to have an external DSL that can be interacted with. A typical example might be something like a rules engine (like Drools).

I think I realized a long time ago that Java is not a good enough language to implement applications. So I came up with the idea that a dynamic language on top of Java might be enough. But I’m starting to see that Java is not good enough for the stable layer either. In fact, I’m not sure if Java the language is good enough for anything, anymore. So that’s what my language exploration is about. I have a suspicion that Scala might be a good language at the stable layer, but at this point the problem is there aren’t any other potential languages for that layer. So what I’m doing is trying to investigate if Scala is good enough for that.

But I need to make one thing clear – I don’t believe there will be a winner at any of these layers. In fact, I think it would be a clearly bad thing if any one language won at any layer. That means, I’m seeing a future where we have Jython and JRuby and Rhino and several other languages coexisting at the same layer. There doesn’t need to be any rivalry or language wars. Similarly, I see even less point in Scala and Ruby being viewed as competing. In my point of view they aren’t even on the same continent. And even if they were, I see no point in competing.

I got accused of being “religious” about languages yesterday. That was an interesting way of putting it, since I have always been incredibly motivated to see lots of languages coexisting, but coexisting on the JVM in a productive way.

20 Comments | By Ola Bini | In: Uncategorized | tags: future of programming, jruby, jvm, jython, programming languages, rhino, scala. | #

So, it’s that time of the year again. The restlessness flows over me. I feel cold and numb. And no, it’s not because I live in London – it’s because I need the warmth of learning a new language.

Now, I want something I can actually get into and learn. I’ve tried to get into OCaml, but I gotta admit I hate the type system. I have no problem with bondage static typed languages (Haskell’s type system is really nice, for example) but OCaml’s really feels like half of it exists just to cover up holes in the other half. There seems to be a large overlap in functionality, and lots of workarounds for handling things that should be simple.

I’m half way into Erlang, but for several reasons the language feels very primitive.

I’ve kinda thought about maybe getting serious with Scala. I like many of the language features, it’s a nicely designed language and so on. But – hear this, people – I would love to get away from the JVM for a while, just for the sake of it. I can do Scala later. I actually have a medium sized project lined up for my Scala learning. But not right now.

So, what do I want? Something I haven’t touched before. I would love something that involves radically new language features, if there are any left to discover. I have no need for it to be static or dynamic specifically. Doesn’t really matter. It would be fun if it’s new, but if it’s old, good and still in use in some sectors that would be fun too. Specifically something that’s not mainly run on the JVM or CLR. And of course, not any of the “mainstream” languages, who I actually tend to know fairly well (and yeah, to my sorrow that includes the whole W-family…).

Please help me! Give this December new meaning for me. I promise, if someone comes up with a nice language to try out, I’ll be very fair to it when I evaluate and learn it. =)

50 Comments | By Ola Bini | In: Uncategorized | tags: new language, programming languages. | #

Since the current world is moving away from languages in the classical imperative paradigm, it’s more and more important to understand the fundamental type differences between programming languages. I’ve seen over and over that this is still something people are confused by. This post won’t give you all you need – for that I recommend Programming Language Pragmatics by Michael L. Scott, a very good book.

Right now, I just wanted to minimize the confusion that abounds surrounding two ways of categorizing programming languages. Namely strong versus weak typing and dynamic versus static typing.

The first you need to know is that these two typings are independent of each other, meaning that there are four different types of languages.

First, strong vs weak: A strongly typed language is a language where a value always have the same type, and you need to apply explicit conversions to turn a value into another type. Java is a strongly typed language. Conversely, C is a weakly typed language.

Secondly, dynamic vs static: A static language can usually be recognized by the presence of a compiler. This is not the full story, though – there are compilers for Lisp and Smalltalk, which are dynamic. Static typing basically means that the type of every variable is known at compile time. This is usually handled by either static type declarations or type inference. This is why Scala is actually statically typed, but looks like a dynamic language in many cases. C, C++, Java and most mainstream languages are statically typed. Visual Basic, JavaScript, Lisp, Ruby, Smalltalk and most “scripting” languages are dynamically typed.

See, that’s not too hard, is it? So, when I say that Ruby is a strongly, dynamically typed language, you know what that means?

C is a actually an interesting beast to classify. It’s the only weakly, statically typed language I can think of right now. Anyone has any more examples?

To find out more, read the book above, or look up “Type systems” on Wikipedia.

5 Comments | By Ola Bini | In: Uncategorized | tags: programming languages, type inference, type systems. | #