Showing posts with label scala. Show all posts
Showing posts with label scala. Show all posts

Saturday, December 19, 2020

Deep Learning From Java and Scala

Deep learning has been dominated by Python for years. It has been much harder to do deep learning on the JVM, but recently there has been some improvements. Here is a brief comparison of popular options going into 2021.

  • Deeplearning4j
  • DJL, Deep Java Library
  • MXLib Java and Scala bindings
  • PyTorch Java bindings
  • TensorFlow Java bindings
  • TensorFlow Scala

Bindings and Portability

Python is great for data exploration and for building models. Direct JVM access to deep learning is great for development and deployment to servers or Spark. It is easier than setting up a Python micro service.

Only Deeplearning4j is native to JVM, the others are wrappers to C++ code. Java binding to C++ or Fortran code is less portable than normal Java code. A big issue with these libraries is how well they package up the C++ library for use from Java. Do they have pre-compiled jar files for your platform, or do you need to run install scripts? Are these install scripts well documented and maintained.


Deeplearning4j

GitHub Stars: 12k

Deeplearning4j is the only native Java deep learning library, giving it a concept and portability advantage. It is a little verbose as Java often is.

Active and popular but less popular than the domineering PyTorch and TensorFlow.


DJL, Deep Java Library

Sponsor: Amazon

GitHub Stars: 1.5k

DJL is a new and very active. It wraps other libraries MXLib, ONNX, PyTorch and TensorFlow. It has good documentation.

DJL has a very high abstraction level. DJL can load models from a model zoo from different underlying libraries. If you just want to take some trained model and run it in production, you can pick and choose models written for different libraries from the same code. 

On the other hand, if you are training your model, then having an extra abstraction layer around classes makes it harder to build and train a model.

DJL object detection using model zoo


MXLib Java and Scala Bindings

Sponsors: Amazon and Microsoft

GitHub Stars: 19k

MXLib supports a lot of languages and there is good documentation for each of them.

Active and popular but less popular than the domineering PyTorch and TensorFlow.

 

PyTorch Java Bindings

Sponsor: Facebook

GitHub Stars: 50k

PyTorch is the second most popular deep learning framework. It has changed less than TensorFlow. It represents models as a dynamic computation graph, which is easy to program especially for complex dynamic models.

PyTorch Java bindings is part of PyTorch, the install is platform specific and requires several steps. It has an example project, but doesn't seem very active. There is quite a bit of documentation about Android Java development.


TensorFlow Java Bindings

Sponsor: Google

GitHub Stars: 152k

TensorFlow is the most popular deep learning framework with a giant ecosystem. TensorFlow v1.x had a steep learning curve. It has gone through many changes, making it a moving target for Python / Java programmers.

TensorFlow Java is part of TensorFlow project. It has dependencies for Linux, macOS and Windows packaged up in jar file and installs cleanly on those platforms. It is unclear how popular it is; a lot of the documentation is referring to legacy Java bindings and there is little documentation about new Java bindings, that only has 0.2k GitHub stars.

Understanding TensorFlow's architecture with graphs and sessions is important for Java bindings. Here is a lecture explaining it.



TensorFlow Scala 

GitHub Stars: 0.8k

TensorFlow Scala is a low-level idiomatic wrapper around TensorFlow. It has a lot of high-quality Scala code and is actively developed. 

TensorFlow represents its computation graph with Protobuf. This makes it more language agnostic.  TensorFlow Scala has idiomatic abstraction around that.

TensorFlow Scala code is keeping up with TensorFlow version. There are precompiled binary jar files for Linux, Mac and Windows. Documentation is sparse so be prepared to read source code.


Conclusion

There have been big improvements to deep learning from JVM languages like Java, Kotlin and Scala, but the quality is substantially below C++ / Python versions. The documentation is still spotty, and bindings are often behind C++ / Python libraries. But the binding should be good enough to run ML in production code.


Test / Starter Projects

Here are the Scala test projects I used to check if the bindings were working and cross platform. It took some experimenting to get these to work.


DJL, Deep Java Library

https://github.com/sami-badawi/scaladl

Object detection calling TensorFlow model zoo threw exception.


PyTorch Java bindings

https://github.com/sami-badawi/java-demo


TensorFlow Java bindings

https://github.com/sami-badawi/tensorzoo

Java bindings are using Java generics that are pretty different from Scala generics.


TensorFlow Scala

https://github.com/sami-badawi/tf_scala_ex


Disclaimer

Apologies for omissions and open to corrections.

 

 


Saturday, February 22, 2020

Haskell and Hadoop the Aftermath

In 2012 Haskell and Hadoop were the hottest technologies. They had a lot of hype and I loved them. Both were based on functional programming and built on towering abstractions.

Elite functional programmers used Haskell. Serious tech startups had to use big data, meaning Hadoop. Three years later I had learned Haskell and Hadoop and my top advice to startups was:

Don't use Haskell or Hadoop!

They won't you give you a competitive advantage they will just slow you down.

That was my personal experience. For years after that I avoided jobs involving Hadoop, but for the last couple of years I have mainly been working in Hadoop with Spark. It's now solid and very productive.

I found the productivity increase quite remarkable. Some of it is a textbook example of technology life-cycle, but a some of it comes down to understanding the power and limitation of functional programming.


Modern Programming Paradigms


There are three main modern programming paradigms:
  • Object oriented
  • Functional
  • Declarative

Object oriented programming gives you fine-grained control. Functional programming uses transformations with less control. In declarative programming you just write queries and you have little control. The higher the abstraction the less control.


Essential Hadoop



The breakthrough that Hadoop / MapReduce made was that by using functional programming transformation you could distribute a computation over thousands of computers in a fault tolerant way. This was a monumental achievement, but what made Hadoop the dominant data platform it is today was that it later combined functional with the declarative programming available in Spark SQL, HIVE or PIG.

Combined functional and declarative programming was once the holy grail in computing, but nobody knew how to do it. Today it is ubiquitous and it is free, until you get the bill from your cloud provider.



Essential Haskell



I expected Haskell to be a mathematical version of Python. It was not. If you are trying to do object oriented programming in Haskell it will cause you a lot of pain. Unlike doing OOP in hybrid languages like F#, OCaml or Scala.

The power of Haskell is that it limits you to a small set of basic operations that compose. This allows you to build a big machine out of simple parts. The lazy evaluation makes it natural to work on infinite streams of data. The powerful type system makes it possible to connect small pieces of code in many different dimensions. My metaphor is:

Haskell is an extra dimensional Lego set

Haskell started as a playground for language researchers experimenting. I wanted to play with all these shiny theoretical toys. That was a big time sink and a part of the reason it took me a long time to learn.


Common Problems


One reason I gave up on both Haskell and Hadoop was that it was hard to get things done. Both were beautiful abstractions built on a tower of unstable software libraries. Everything was evolving quickly. This made it hard to keep the libraries underneath on compatible version. Every time your Hadoop distribution was updated your code would break.

In Haskell this problem was called Cabal Hell after the build system Cabal. There were simple solutions. Haskell now has stable versions of libraries that work with each other. It has a modern build system called Stack. Now tooling in both Haskell and Hadoop is quite good.


The Aftermath


I spent more time and effort learning Haskell and Hadoop than any other technologies. With that much effort I expected them to give me superpowers. Instead they slowed me down. This caused a backlash. I felt naive for jumping on the Haskell and Hadoop bandwagon and wasting so much time.

Now 8 years later the dust has settled and part of my problem was that I was an early adapter of immature technologies. Haskell and Hadoop are now mature but inherently complex technologies. They draw their power from giving up fine control. Instead they let you build machines that you can pipe data through.

Big data in the case of Hadoop. Infinite data in the case of Haskell.

Hadoop is highly successful, and is now a cornerstone of data engineering. Even though it is currently standing in the shadow of Spark that was built to run on top of Hadoop infrastructure.

Haskell is a practical programming language well suited for constructive mathematics and category theory, but it is not a better version of Scala. It is pretty successful at number 19 on RedMonk programming language ranking and is used in industry.


Monday, October 21, 2019

