Subscribe to Jack of all Languages        RSS Feed

Shaking up the Industry with Scala

Icon 3 Comments
There is soon to be a big change wrought on the programming community, and it is going to be driven by hardware. Processor speed is about as fast as it can be with current technology. To satisfy the need for speed, manufacturers are combining several chips into parallel processors. Multicore is the future and that means concurrent programming.

Concurrent programming is fraught with pitfalls in imperative languages. The root cause is shared state. When two threads modify the same data at the same time, the results are unpredictable. As soon as you enforce immutability, shared state is no longer a problem and concurrent programming becomes a lot easier.

It's not practical to eliminate mutable state from programs written in imperative languages. Changing the values of variables is too fundamental a concept to these languages. Functional languages, on the other hand, have very little mutable state. Almost everything is immutable and this makes them a natural choice for concurrent programming.

I'm reading Seven Languages in Seven Weeks by Bruce Tate. This week was the Scala chapter. Tate predicts the industry is about to enter a transition phase to functional programming and argues that Scala is perfectly positioned to introduce today's programmers to functional concepts.

Scala looks like an incredibly pragmatic language. It targets Java developers (of whom there are a lot) by being built on top of Java. It compiles to bytecode, runs on the JVM and has access to the Java API. Scala fixes some common gripes with Java. The syntax feels familiar but is more concise. It supports operator overloading and type inference. Concurrent code is made easier with Actors. Scala takes the pain out of using regex and has literals and a query language for XML.

From the functional programming side, immutable state is encouraged (but not enforced) and there is good support for recursion, closures, currying and pattern matching. Scala lets you mix functional and imperative paradigms. For most Java programmers, that means mostly sticking to the familiar imperative OO style with the option of throwing in some functional parts when it suits.

Tate argues that this mix of OO and functional programming makes Scala strongly positioned as a transition language. He could be right but other OO languages are gradually incorporating more and more functional features. If this trend continues, I think Java and C# could end up being the transition languages.

Whatever the case, I Scala seems to be a language I would enjoy working in. The language seems to have everything I could want and it would be easy to transition to from my Java background. However, for some reason I can't put my finger on I just can't seem to get excited about Scala. For now I think I'll file it alongside C# as a language I'll learn on the job the first time I need to use it.

3 Comments On This Entry

Page 1 of 1


13 October 2014 - 07:11 AM
I am not certain about moving into a transition to a functional language. If anything the transition is going to shift from desktops to mobile which knocks out the hardcore/multi core problem. :^:


14 October 2014 - 12:32 AM
Well, my mobile has a quad core processor. Hardly massively multicore but I can see mobiles heading in that direction even if it lags behind desktops and servers. I'm sure you are right that mobile will become more important relative to desktops but a lot of busibesses will still need desktops and servers, as will many home users.


20 October 2014 - 10:49 AM
Mobile is certainly a trend, but large streams of realtime data are huge and functional and/or reactive models shine on the server side. Servers won't be going away for a while. Scala is a good "now" language for dealing with this stuff.
Page 1 of 1

Trackbacks for this entry [ Trackback URL ]

There are no Trackbacks for this entry

May 2022

2223 24 25262728


    Recent Entries

    Recent Comments

    Search My Blog

    0 user(s) viewing

    0 Guests
    0 member(s)
    0 anonymous member(s)