Scala vs. F#: Comparing Functional Programming Features —

Posted by: Lava Kafle

Immutability Fosters Concurrent Programming

Sharing Is Cheap

If you’re certain that an object will never change, then sharing this object becomes a simple matter of providing a reference to it. In Java doing so often requires a lot of defensive copying. Along this vein, because we can freely share references for immutable objects, we can likewise intern them for free.

Flattening the Levels of Indirection

There’s a marked difference between a mutable object and a mutable reference. The default in Java is that there are mutable references that contain mutable data. But in Clojure there are only mutable references. This may seem like a minor detail, but it certainly works to reduce unnecessary complexities. Why else is there a proliferation of final in next-generation Java programming styles?

Equality Has Meaning

Equality in the presence of mutability has no meaning. Equality in the face of mutability and concurrency is utter lunacy. That is, if any two objects resolve as being equal now, then there’s no guarantee that they will a moment from now. And if two objects aren’t equal forever, then they’re technically never equal (For more information about these statements, see Henry Baker’s essay “Equal Rights for Functional Objects or, The More Things Change, The More They’re the Same.”). Providing immutable objects once again assigns meaning to equality in that if two objects are equal now, then they will always be so.

In a concurrency-oriented programming language like Clojure, the primary benefit of immutability is that the core types can be shared freely among separate threads without fear. In the next section we’ll discuss this particular benefit in more detail.

F# vs. Scala: Lazy Evaluation

F# supports lazy evaluation, but for performance reasons it is not enabled by default. Instead, F# supports so-called eager evaluation: functions can be marked for lazy evaluation by explicitly labeling them with the keyword lazy and running the program with the Lazy.force option specified.

let lazyMultiply = lazy ( let multiply = 4 * 4 )

Like F#, Scala is not lazy by default, but unlike F#, values — not functions –have to be marked with the keyword lazy and therefore evaluated as call-by-need.

def lazyMultiply(x: => y:) = { lazy val y = x * x }

F# vs. Scala: Lambda Expressions and Currying

via Scala vs. F#: Comparing Functional Programming Features —

Scala vs. F#: Comparing Functional Programming Features — was last modified: February 12th, 2015 by Lava Kafle

Blog Comments

  1. Lava Kafle Post author

    Separation of concerns is crucial to the design of the Internet. In the Internet Protocol Suite great efforts have been made to separate concerns into well-defined layers. This allows protocol designers to focus on the concerns in one layer, and ignore the other layers. The Application Layer protocol SMTP, for example, is concerned about all the details of conducting an email session over a reliable transport service (usually TCP), but not the least concerned about how the transport service makes that service reliable. Similarly, TCP is not concerned about the routing of data packets, which is handled at the Internet Layer.
    WikiPedia thanks

  2. separation of concerns (SoC)

    In computer science, separation of concerns (SoC) is the process of breaking a program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program.

    SoC is a long standing idea that simply means a large problem is easier to manage if it can be broken down into pieces; particularly so if the solutions to the sub-problems can be combined to form a solution to the large problem.
    The term separation of concerns was probably coined by Edsger W. Dijkstra in his paper On the role of scientific thought.

  3. Are Oracle unlimited license agreements really unlimited?

    “That was an example of where the clients didn’t truly have an unlimited license,” he said.
    Colon said Oracle started offering its biggest 100 clients unlimited license agreements about six years ago. One of the early adopters was the federal government. Steven Pavick, a chief systems engineer for the Air Force Logistics Transformation Office, said they operate under ULAs because of the more than 250,000 anticipated users over the life of the agreement. He said they went with ULAs four years ago as part of the government’s acquisition strategy.

    But over the last couple of years, Oracle started opening up the offer to its next 1,000 or so largest companies. Colon said the agreements are best for companies that expect growth through normal business operations rather than through mergers and acquisitions.

    Why is that? Because, depending on the language of the terms, the unlimited license agreement won’t apply. Oracle shops might encounter problems after signing the agreement because they didn’t notice some restrictions in the contract, or the wording wasn’t precise enough. As a result, ULAs might not apply for external users of Oracle products. For example, Jones said he worked with one North American public utility that ran into that very issue — who could use the software. It was for internal use only.

  4. Java Concurrency in Practice, by Brian Goetz,

    There’s nothing magical about immutable objects. Computer systems are in many ways open systems, providing the keys to the vault if one is so inclined to grab them. But in order to foster an air of immutability in our own systems, it’s of utmost importance to create a facade of immutability. Immutability requires that we layer over and abstract the parts of our system that provide unrestrained mutability. For example, creating immutable classes in Java requires us to do this in a number of ways (See Java Concurrency in Practice, by Brian Goetz, for more details). First, a class itself and all of its fields should be labeled as final. Next, in no way should an object’s this reference escape during construction. And finally, any internal mutable objects should originate, either whole cloth or through a copy, within the class itself and never escape. Obviously, we’re simplifying in order to illustrate because there are finer details to this recipe for Java immutability, but for now these simplified highlights serve to show that by observing convention, even an inherently mutable language such as Java can be made immutable. In languages like Java, immutability isn’t directly supported and requires some gymnastics in order to achieve, although Clojure directly supports immutability as a language feature with its core data structures (We’re intentionally glossing over Clojure’s features that support mutability, such as reference types and transients, in order to keep this section focused.). By providing immutable data structures as a primary language feature, Clojure separates the complexity of working with immutable structures from the complexities of their implementation (Reginald Braithwaite discusses this language-level separation of concerns in his excellent blog post “Why Why Functional Programming Matters Matters”).

Post Your Comments:

Your email address will not be published. Required fields are marked *