F# vs Scala

F# and Scala are both hybrid functional object-oriented languages created for popular virtual machines.

  • F# for CLR / .NET
  • Scala for JVM / Java


F# and Scala are now in more direct competition after Microsoft open sourced F# and .NET Core. They have many similarities but a distinctly different feel. It was hard for me to put my finger on the difference. This blog post investigates their design decisions and use cases. Starting with a brief overview of F# and Scala.


F# (F Sharp)


F Sharp


F# is a mature, open source, cross-platform, functional-first programming language. It was created by Don Syme in 2005 as a port of the OCaml language to .NET.
  • Core: Strict, strong, inferred, hybrid
  • Popularity: Some use in industry and backed by Microsoft
  • Complexity: Easy to learn, but part of a big ecosystem
  • Maturity: It is 14 years old and part of the .NET, so quite mature
  • Tooling: Very good, both .NET based and F# specialized
  • Cross platform: with Mono and .NET Core and JavaScript
  • IDE: Visual Studio, VS Code


Scala


Scala

Scala combines object-oriented and functional programming in one concise, high-level language. It was created by Martin Odersky in 2004.

  • Core: Strict and lazy, nominal and structural, hybrid, implicit for IoC
  • Popularity: Very popular. No 13 on Red Monk June 2019 list. Spark is written in Scala
  • Complexity: It is a quite complex language, but it is easy to get started with
  • Maturity: Very stable. Run on JVM, well integrated with JVM ecosystem
  • Tooling: Great build tool and package managers
  • Cross platform: JVM and JS. Also early work on native / LLVM version
  • IDE: IntelliJ, VS Code, Eclipse


Microsoft Open Source Bet


Choosing between F# and Scala used to be pretty easy. If you were doing Windows development you would use F# if you were on an open source stack you would choose Scala.

In 2012 Microsoft open sourced F# and started porting it to Mono a Microsoft supported cross platform version of the CLR. That was cool but not something I would run production code on.

However, in September 2019 Microsoft released .NET Core 3 an open source cross platform version of a big part of their SDK and also a first release of Apache Spark for .NET.

After this .NET and F# are serious contenders for being parts of an open source stack.


Relation to Java and C#


You might think that F# is just the .NET version of Scala and moving from Java to Scala is similar to moving from C# to F#. This is not the case.

Java was a small and simple language with a lot of innovations but some annoying problems. A big part of Scala appeal was that it was a better Java with more features.

C# was also made to be a better Java. It fixed some of the flaws in the original Java, e.g. auto boxing of integers, generics and lambdas. C# is a great but also very big language. F# is more like a leaner version of C#, with less features.


Collection Libraries


Scala has made a big effort to make a full set of immutable and mutable Scala collections and make different Java collections look like they are native Scala collections.

I tried Scala in 2007 it had generic and could use Java generic, but either you were programming in Java or in Scala. This took a long time to get this right and cost was that the standard library code was very complicated. This is not really a problem for the user who won't see this.

Generally, F# is using a few collections: Arrays, lists, seq, set and map.
It is a bit messy to bridge the OCaml and the C# heritage, especially map / dictionaries are clumsy.


Monads


A monad is an important part of functional programming. It is a general principle to express a sequence of operations and work on a lot of different data types:
List, Seq, Future, Option.

Scala monadic for comprehension



Scala's version is syntactic sugar over flatMap(). It is more flexible, it can mix two types of monads say List and Option. Scala's monad will also return the same type as the input type.

F# monadic for comprehension



F#'s version of the monad computation is called computational expression. It has more features than Scala's.



Classes


Classes are considered an anti-pattern by functional programming purist. Some problems with classes are:

  • A class maintains state
  • A class creates a custom language instead of reuse of operations
  • Inheritance is crating tight coupling

Scala has a very sophisticated type and class system and classes are central part of Scala.

F# has support for classes, but it is billing itself as object programming not object-oriented programming. It is made to use classes defined in C#, but will often define objects with methods without a full class definition.

I like that F# is exploring more lightweight alternatives but classes are easy to create and feels natural to use.


Type Classes, IoC, DI, Type Providers


Type class is a powerful abstraction that can make a third party class implement an interface. It plays an important role in Scala and are implemented with helper classes created by implicit.

Inversion of control and dependency injection, are first class in Scala with implicit. This is an advanced but very useful feature of Scala.

Scala has developed these ideas to the point where you can do logic style programming with implicit. A lot of the more sophisticated category theory like programming is based on this.


You can do inversion of control and dependency injection in F# using libraries.

F# has type providers that on the fly generated typed access to a lot of different data sources, e.g. a table on a webpage.


Design Decisions


F# is white space indentation-based language. Scala is a curly bracket language.

F# is a lightweight language with strong compose-ability.

Scala has sophisticated type system, including type classes, this unifies a lot of different classes and facilitating reuse.

F# program feel a little more like a loose collection of definitions while Scala program feels more like a carefully packaged system.


Conclusion


F# and Scala have a lot in common. To a large extent you would still chose F# or Scala based on your platform choice.

Both languages are very well suited for building back end programs that can interact with a universe of libraries written in C# or Java.

Scala has more momentum and a better niche. It is still having status as a better Java. Even after Java added some of the best constructs from Scala. Spark has made Scala a corner stone of data engineering.

F# is more lightweight than Scala. This makes it great for data exploration and great for building small scripts. It still remains to be seen how well supported Spark is going to be for .NET.

From a language evolution perspective, the object functional hybrid has been very successful. F# and Scala's different emphasis has produced different language from similar goals. I am very happy that we now can compare their design decisions on merit not just compare .NET and Java ecosystems.

This article is an elaboration on my last blog post Typed Functional Languages 2019.
Disclaimer I have been a happy Scala user for years, and only occasionally use F#.

Wednesday, September 11, 2019

Typed Functional Languages 2019

This post is a brief status of the state of typed functional languages in late 2019.

Typed functional languages like Clean, Haskell and OCaml were developed within academia in the 1990s. Around 2010, languages like F# and Scala were gaining some acceptance in industry. Today there are many great typed functional languages, several used in industry. I will give a brief side by side introduction to the following languages:

  • F#
  • F*
  • Haskell
  • OCaml
  • Rust
  • Scala
  • TypeStript
Concepts from typed functional languages have also spread into object oriented languages like C++, C# and Java. The distinction between OOP and typed functional is fluid, so that list might seem a little arbitrary.

These languages are best of breed so the point of this article is not to compare them by merits, but to explore what language to use for what purpose. Follow up post covers F# vs Scala.


F# (F Sharp)


F Sharp


F# is a mature, open source, cross-platform, functional-first programming language. 
  • Core: Strict, strong, inferred, hybrid
  • Popularity: Some use in industry and backed by Microsoft
  • Complexity: Easy to learn, but part of a big ecosystem
  • Maturity: It is 14 years old and part of the .NET, so quite mature
  • Tooling: Very good
  • Cross platform: with Mono and .NET Core and JavaScript
  • IDE: Visual Studio, VS Code

Strengths

Simple, open source, cross platform with good integration with the whole .NET universe.
Well suited for backend programming, Azure, web-serving and finance.
Type providers give easy typed access to a lot of different data sources.

Issues

IDE, GUI programming and LINQ is not as well developed as for C#.


F* (F Star)


F Star

F* is a general-purpose functional programming language with effects aimed at program verification.

  • Core: Strict, dependently typed, tactical theorem prover, constraint solver, refinement type, algebraic effect tracking
  • Popularity: Research language with very few users
  • Complexity: Quite complex
  • Maturity: Several researchers are working on it, but it is not used a lot
  • Tooling: Not super polished, but build on top of good tooling in OCaml and F#
  • Cross platform: OCaml, F#, C, WASM and ASM
  • IDE: Support for Emacs

Strengths

F* has implemented a lot of powerful and interesting ideas that you can try and actually use. It is a very well developed dependently typed language.
Good for validating highly sensitive security programs, encryption protocols.

Issues

There is little adaptation and it has not stood the test of time yet.


Haskell


Haskell

