Speaking on Lambda Jakarta: welcoming new Lambda Jakarta meetup member, new organizer, platform concern, and more

Lambda Jakarta meetup time! Now the meetup is themed “Casual Meetup”. This meetup is now located at Starbuck, at Tebet Green Mall on May 9, 2015.
The meetup is casual, as currently we didn’t have defined talks to be delivered but we have free topics (about programming language, of course) and still mainly focusing on functional programming.
For the detail on this meetup, visit the official event page: http://www.meetup.com/Lambda-Jakarta/events/222067797/

Agenda on this meetup is themed basically on these:

1. Announcement of new organizer, handled from Abdullah to Tino (a.k.a. “Kusut”)
2. Planning for the next meetup to have some presentations for next meetup. Again, I voluntarily for the next meetup

Without further ado, let’s welcome Kusut as the new organizer! Kusut has been around for more than 6 years in programming. Currently he has been fluent in Python, Ruby. For the last 2 years he began to dive into Haskell, with the help of Abdullah and Erik. By the way, Erik was one of the original founder of Lambda Jakarta meetup.

UPDATE 1: The original founder is Abdullah, Kusut and Asep. Thanks for clarifications, Erik :)

We welcomed new members: Rezha, Irvan and 2 more (sorry guys, I can’t remember your real names). Reza is still undergraduate student, with a passion to learn more than just OOP and procedural programming languages in his study! Irvan is still working at Traveloka as team leader and also software architect.
This is the picture:

The total of attendances was not so many, it was about 15 attendants. But we have so much fun discussing what happened in programming language world, and we agreed that we will touch more on platform.

After we introduced ourselves, we had topics to discuss. As always, I was happy to answer and discuss more on F#, .NET and platform relevance.

Platform (runtime platform) concern

Platform in this sense is platform in a sense of runtime platform, either .NET (and its Mono on Linux/UNIX) and Java. True that we as Lambdas love Haskell, but Haskell itself can’t be considered as true platform on its own. I shall focusing on the runtime virtualization platform on these two: .NET and Java.

Non runtime virtualization is usually native and closer to metal, like Win32, Bash, Csh, ObjectiveC, and many more (including DirectX, device driver).

A simple illustration about this native versus virtualized is:

Now you may wonder, why .NET/Mono apps (and hence Java) called managed? Because they have their own virtualization on top of the native OS runtime.
Therefore this bring these consequences:

1. Applications has their own shared virtualized runtime, often in some isolated fashion (in modern OS such as Windows Store Apps in Windows 8.0 and 8.1)
2. Memory, I/O, and other side effects are managed as abstracted from the underlying native OS. Often the virtualization provides some mechanism to access native OS API. Some example of this is the use of P/Invoke within .NET apps and JNI within Java.
3. These abstractions can add a little overhead to the performance, but this is by design. This also brings more room for innovations such as cross platforms (in a sense of running on other OS platform). We see in real world as Java and .NET/Mono, that runs on Windows and Linux/UNIX/MacOS.
4. When these virtualized apps run, not just in a managed environment but most of them are often well behaved as they often have a little knowledge of how they run in parallel according to the underlying OS. Therefore there are no simple or definite way to provide one-on-one performance profile on many OS. This is why (again) managed applications are mostly not geared for performance when compared against native applications.

Now that we understand why they are managed, it’s time to understand implications on the functional programming world. We know that Scala in Java and F# in .NET/Mono are the strong contender for the managed programming languages that also functional!

But then, at the core of those platforms, the virtualized platforms matter itself. The choice between Java or .NET is still not easy, as each platforms has their own advantages over the others.

Platform (runtime platform) choice

Why the choice of the runtime matters more? Because there’s no easy interoperability between the two major platform.

My own choice? The answer is complicated, but for those like me that already has enough manhours spent on these two, the clear winner (although it has its own disadvantages) is .NET.Let’s dive into the current states of Java as runtime.
Java 8, the latest incarnation of JDK, has these:

1. Generic support (using type erasure strategy) since JDK 1.4
2. wildcard for covariance/contravariance relaxation, but it’s still partial due to type erasure
3. rich type reflection through bean descriptor and class mechanism (explicit setter and getter)
4. No tail call support yet

.NET 4.5 has these:

1. Generic support using type reification strategy since .NET 2.0
2. support for STRUCT type (value type as .NET called it)
3. Iterator since .NET 2.0
4. Parallel support since .NET 4.0
5. Covariance/contravariance in generics
6. rich type reflection through inherent setter getter with properties
7. tail call

My main reasons in deciding that .NET is the winner are the type reification, STRUCT type, and the covariance/contravariance support. There are also minor comparing factor such as Lambda statements in Java, but this is not a true comparison as Lambda is truly language feature, not runtime feature.

 

Curious about type erasure? Read this from the official source: https://docs.oracle.com/javase/tutorial/java/generics/erasure.html

But for me, the most decisive factor is the use of type erasure in Java. It’s quite annoying because the type information can’t be ensured at runtime! This is the big issue in Java that is a big disadvantages compared to .NET. It’s also a wrong decision at start, for the sake of compatibility.
This matter of type erasure choice has its own backup supporters, such as this guy in a blog post for example. But still in that article, he also mentioned that it’s still a wrong decision.
Further implications? Many! The nature of functional programming languages are strong type everywhere, including generic supports. This weak generic support of Java can make even Scala losing its backers in long run as it doesn’t fit for strong functional programming runtime.
Hey, I’m not Java haters! I’m still a polyglot developers, and I still have high hope for Java. For Java 9, there will be a support for STRUCT type, and Java 9 will be the starting point to support type reification, by paving the way for STRUCT.
This means that we’ll see type reification after Java 9. But the exact release will be further decided by the community and Oracle. Don’t be excited first, guys.

What about Haskell?

Unfortunately there’s no definite answer about this. We still don’t know yet about mature support of Haskell in Java or .NET. There is GHC for .NET, but this support is still far from mature and stable although it was developed by Simon Peyton Jones, the same guy developed GHC.
My big intelligent guess is: there’s no direct support for type classes in the runtime, and it’s also quite hard to implement pure functional language boiled into the managed runtime. Try implementing Haskell’s IO monad using the managed runtime, for example. You will find it quite hard even for long time .NET developers.
That’s it, folks! Can’t wait to attend the next Lambda meetups!