Rafael Naufal's blog

Communicating my thoughts on software development

Posts Tagged scala

JDK7 Tackles Java Verbosity

Sep 22

Posted by rnaufal in Uncategorized | 2 Comments

Interesting article showing some changes on the Java platform to address its verbosity, but keeping code readability safe.
I liked the new Collection’s literals syntax to create lists, sets and maps:

List powersOf2 = {1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024};
Map ages = {"John" : 35, "Mary" : 28, "Steve" : 42};

Although it can be possible to use the DoubleBraceInitialization idiom to initialize collections in a more elegant way, this syntax is very terse and concise.

BTW, as I said before, Scala already has a syntactic sugar to create a literal Map:

val ages = Map("John" -> 35, "Mary" -> 28, "Steve" -> 42)

Maybe this change was taken into account considering the Scala collection literals implementation?

Tags: , , , , , , ,

Constructors in Scala

Aug 26

Posted by rnaufal in Uncategorized | No Comments

I just came across an interesting post by Stephan Schmidt about constructors in Scala.

It shows how to create constructors with immutable and mutable fields, how to have multiple constructors how to invoke super class constructors. I found it very handy and concise to create a constructor with a private immutable field:

class Foo(private val bar: Bar)

Tags: ,

Using Scala to update LiveJournal tags – Part I

May 23

Posted by rnaufal in Uncategorized | 7 Comments

Some days ago I started to use the Scala programming language to update my Livejournal tags using its XML-RPC protocol reference. First I had to check if some tags of mine were entered wrong, so I’ve done this Scala program to list all of them:

   1:import org.apache.xmlrpc.client.XmlRpcClient;
   2:import org.apache.xmlrpc.client.XmlRpcClientConfigImpl;
   3:import org.apache.xmlrpc.client.XmlRpcCommonsTransportFactory;
   4:import java.net.URL;
   5:import java.util.Map
   6:import java.util.HashMap
   7:import scala.collection.immutable.TreeSet
   8:
   9:object LJListTag {
  10:     def main(args: Array[String]) {
  11:         val config = new XmlRpcClientConfigImpl()
  12:         config.setEnabledForExtensions(true);
  13:         config.setServerURL(new URL("http://www.livejournal.com/interface/xmlrpc"))
  14:         val client = new XmlRpcClient()
  15:         client.setConfig(config)
  16:         val params = new HashMap[String, String]
  17:         params.put("username", "user")
  18:         params.put("password", "password")
  19:         var paramsToServer = new Array[Object](1)
  20:         paramsToServer(0) = params
  21:         val results = client.execute("LJ.XMLRPC.getusertags", paramsToServer).asInstanceOf[Map[String, String]];
  22:         printEachTag(results)
  23:     }
  24:    
  25:     def printEachTag(results: Map[String, String]) {
  26:        var allTags = new TreeSet[String]
  27:        val iterator = results.values().iterator()
  28:           while(iterator.hasNext()) {
  29:             val resultFromRPCData = iterator.next().asInstanceOf[Array[Any]]
  30:             resultFromRPCData.foreach(singleResult => allTags += extractTag(singleResult))
  31:           }
  32:        allTags.foreach(tag => println(tag))
  33:     }
  34:    
  35:    def extractTag(singleResult: Any): String = {
  36:        val tag = singleResult.asInstanceOf[HashMap[String, String]]
  37:        return tag.get("name")
  38:    }
  39:}

Just fill your user and password to have all of your LiveJournal tags printed on the standard output. The experience was so amazing, since you can use all the Java libraries (Scala is fully interoperable with Java and runs on top of the JVM). I used a TreeSet because I wanted print my tags sorted according its alphabetical order. I’m continuously studying Scala and its API, so the code above doesn’t use any advanced Scala constructs. If you have any suggestion about the code or how to use better the Scala constructs, post your comments here. It will be all appreciated.

Tags: , , , , ,

Twitter on Scala Interview

Apr 27

Posted by rnaufal in Uncategorized | 4 Comments

There is a nice interview with the Twitter development team on Artima about using Scala in production on Twitter code. The team talks about some issues and facilities regarding the chose of Scala to develop Twitter’s queueing system and how Scala affected the team’s programming style.

My personal highlights:

And Ruby, like many scripting languages, has trouble being an environment for long lived processes. But the JVM is very good at that, because it’s been optimized for that over the last ten years..

So Scala provides a basis for writing long-lived servers…Another thing we really like about Scala is static typing that’s not painful. Sometimes it would be really nice in Ruby to say things like, here’s an optional type annotation

And because Ruby’s garbage collector is not quite as good as Java’s, each process uses up a lot of memory. We can’t really run very many Ruby daemon processes on a single machine without consuming large amounts of memory

In some cases we just decided to burrow down and use the Java collections from Scala, which is a nice advantage of Scala, that we have that option..

As I’ve learned more Scala I’ve started thinking more functionally than I did before. When I first started I would use the for expression, which is very much like Python’s. Now more often I find myself invoking map or foreach directly on iterators..

The reason you should care about immutability is that if you’re using threads and your objects are immutable, you don’t have to worry about things changing underneath you..

It’s very worth read. Post your comments here when you read it.

Tags: , , , ,

Is Java on a evolutionary dead end way?

Jan 11

Posted by rnaufal in Uncategorized | No Comments

Artima is running an article where Bruce Eckel talks about about Java’s objective on backwards compatibilities and the problem of combinatorial complexity when you combine a new feature in every possible way with the other language features already present.

It’s the combinatorial complexity that you get when you combine a new feature in every possible way with the other language features. The combinatorial complexity can produce horrifying surprises, typically after the feature is added when it’s too late to do anything about it.

It’s clear Eckel is mentioning the Java closures’ proposals to become part of the language on the Java 7 and the major improvements occured when Java 5 appeared.

If Java is unwilling to break backwards compatibility, then it is inevitable that it will acquire both unproductive complexity and incomplete implementation of new features. I’ve made the case in Thinking in Java 4e that Java Generics are only a pale imitation of real generics, and one of the more appealing suggestions for closures is an incomplete implementation of true closures, but it would actually be preferable to a complete implementation because it produces clearer, more straightforward code.

I particularly agree with him, when he also says

Fundamental new features should be expressed in new languages, carefully designed as part of the ecosystem of a language, rather thanbeing inserted as an afterthought.

He also considers Scala as an alternative for the Java language. Eckel also declares

Java values backward compatibility over the clarity of its abstractions.

I don’t agree with him at this later point, the Collections’ framework is an example of good API design rules with a lot of well designed abstractions by Joshua Block, separating things that change from things that stay the same.

And you? What do u think about it? Should Scala be considered as an exit for Java?

Tags: , , , ,