Haskell is an advanced purely-functional programming language.
  • Core: Lazy, pure, effect tracking using effect monads
  • Popularity: Prestigious research language with some industry adoption. Number 19 on Red Monk June 2019 list
  • Complexity: Very complex language
  • Maturity: It has been around for 30 years, used in industry, used for research
  • Tooling: New build tool Stack is quite nice
  • Cross platform: Runs on OS X, Linux and Windows
  • IDE: Several decent plugins for: VSCode, emacs, Spacemacs, SpaceVim and IntelliJ

Strengths

Very influential research language, test bed for a lot of language research and development.
It has been optimized for years and has some use in industry.
Type classes are built into the language so you can reuse code very broadly.
Aesthetically pleasing if you love math or category theory.

Issues

It is a very complex language and tracking effect in non pure computations is quite hard.
It has some use in industry, but is still very much a research language.


OCaml



 OCaml is a strictly evaluated functional language with some imperative features.
  • Core: Strict, strong, inferred, hybrid
  • Popularity: Used as teaching language and by a few big companies
  • Complexity: It is a simple language to learn
  • Maturity: It has been around for 20 years and is used in industry so quite mature
  • Tooling: Recently it got a good build tool and package manager
  • Cross platform: Runs on a lot of different operating system, hardware
  • IDE: Language server with good integration with Eclipse, VS Code, Emacs and Vim

Strengths

Great REBL, very fast compiler, makes it suited for tooling. Facebook using it for web tooling.
Popular in theorem provers.

Issues

Concurrency is not great.


Rust


Rust
TM Mozilla

Rust is a multi-paradigm system programming language focused on safety, especially safe concurrency.
  • Core: Inferred, linear type, nominal, static, strict, strong, build around concurrency
  • Popularity: Quite popular and raising. No 21 on Red Monk June 2019 list
  • Complexity: Somewhat complex language
  • Maturity: Pretty new language, but used in Firefox and by AWS Firecracker
  • Tooling: Excellent build tool and package manager
  • Cross platform: Work on many different OSs
  • IDE: Good VS Code support

Strengths

Rust is a combination of ideas from OCaml, Haskell, C++, linear types and low level imperative control. It is very fast and well suited for system programming and secure programming. There is no garbage collector and no runtime, this makes Rust great for writing libraries and WebAssembly. Rust has started to make inroads in cloud infrastructure.

Issues

Getting rid of the garbage collector makes the language harder to understand and program in.
It is a pretty new language, still developing, and there are fewer libraries.


Scala


Scala

Scala combines object-oriented and functional programming in one concise, high-level language.

  • Core: Strict and lazy, nominal and structural, hybrid, implicits for IoC
  • Popularity: Very popular. No 13 on Red Monk June 2019 list. Spark is written in Scala
  • Complexity: It is a quite complex language, but it is easy to get started with
  • Maturity: Very stable. Run on JVM, well integrated with JVM ecosystem
  • Tooling: Great build tool and package managers
  • Cross platform: JVM and JS. Also early work on native / LLVM version
  • IDE: IntelliJ, VS Code, Eclipse

Strengths

Back-end programming, data engineering, web serving.
It is a great all around language. A lot of work has gone into creating language constructs that makes Scala work well with Java libraries. In Scala 2.0 this was not the case.
Spark is a cornerstone in data engineering.

Issues

There is quite a lot of complexity: Implicits, macros,  type classes / ad hoc polymorphism is possible but it takes some work.
Not super easy to set up a small project.
GUI programming support is not that great.


TypeStript


TypeScript

TypeScript brings you optional static type-checking along with the latest ECMAScript features.
  • Core: Gradually typed, structural, many new sophisticated type constructs, data language
  • Popularity: Very popular. No 10 on Red Monk June 2019 list
  • Complexity: Pretty complex
  • Maturity: A lot of money has gone into JavaScript, it is improving but it still feels wonky
  • Tooling: NPM. There are a lot of tools in the Nodes ecosystem, too many
  • Cross platform: Runs in every browser and on Node.js
  • IDE: Amazing support in VS Code

Strengths

Typescript makes big JavaScript codebases a lot more robust.
It is really easy to process semi structured data in json.
Starting to see some use of TS in machine learning e.g. with TensorFlow.js.

Issues

The JavaScript modules seem simple like in Python or Java, but there are many different module systems and it is pretty complicated. There are a lot of NPM packages but it still feels less mature. Getting setup with a small project with unit tests is more work than it should be.
Concurrency: Async await dramatically simplified call back style of programming, but still not great.


Golden Age Programming Languages


For many years I was puzzled about why language evolution seems to favor bloated and hacky development, while ignoring more principled computer science ideas. Twenty years ago I got very excited to read about these new functional languages with strong types. Unfortunately they were only popular in academia.

We are finally living in the golden age of programming languages. It just took some time. Development is moving quickly now and not slowing down.

Apologies in advance for omissions, outdated information and other mistakes.

Tuesday, March 22, 2016

Static vs. Dynamic Functional Languages

You can divide functional programming languages into 2 groups: Static and dynamic.

Dynamic functional languages: Clojure, Common Lisp, Racket and Scheme. They have few types often only known at run time.

Statically typed functional languages: F#, ML, Haskell, Idris and Scala. They have advanced types that are known at compile time.

Functional programming languages have similarities but are very different from one another. Some are quite hard to learn. What should you pick?

Slogans

Here are two extreme positions in functional programming reduced to slogans:

Lisp: Everything is Data

Lisp has a great story: Everything is data.

Lisp is homoiconic. There is one datatype: The S-expression in Lisp or an EDN in Clojure. This encodes:
  • Records
  • List
  • Map
  • Stream
  • Programs
Everything is unified and first class. This makes Lisp very elastic and adaptable to handle open ended problems like AI. It also leaves a lot of room for mistakes when dealing with complex data structures since everything sticks to everything.

Haskell: Everything is a Computation

Computation sounds like an equally strong unifying foundation. This is a strong counter argument to Lisp.

Haskell turns the world into mathematics by giving strong guarantees and the ability to reason about programs. It is fast, elegant and remarkably safe.

Most of the world is messy so programming in Haskell is both an art and a science.

A Type System is a Must For Production Code

In my experience:

A complex production server application demands a static type system for stability

The type system is doing at least half of my work when I work alone and prevents total anarchy when working in teams.

History of Static and Dynamic Type System

Like many other programmers, I have gone back and forth between preferring static and dynamic languages several times.

C++ and Java

I started using and loving the sophisticated statically typed object oriented languages: C++ and Java.
Why would anybody want to program in Basic?

Perl, Python and Ruby

At some point I had to make a small script for text processing. I realized that dynamically typed languages Perl, Python and Ruby are much simpler and faster to work with.
They borrow a lot of ideas form functional languages and saves you a lot of boiler plate. Programming became fun again.
I never wanted to go back.

F#, Scala and Haskell

Then came the raise of F#, Scala and Haskell.
I thought that you got the best of both worlds:
  • There are few visible types due to type inference
  • They look like dynamic language
  • Still you get strong safety from the invisible type system
  • They are fast
My stability concern for production application ruled out dynamic languages. The future belongs to F#, Scala and Haskell.

Living with Static Types

For the last 4 years I have been happy programming in Scala. It really improved my productivity.
I mainly deal with stable data types. Each data structure get immutable case class and they flow beautifully and it even works well in a concurrent system.

I am a little concerned about the amount of black magic going on at the type level in Scala and Haskell.

Web, Scripting and Data Exploration

Some fields continue to be dominated by dynamic languages:
  • Data exploration
  • Data science
  • Scripting
  • Web front end work in JavaScript, PHP and Ruby
I do data mining in Scala and can quickly add a new data source with unit tests to a stable functional reactive ingestion pipeline, but during a hackaton I had to explore a lot of different data sources and my normal startup time was too slow for the deadline.

Dynamic languages have an edge for small systems.

Problems Using Scala for NLP

Idiomatic Scala has been great for NLP.
I had to extract all the hidden and visible information on a html page and had to parse the DOM tree for everything: elements, attributes, code and json data.
The DOM tree is similar to an S-expression.
The best idiomatic Scala representation I could find was Play JSON. The DOM tree and Play JSON are not that similar and processing json in dynamic languages is more natural than in strongly typed languages.

Dynamic languages have an edge for some complex systems.

Lisp Revisited

I used Lisp in school. It was the cool AI language and my first functional language. I loved it, it blew my mind but I had a very shallow understanding.

Impressions from revisiting Lisp after using statically typed functional languages:
  • Lisp is small and elegant
  • Easy learning curve
  • Great at traversing dynamic data
  • Well suited for exploration
  • A lot of the principles of statically typed functional programming translate directly
  • I still think in Scala like types making my Clojure code better organized
  • Macros feel natural unlike in C++ and Scala
  • Lisp is really fluid combining in so many crazy ways
  • You lose a lot of safety

Going from Haskell to Clojure left me with the feeling I had when moving from C++ to Python. You get a lot of value for less effort.

Raise of the Gradual Type Systems

There has been slow movement towards gradual types. Here are a few place where they have popped up:

Ambrose Bonnaire-Sergeant on gradual typing in Clojure

The type systems in Typed Clojure and Typed Racket are pretty different than in Scala and Haskell. Generally weaker, but Typed Clojure and Typed Racket have union types that are only now investigated in Scala's experimental new type system Dotty.
These advances in gradual types make it possible to harden Lisp code to improve stability.

Data or Calculation

I was puzzled by the Lisp and Haskell slogans:
  • Everything is data
  • Everything is a calculation
It was a paradox. Which is a better foundation for computer science?
I could not easily dismiss either. For now I have accepted that we are stuck with both.

For a long time I suffered from the misunderstanding that F#, Scala and Haskell are like dynamic languages, with the addition of speed and safety. But they are fundamentally different.

Tuesday, September 29, 2015

Practical Scala, Haskell and Category Theory

Functional programming has moved from academia to industry in the last few years. It is theoretical with a steep learning curve. I have worked with strongly typed functional programming for 4 years. I took the normal progression, first Scala then Haskell and ended with category theory.

What practical results does functional programming give me?

I typically do data mining, NLP and back end programming. How does functional programming help me with NLP, AI and math?

    Scala

    Scala is a complex language that can take quite some time to learn. For a couple of years I was unsure if it really improved my productivity compared to Java or Python.

    After 2 years my productivity in Scala went up. I find that Scala is an excellent choice for creating data mining pipelines because it is:
    • Fast
    • Stable
    • Has lot of quality libraries
    • Has a very advanced type system
    • Good DSL for Hadoop (Scalding)

    Natural Language Processing in Scala

    Before Scala I did NLP in Python. I used NLTK the Natural Language Toolkit for 3 years.

    NLTK vs. ScalaNLP


    NLTK

    • Easy to learn and very flexible
    • Gives you a lot of functionality out of the box
    • Very adaptable, handles a lot of different structured file formats

    What I did not like about NLTK was:
    • It had a very inefficient representation of a text features as a Dictionary
    • The file format readers were not producing exactly matching structures and this did not get caught by the type system
    • You have to jump between Python, NumPy and C or Fortran for low level work

    ScalaNLP

    ScalaNLP merged different Scala numeric and NLP libraries. It is a very active parent project of Breeze and Eric.

    ScalaNLP Breeze

    Breeze is a full featured, fast numeric library that uses the type system to great effect.
    • Linear algebra
    • Probability Distribution
    • Regression algorithms
    • You can drop down to the bottom level without having to program in C or Fortran

    ScalaNLP Eric

    Eric is the natural language processing part of ScalaNLP. It has become a competitive NLP library with many algorithms for several human languages:
    • Reader for text corpora
    • Tokenizer
    • Sentence splitter
    • Part-of-speech tagger
    • Named entity recognition
    • Statistical parser


    Video lecture by David Hall the Eric lead

    Machine Learning in Scala

    The most active open source Scala machine learning library is MLib which is part of the Spark project.
    Spark now has data frames like R and Pandas.
    It is easy to set up machine learning pipelines, do cross validation and optimization of hyper parameters.

    I did text classification and set it up in Spark MLib in only 100 lines of code. The result had satisfactory accuracy.

    AI Search Problem in Scala vs. in Lisp

    I loved Lisp when I learned it at the university. You could do all these cool Artificial Intelligence tree search problems. For many years I suffered from Lisp envy.

    Tree search works a little differently in Scala, let me illustrate by 2 examples.

    Example 1: Simple Tree Search for Bird Flu

    You have an input HTML page and parsed into a DOM tree. Look for the word bird and flu in a paragraph that is not part of the advertisement section.
    I can visualize what a search tree for this would look like.

    Example2: Realistic Bird Flu Medication Search

    The problems I deal with at work are often more complex:
    Given a list of medical websites, search for HTML pages with bird flu and doctor recommendations for medications to take. Then do a secondary web search to see if the doctors are credible.

    Parts of Algorithm for Example 2

    This is a composite search problem:
    • Search HTML pages for the words bird and flu close to each other in DOM structure
    • Search individual match to ensure this is not in advertisement section
    • Search for Dr names
    • Find what Dr name candidates could be matched up with the section about bird flu
    • Web search for Dr to determine popularity and credentials
    Visualizing this as a tree search is hard for me.

    Lazy Streams to the Rescue

    Implementing solutions to the Example 2 bird flu medication problem takes:
    • Feature extractors
    • Machine learning on top of that
    • Correlation of a disease and a doctor
    This lends itself well to using Scala's lazy streams. Scala makes it easy to use the lazy streams and the type system gives a lot of support, especially when plugging together various streams.

    Outline of Lazy Streams Algorithm for Example 2

    1. Stream of all web pages
    2. Stream of tokenized trees
    3. Steam of potential text matches e.g. avian influenza, H5N1
    4. Filter Stream 3 if it is an advertisement part of the DOM tree, (no Dr Mom)
    5. Stream of potential Dr text matches from Stream 2
    6. Stream of good Dr names. Detected with machine learning
    7. Merge Stream 3 and Stream 6 to get bird flu and doctor name combination
    8. Web search stream for the doctor names from Stream 7 for ranking of result

    AI Search Problem in Lisp

    Tree search is Lisp's natural domain. Lisp could certainly handle Example 2 the more complex bird flu medication search. Even using a similar lazy stream algorithm.

    Additionally, Lisp has the ability to do very advanced meta programming:
    Rules that create other rules or work on multiple levels. Things I do not know how to do in Scala.

    Lisp gives you a lot of power to handle open ended problems and it is great for knowledge representation. When you try to do the same in Scala you end up either writing Lisp or Prolog style code or using RDF or graph databases.

    Some Scala Technical Details

    Here are a few observations on working with Scala.

    Scala's Low Rent Monads

    Monads are a general way to compose functionality. They are a very important organizing principle in Scala. Except is not really monads it is just syntactic sugar.

    You give us a map and a flatMap function and we don't ask any questions.

    Due to the organization of the standard library and subtyping you can even combine an Option and a List, which should strictly not be possible. Still this give you a lot of power.
    I do use Scala monads with no shame.

    Akka and Concurrency

    Scala's monads make it convenient to work with two concurrency constructs: Futures and Promises.

    Akka is a library implementing an Erlang style actor model in Scala.
    I have used Akka for years and it is a good framework to organize a lot of concurrent computation that requires communication.

    The type system does not help you with the creation of parent actors so you are not sure that they exist. This makes it hard to write unit tests for actors.

    Akka is good but the whole Erlang actor idea is rather low level.

    Scalaz and Cake Patterns

    Scalaz is a very impressive library that implements big parts of Haskell’s standard library in Scala.
    Scalaz’s monad typeclass is invariant, which fixes the violations allowed in the standard library.

    Cake Patterns allows for recursive modules, which make dependency injection easier. This is used in the Scala compiler.

    Both of these libraries got me into trouble as a beginner Scala programmer. I would not recommend them for beginners.

    How do you determine if you should use this heavy artillery?
    Once you feel that you are spending a lot of time repeating code due to insufficient abstraction you can consider it. Otherwise:

    Keep It Simple.

    Dependent Types and Category Theory in Scala

    There are many new theoretical developments in Scala:
    • Dotty - a new compiler built on DOT a new type-theoretic foundation of Scala
    • Cats library - a simplified version of Scalaz implementing concepts from category theory
    • Shapeless library for dependent types. I am using this in my production code since Shapeless is used in Slick and Parboiled2


    Haskell

    Haskell is a research language from 1990. In 2008 its popularity started to rise. You can now find real jobs working in Haskell. Most publicized is that Facebook wrote their spam filter in Haskell.



    Why is Haskell so Hard to Learn?

    It took me around 2 years to learn to program in Haskell, which is exceptionally long. I have spoken to other people at Haskell meetups who have told me the same.

    Mathematical Precision

    Python effectively uses the Pareto principle: 20% of the features will give give you 80% of the functionality; Python has very few structures in the core language and reuses them.

    Haskell uses many more constructs. E.g. exception handling can be done in many different ways each with small advantages. You can chose the optimal exception monad transformer that has least dependencies for your problem.

    Cabal Hell and Stack

    Haskell is a fast developing language with a very deep stack of interdependent libraries.
    When I started programming in it, it was hard to set up even a simple project since you could not get the libraries to compile with versions that were compatible with each other.
    The build system is called cabal, and this phenomenon is called Cabal Hell.
    If you have been reading mailing list there are a lot of references to Cabal Hell.

    The Haskell consulting company FPComplete first released Stackage a curated list of libraries that works together. In 2015 they went further and released Stack which is a system that installs different versions of Haskell to work with Stackage versions.

    This has really made Haskell development easier.

    Dependently Typed Constructs in Haskell

    Dependently typed languages are the next step after Haskell. In normal languages the type system and the objects of the language are different systems. In dependently typed languages the objects and the types inhabits the same space. This gives more safety and greater flexibility but also makes it harder to program in.
    The type checker has to be replaced with a theorem-prover.

    You have to prove that the program is correct, and the proofs are part of the program and first order constructs.

    Haskell has a lot of activities towards emulating dependently typed languages.
    The next version of the Haskell compiler GHC 8 is making a big push for more uniform handling of types and kinds.

    Practical Haskell

    Haskell is a pioneering language and still introducing new ideas. It has clearly shown that it is production ready by being able to handle Facebook's spam filter.

    Aesthetically I prefer terse programming and like to use Haskell for non work related programming.

    There is a great Haskell community in New York City. Haskell feels like a subculture where Scala has now become the establishment. That said I do not feel Haskell envy when I program in Scala on a daily basis.

    Learning Haskell is a little like running a marathon. You get in good mental shape.


    Category Theory

    Category theory is often called Abstract Nonsense both by practitioners and detractors.
    It is a very abstract field of mathematics and its utility is pretty controversial.

    It abstracts internal properties of objects away and instead looks at relations between objects.
    Categories require very little structure and so there are categories everywhere.  Many mathematical objects can be turned into categories in many different ways. This high level of abstraction makes it hard to learn.

    There is a category Hask of Haskell types and functions.


    Steve Awodey lecture series on category theory

    Vector Spaces Described With a Few String Diagrams

    To give a glimpse of the power of category theory: In this video lecture John Baez shows how you can express the axioms of finite dimensional vector spaces with a few string diagrams.

    Video lecture by John Baez

    With 2 more simple operations you can extend it to control theory.

    Quest For a Solid Foundation of Mathematics

    At the university I embarked on a long quest for a solid scientific foundation. Fist I studied chemistry and physics. Quantum physics drove me to studying mathematics for more clarity. For higher clarity and a solid foundation I studied mathematical logic.
    I did not find clarity in mathematical logic. Instead I found:

    The Dirty Secret About the Foundation of Mathematics

    My next stop was the normal foundation for modern mathematics: ZFC, Zermelo–Fraenkel set theory with the axiom of choice.

    This was even less intuitive than logic. There were more non intuitive axioms. This was like learning computer science from a reference of x86 assembly: A big random mess. There were also an uncertain connection between the axioms of logic and the axioms set theory.

    ZFC and first order logic makes 2 strong assumptions:
    1. Law of Excluded Middle
    2. Axiom of Choice
    Law of Excluded Middle is saying that every mathematical sentence is either true or false. This is a very strong assumption that was not motivated at all. And it certainly does not extend to other sentences.

    Constructive Mathematics / Intuitionistic Logic

    There was actually a debate about what should be a foundation for mathematics at the beginning of the 20th century.
    A competing foundation of mathematics was Brouwer's constructive mathematics. In order to prove something about a mathematical object you need to be able to construct it and via the Curry-Howard correspondence this is equivalent to writing a program constructing a particular type.

    This was barely mentioned at the university. I had one professor who once briefly said that there was this other thing called intuitionistic logic, but it was so much harder to prove things in it, why should we bother.

    Recently constructive mathematics have had a revival with Homotopy Type Theory. HoTT is based on category theory, type theory, homotopy theory and intuitionistic logic.
    This holds a lot of promise and is another reason why category theory is practical for me.


    Robert Harper's lectures on type theory
    end with an introduction to HoTT

    Future of Intelligent Software

    There are roughly 2 main approaches to artificial intelligence
    • Top down or symbolic techniques e.g. logic or Lisp
    • Bottom up or machine learning techniques e.g. neural networks
    The symbolic approach was favored for a long time but did not deliver on its promise. Now machine learning is everywhere and has created many advances in modern software.

    To me it seems obvious that more intelligent software needs both. But combining them has been an elusive goal since they are very different by nature.

    Databases created a revolution in data management. They reduce data retrieval to simplified first order logic, you just write a logic expression for what you want.

    Dependently typed language is the level of abstraction where programs and logic merge.
    I think that intelligent software of the future will be a combination of dependently typed languages and machine learning.
    A promising approach is: Discovery of Bayesian network models from data. This finds causality in a form that can be combined with logic reasoning.

    Conclusion

    I invested a lot of time in statically typed functional languages and was not sure how much this would help me in my daily work. It helped a lot, especially with reuse and stability.

    Scala has made it substantially easier to create production quality software.

    MLib and ScalaNLP are 2 popular open source projects. They show me that Scala is a good environment for NLP and machine learning.

    I am only starting to see an outline of category theory, dependently typed languages and HoTT. It looks like computer science and mathematics are not mainly done, but we still have some big changes ahead of us.

    Monday, September 23, 2013

    Big Data: What Worked?

    "Big data" created an explosion of new technologies and hype: NoSQL, Hadoop, cloud computing, highly parallel systems and analytics.

    I have worked with big data technologies for several years. It has been a steep learning curve, but lately I had more success stories.

    This post is about the big data technologies I like and continue to use. Big data is a big topic. These are some highlights from my experience.

    I will relate big data technologies to modern web architecture with predictive analytics and raise the question:

    What big data technologies should I use for my web startup?

    Classic Three Tier Architecture

    For a long time software development was dominated by the three tier architecture / client server architecture. It is well described and conceptually simple:
    • Client
    • Server for business logic
    • Database
    It is straightforward to figure out what computations should go where.

    Modern Web Architecture With Analytics

    The modern web architecture is not nearly as well established. It is more like an 8 tiered architecture with the following components:
    • Web client
    • Caching
    • Stateless web server
    • Real-time services
    • Database
    • Hadoop for log file processing
    • Text search
    • Ad hoc analytics system
    I was hoping that I could do something closer to the 3-tier architecture, but the components have very different features. Kicking off a Hadoop job from a web request could adversely affect your time to first byte.

    A problem with the modern web architecture is that a given calculation can be done in many of those components.

    Architecture for Predictive Analytics

    It is not at all clear what component predictive analytics should be done in.

    First you need to collect user metrics. In what components can do you do this?
    • Web servers, store the metric in Redis / caching
    • Web servers, store the metric in the database
    • Real-time services aggregates the user metric
    • Hadoop run on the log files

    User metric is needed by predictive analytics and machine learning. Here are some scenarios for this:
    • If you are doing simple popularity based predictive analytics this can be done in the web server or a real-time service.
    • If you use a Bayesian bandit algorithm you will need to use a real-time service for that.
    • If you recommend based on user similarity or item similarity you will need to use Hadoop.

    Hadoop

    Hadoop is a very complex piece of software to handle very large amounts of data that cannot be handled by conventional software because it is too big to fit on one computer.

    I compared different Hadoop libraries in my post: Hive, Pig, Scalding, Scoobi, Scrunch and Spark.

    Most developers that have used Hadoop complain about it. I am no exception. I still have problems with Hadoop jobs failing due to errors that are hard to diagnose. Generally I have been a lot happier about Hadoop lately. I am only using Hadoop for big custom extractions or calculations from log files stored in HDFS. I do my Hadoop work in Scalding or HIVE

    The Hadoop library Mahout can calculate user recommendations based on user similarity or item similarity.

    Scalding

    Hadoop code in Scalding looks a lot like normal Scala code. The scripts I am writing are often just 10 lines of code and look a lot like my other Scala code. The catch is that you need to be able to write idiomatic functional Scala code.

    HIVE

    HIVE makes it easy to extract and combine data from HDFS. You just write SQL after some setup of a directory with table structure in HDFS.

    Real-time Services

    Libraries like Akka, Finagle and Storm are good for having long running stateful computations.
    It is hard to write correct highly parallel code that scales to multiple machines using normal multithreaded programming. For more details see my blog post: Akka vs. Finagle vs. Storm.

    Akka and Spray

    Akka is a simple actor model taken from the Erlang language. In Akka you have a lot of very lightweight actors, they can share a thread pool. They do not block on shared state but communicate by sending immutable messages.

    One reason that Akka is a good fit for real-time services is that you can do varying degrees of loose coupling and all services can talk with each other.

    It is hard to change from traditional multithreaded programming to using the actor model. There are just a lot of new actor idioms and design patterns that you have to learn. At first the actor model seems like working with a sack of fleas. You have much less control over the flow due to the distributed computation.

    Spray makes it easy to put a web or RESTful interface to your service. This makes it easy to connect your service with the rest of the world. Spray also has the best Scala serialization system I have found.

    Akka is well suited for: E-commerce, high frequency trading in finance, online advertising and simulations.

    Akka in Online Advertising

    Millions of users are interacting with fast changing ad campaigns. You could have actors for:
    • Each available user
    • Each ad campaign
    • Each ad
    • Clustering algorithms
    • Each cluster of users
    • Each cluster of ads
    Each actor is developing in time and can notify and query all other actors.

    NoSQL

    There are a lot of options, with no query standard:
    • Cassandra
    • CouchDB
    • HBase
    • Memcached
    • MongoDB
    • Redis
    • SOLR
    I will describe my initial excitement about NoSQL, the comeback of SQL databases and my current view on where to use NoSQL and where to use SQL.

    MongoDB

    MongoDB was my first NoSQL technology. I used it to store structured medical documents.

    Creating a normalized SQL database that represents a structured data format is a sizable task and you easily end up with 20 tables. It is hard to insert a structured document into the database in the right sequence, so foreign key constraints are satisfied. LINQ to SQL helped with this but it was slow.

    I was amazed by MongoDB's simplicity:
    • It was trivial to install
    • It could insert 1 million documents very fast
    • I could use the same Python NLP tools for many different types of documents

    I felt that SQL databases were so 20th century.

    After some use I realized that interacting with MongoDB was not as easy from Scala. I tried different libraries Subset and Casbah.
    I also realized that it is a lot harder to query data from MongoDB than a SQL database both in syntax and expressiveness.
    Recently SQL databases have added JSON as a data type, taking away some of MongoDB's advantage.

    Today I use SQL databases for curated data. But MongoDB for ad hoc structured document data.

    Redis

    Redis is an advanced key value store that is mainly living in memory but with backup to disk. Redis is a good fit for caching. It has some specialized operations:
    • Simple to age out data
    • Simulates pub sub
    • Atomic update increments
    • Atomic list append
    • Set operations

    Redis also supports sharding well, in the driver you just give a list of Redis servers and it will send the data to the right server. Redistributing data after adding more sharded servers to Redis is cumbersome.

    I first thought that Redis had an odd array of features but it fits the niche of real-time caching.

    SOLR

    SOLR is the most used enterprise text search technology. It is built on top of Lucene.
    It can store and search document with many fields using an advanced query language.
    It has an ecosystem of plugins doing a lot of the things that you would want. It is also very useful for natural language processing. You can even use SOLR as a presentation system for your NLP algorithms.

    To Cloud or not to Cloud

    A few years back I thought that I would soon be doing all my work using cloud computing services like Amazon's AWS. This did not happen, but virtualization did. When I request a new server the OPS team usually spins up a virtual machine.
    A problem with cloud services is that storage is expensive. Especially Hadoop sized storage.

    If I were in a startup I would probably consider the cloud.

    Big and Simple

    My fist rule for software engineering is: Keep is simple.

    This is particularly important in big data since size creates inherent complexity.
    I made the mistake of being too ambitious too early and think out too many scenarios.

    Startup Software Stack

    Back to the question:

    What big data technologies should I use for my web startup?

    A common startup technology stack is:
    Ruby on Rails for your web server and Python for your analytics and hope that a lot of beefy Amazon EC2 servers will scale your application when your product takes off.
    It is fast to get started and the cloud will save you. What could possibly go wrong?

    The big data approach I am describing here is more stable and scalable, but before you learn all these technologies you might run out of money.

    My answer is: It depends on how much data and how much money you have.

    Big Data Not Just Hype

    "Big data" is misused and hyped. Still there is a real problem, we are generating an astounding amount of data and sometimes you have to work with it. You need new technologies to wrangle this data.

    Whenever I see a reference to Hadoop in a library I get very uneasy. These complex big data technologies are often used where much simpler technologies would have sufficed. Make sure your really need them before you start. This could be the difference between your project succeeding or failing.

    It has been humbling to learn these technologies but after much despair I now enjoy working with them and find them essential for those truly big problems.

    Monday, April 1, 2013

    Akka vs. Finagle vs. Storm

    Akka, Finagle and Storm are 3 new open source frameworks for distributed parallel and concurrent programming. They all run on the JVM and work well with Java and Scala.

    They are very useful for many common problems:

    • Real-time analytics
    • Complex website with different input and outputs
    • Finance
    • Multiplayer games
    • Big data


    Akka, Finagle and Storm are all very elegant solutions optimized for different problems. It is confusing what framework you should use for what problem. I hope that I can clarify this.


    The 30 seconds history of parallel programming

    Parallel / concurrent programming is hard. It had rudimentary support in C and C++ in the 1990s.

    In 1995 Java made it much simpler to do simple concurrent programming on one machine by adopting the monitor primitive. Still if you had more than a few threads you could easily get deadlocks, and it did not solve the bigger problem of spreading a computation over many machines.

    The growth of big data created a strong demand for better frameworks.


    MapReduce and Hadoop 

    Hadoop the open source version of Google's MapReduce is the most well known method for distributed parallel programming.
    It does streaming batch computation, by translating an algorithm to a sequence of map and reduce steps.
    Map is fully parallel.
    Reduce collect the result from the mapping step.

    Hadoop has a steep learning curve. You should only use it when you have no other choice. Hadoop has a heavy stack with a lot of dependencies.

    My post Hive, Pig, Scalding, Scoobi, Scrunch and Spark describes simpler frameworks built on top of Hadoop, but they are still complex.

    Hadoop has long response time, and it not suited for real-time responses.

    The Akka, Finagle and Storm frameworks are all easier to use than Hadoop and are suited for real-time responses.


    Storm

    Storm is created by Twitter and open sourced in 2011. It is written in Clojure and Java, but it works well with Scala. It is well suited for doing statistics and analytics on massive streams of data.

    Storm can describe streaming computation very simply: You make a graph of you computation with some input data source called spouts at the top, below that computation nodes called bolts that can depend on any spout or bolt that has been computed above it, but you cannot have cycles. The graph is called a topology.

    Features


    • Storm will deal with communication between machines and bolts
    • Consistent hashing to spread computation to right instance of a bolt
    • Error recovery due to hardware or network failure
    • Storm does not handle computations that fail due to inherent errors well
    • Can do analytics on Twitter scale input, literally
    • You can create a bolt in a non JVM language as long at it talks Thrift
    • Build in support for Ruby, Python, and Fancy

    Word counter example in Storm

    The hello world example for Hadoop is to count word frequencies in a big expanding text corpus.

    This is a word counting topology in Storm:

    • Input spout is a stream of texts
    • Tokenization blot, you tell Storm how many instance of this you want, they can run either in local mode on one machine or in distributed mode on several machines.
    • Counting blot. This too can be split over different machines.


    Spam filter topology in Storm

    Let me give an outline of how to make a statistical spam filter using simple natural language processing. This can be used on emails, postings or comments.

    There are 2 data paths:

    Training path

    Containing messages that have been classified as spam or ham.

    1. Input spout: is tuple of the text and status: spam or ham
    2. Tokenizer bolt. Input 1
    3. Word frequency bolt. Input bolt: 2
    4. Bigram finder bolt. Input bolts: 2 and 3
    5. Most important word and bigram selector bolt. Input bolts: 2, 3 and 4
    6. Feature extractor bolt. Input bolt: 5
    7. Bayesian model bolt. Input 3, 4 and 6,

    Categorizer path

    The unprocessed messages would be sent to the Bayesian model bolt so it can be categorized as spam or ham.

    • Input spout: tuple of the text and an id for message
    • Tokenizer
    • The feature extractor. Extracting optimal feature set of words and bigram. Bolt 6 from above.
    • Bayesian model. Bolt 7 from above
    • Result bolt tuple message id and probability of spam


    This spam filter is quite a complex system that fits well with Storm.


    Akka

    Akka v0.6 was released in 2010. Akka is now at v2.2 and is maintained by TypeSafe the company that maintain Scala and it part of their stack. It is written in Scala and Java.

    Features


    • Akka is based on the Erlang language that was developed to handle telecom equipment and be highly parallel and fault tolerant.
    • Akka gives you very fine grained parallel programming. You split you tasks up into smaller sub tasks and have a lot of actors compute these tasks and communicate the result.
    • Works well for two way communication.
    • An actor that can communicate with mailboxes and they are single threaded.
    • The motto of Akka's team is: Let it fail early.
    • If an actor fails Akka has different strategies for recovery.
    • Actors can have share access to an object on one machine, e.g. a cache.
    • Communication between different actors is very simple, it is just a method call and it will give you a future to a value.
    • Actors are very lightweight, you can have 2.7 million actors per GB of heap. 
    • There is a executions context with shared thread pool.
    • This works well when there is IO bound computations.
    • Turns computation into a Future, a monadic composable asynchronous computation.
    • Incorporate dataflow variables from a research language called Oz.

    Use cases


    • Agents
    • Simulations
    • Social media 
    • Multiplayer game 
    • Finance
    • Online betting


    Finagle

    Finagle is created by Twitter and open sourced in 2011. It is written in Scala and Java.

    Finagle lets internal and external heterogeneous services communicate. It implement asynchronous Remote Procedure Call (RPC) clients and servers.

    Features


    • It is simple to create servers and clients for your application
    • Remote services calling each other
    • Speaks different protocols: HTTP, Thrift, Memcashed
    • Failover between servers
    • Is good for having one service query other services 
    • Uniform error policy
    • Uniform limits on retry
    • Two way communication
    • Load balancing
    • Turns computation into a Future, a monadic composable asynchronous computation.

    Use cases

    • Complex website using different services and supporting many different protocols
    • Web crawler


    Side by side comparisons


    Akka vs. Finagle

    Akka and Finagle can both do two-way communication.

    Akka is great as long as everything lives on one actor system or multiple remote actors systems. It is very simple to have them communicate.

    Finagle is much more flexible if you have heterogeneous services and you need different protocols and fallbacks between servers.


    Akka vs. Storm

    Akka is better for actors that talk back and forth, but you have to keep track the actors, and make strategies for setting up different actor systems on different servers and make asynchronous request to those actor systems. Akka is more flexible than Storm but there is also more to keep track of.

    Storm is for computations that move from upstream sources to different downstream sinks. It is very simple to set this up in Storm so it run computation over many distributed servers.

    Finagle vs. Storm

    Finagle and Storm both handle failover between machines well.

    Finagle does heterogeneous two-way communication.

    Storm does homogeneous one way communication, but does it in a simple way



    Serialization of objects

    Serialization of objects is a problem for all of these, since you have to send object between different machine, and the default Java serialization has problems:

    • It is very verbose
    • It does not work well with Scala's singleton objects
    Here are a few Scala open source libraries:





    My experience

    It has been hard for me to decide what framework is the better fit in a given situation, despite a lot of reading and experimenting.

    I started working on an analytics program and Storm was a great fit and much simpler than Hadoop.

    I moved to Akka since I needed to:
    • Incorporate more independent sub systems all written in Scala
    • Make asynchronous call to external services that could fail
    • Setup up on-demand services

    Now I have to integrate this analytics program with other internal and external services some in Scala some in other languages I am now considering if Finagle might be a better fit for this. Despite Akka being easier in a homogeneous environment.


    Afterthought

    When I went to school parallel programming was a buzz word. The reasoning was: 

    Parallel programming works like the brain and it will solve our computational problems

    We did not really know how you would program it. Now it is finally coming of age.

    Akka, Finagle, Storm and MapReduce are different elegant solutions to distributed parallel programming. They all use ideas from functional programming.

    Tuesday, February 5, 2013

    Scala vs. Haskell vs. Python

    Functional programming is on the upswing, but should you bet your career on it, or is it a short-lived technology fad?

    I have long wanted to use functional programming professionally and for the last year I have. Mainly Scala, written in Haskell style, plus some real Haskell programming.

    Here is my impression of Scala and Haskell compared to my benchmark language, Python.


    Scala

    Scala is a functional object oriented hybrid language running on the JVM. It was created by Martin Odersky in 2003. Scala took Java / JVM and organized it nicely according to a few orthogonal principles.
    Working in Scala has been a pleasure, there is a lot to like:
    • You have easy access to the giant world of Java libraries
    • Lot of libraries written for Scala
    • Very fast only 2 to 3 time slower than C
    • Big ecosystem
    • Easy to define a DSL in Scala so you can do everything in Scala
    • Very advanced type system
    • Adapted in the industry by: Twitter, LinkedIn, Foursquare, ...
    • Scala is the most adapted functional language
    • Web frameworks: Play, Scalatra, any kind of Java Servlets
    • Scalding: a very nice framework for Hadoop programming
    • Akka: an Erlang style actor system
    • Mixin composition
    • Good GUI with Swing and JavaFX
    • SBT the best build tool I have used
    • Scala is a full stack multi purpose language

    Issues

    • It is very complex
    • It is a kitchen sink language
    • Confusing to keep Scala collections and parallel Java collections apart

    Eclipse Plugin Scala IDE for Eclipse




    The Scala Eclipse plugin is very solid, but not quite as good as the fantastic Java support.

    • Syntax highlighting
    • Code completion
    • Debugger
    • Shows compile errors with explanation
    • Rudimentary refactoring
    • Jump to definition


    Monad and Applicative Functor

    Two very important concepts in functional programming are monad and applicative functor.

    The best reference I found was: Learn You a Haskell for a Great Good!.

    A monad gives you simple ways of composing different operations. First it seems like an odd principle. Understanding monad took me several months.

    In UNIX and OS X you can create complex programs by piping simple commands together. A monad generalizes this a lot.

    Once you understand the monad you will see monads pop up in so many places. The monad is an amazingly powerful construct.

    The last place I found monads unexpectedly showed up was in asynchronous programming, e.g. used in AJAX.
    You send an external request and you do not block but you have a callback for when the result comes back. This is efficient but messy to program especially if you have a chain of requests to process and you have to have a lot of callbacks floating around. You can do this type of calculations using a future / promise, and luckily a future is a monad so you string a long list of operations after each other in a very simple way.


    Scalaz

    Scalaz is a Scala library that replicates a lot of Haskell constructs, at the cost of being similarly hard to understand.

    You can work with monads in Scala without using Scalaz since the "for-statement" in Scala is syntactic sugar for monadic "for-comprehension".

    I have programmed Java in a functional style both professionally and for my open source project. It is possible but it is rather verbose and clunky. Scala is much more powerful, simpler and cleaner than both Java approaches, and Scalaz is a big step up from Scala.

    When I started programming in Scala I read a really funny blog post called Truth about Scala that describes how a team starts to use Scala and first they are excited, but it quickly descends into a death spiral of complexity. I was concerned with this and tried to keep my code as simple as possible and avoid Scalaz for a long time. I would advise others to become very comfortable with Scala before starting to work with Scalaz.


    Haskell

    Haskell is a strongly typed, lazy, pure functional programming language. It is an academic research language created by a committee in 1987.
    One reason that I got into Haskell was in order to understand monads and applicative functors, they are important constructs in Haskell and category theory.

    There is a steep learning curve for Haskell. Maybe it is more like a hump you have to get over. Just getting to basic proficiency is hard. It took me around one year of low intensity studying, but one day it just made sense.

    • Haskell now has a lot of libraries
    • Libraries and dependencies are handled by Cabal
    • It is fast only 2 - 3 times slower than C
    • Great concurrency
    • Repa native parallel numerical array processing
    • Very small language
    • Very pure
    • Very terse code
    • Very advanced type system
    • Hoogle a Haskell search engine
    • Great web frameworks Happstack, Snap and Yesod


    Issues

    • Bad GUI support
    • Module system is crude


      Hoogle, a Search Engine for Haskell

      A colleague told me that when he needed a function he would write out its signature and put it into Hoogle and often it would take him to the function that he needed. First time I tried it, and it actually took me to a function that solved a bigger part of the problem than what I was looking for.

      When I searched Hoogle for this function signature:

      (a -> Bool) -> [a] -> [Int]

      I got these results in EclipseFP:


      Eclipse Plugin EclipseFP

      EclipseFP with Hoogle


      The Haskell Eclipse plugin is quite good:
      • Syntax highlighting
      • Cabal integration
      • Hoogle integration
      • Code completion
      • Debugger
      • GHCi integration with automatic reload


      Python

      Python is a high-level language built on ideas from functional, imperative and object oriented programming. It was created by Guido van Rossum in 1989.

      For many years Python was my favorite language. It is a language for kids and also for scientists and a lot of people in between.
      • Python is probably the easiest language to learn
      • It took me a day to learn well enough to use
      • Very minimal language
      • Very terse code
      • Excellent wrapper language
      • Many implementations: CPython, Jython (JVM), IronPython (CLR), PyPy
      • Good bindings to numerical packages: NumPy, SciPy
      • Used in computer vision since OpenCV choosing Python to be its scripting language
      • Used in natural language processing due to the NLTK
      • Great web frameworks: Django, TurboGear, CherryPy

      Issues

      Python is not quite a full stack language there are a few missing pieces:
      • Bad GUI support
      • Low-level numerical programming had to be done in external packages
      • Concurrency
      • Speed around 50 times slower compared to C

      Eclipse Plugin PyDev




      I like PyDev it has:
      • Syntax highlighting
      • Code completion
      • Debugger


      Best Programming Language for Kids

      If a kid can understand a technology it is well designed. My daughter is turning 5 and I am thinking about what language I should introduce her to first.

      Python

      My first inclination was to teach her Python since it is the simplest, but it needs to give immediate visual feedback. Python's lack of a good GUI is a problem.

      Haskell

      I have also been tempted to show her some Haskell to teach her good habits in a pure and minimal language. But if I tell her that:

      "A monad is just a monoid in the category of endofunctors"

      she will walk away or scream.

      Scala

      Kojo is a LOGO like graphical turtle programming environment written in Scala. Scala's type inference makes it simpler for kids who will not have a good concept of types.

      My daughter plays with Kojo and she likes it. She comes and asks me if we can do the turtle?


      Kojo notice green drawing turtle in the middle


      So unexpectedly, Scala, the biggest language, was the most kid friendly language. Based on a very small sample size.


      Category Theory

      Haskell is using plenty of concepts from category theory. E.g. the monad. In my quest to understand it I started to study category theory.

      Category theory has been called: "Abstract nonsense", both by its practitioners and critics. And for very good reasons. It can suck you into a black hole of abstraction.

      Category Theory Introductions

      You do not need to understand category theory to program in Haskell or Scalaz, but if it helps you here are a few introduction videos.

      Dominic Verity presents a gentle introduction to Category Theory:

      http://vimeo.com/17207564


      Dominic Verity on Category Theory (Part 2)



      Error792's category theory class, currently there are 5 parts



      Math and Programming

      I have often said that there is no connection between math and programming. The only math you need to program is counting, and occasionally, addition. I felt:

      Programmers are the grease monkeys of today

      We move some data around and throw it on webpages

      After working in Scala and Haskell I have changed my tune:

      When you program in Scala you feel like an engineer

      When you program in Haskell you feel like a mathematician


      Adapting Haskell and Scalaz for a Team

      Using Haskell and Scalaz takes a special mindset and a lot of dedication. I have been very lucky to work at a place that has attracted physicists, mathematicians and theoretical CS people.

      If a big part of your team does not have these qualities you risk wasting time and chasing developers away.

      On the other hand if your team is using Haskell or Scalaz you will attract this brand of developers.



      Conclusion

      I had high expectations when I started using functional programming full time, but I have been disappointed by new technology many times before. Functional programming met my high expectations. It has been challenging and very enjoyable.

      I was a C++ programmer for 8 years, and considered C++ the one true way for high speed, high level programming.
      Recently I looked at a code sample written in C++ and it hurts my eyes: Filled with boilerplate and state.

      Functional programming is addictive and will make you spoiled


      Functional programming is here to stay. It has been an important part of C# since v3.0. It is finally getting added to Java in Java 8 coming out soon. The classic functional languages LISP or ML are the basis of: Clojure and F# that have thriving communities and are used in industry. The time has come to invest some time in understanding functional programming.


      Python

      I enjoy Scala and Haskell more than Python, but Python seem to be the language that I always go back to. It is a power tool that adds very little weight to your programmer's toolbox. You get high return on investment with Python, while with Scala and especially Haskell you have to invest a lot and for a long time before you break even.

      Scala

      Scala is now popular enough that you can get a job doing it. Moving from Java or C# to Scala is pretty easy. Since you can start programming Scala like Java.  Scala is a big and complex language with a big ecosystem and it takes months to get a deeper understanding. Scala is substantially more powerful than Java 7, but Java 8 has supposedly taken a lot of ideas from Scala.

      Haskell

      Haskell is definitely the road less traveled, but it is a road, not a trail. It is an academic research language created in 1987. Recently it has started to break into the mainstream. There are a few jobs in Haskell. Gaining basic proficiency in Haskell is quite hard, but afterwards other languages look a little clunky. Writing Haskell feels like doing math.

      Scala vs. Haskell

      Scala is a safer bet for most programmers, since it is better adapted to more tasks, and you can approximate Haskell pretty well with Scalaz. Scala has a very advanced type system to handle its object oriented features.

      Haskell appeals to functional language purists, mathematicians and category theorists. Esthetically I prefer Haskell. It is terser and the type inference is better.

      In most cases external factors would dictate whether Scala or Haskell would be a better fit for your project.


      Haskell vs. Python

      Haskell and Python have a lot in common:
      • Minimalistic languages
      • White space delimited
      • Very terse
      • List comprehension
      • Important tuple type
      • GUI binding to wxWidget, GTK
      Haskell is statically typed and optimized towards purity and speed.

      Python is dynamically typed and optimized towards pragmatism and simplicity.