Like me, I believe most people go about their business never to give a serious thought about their assumed private correspondence when using Gmail to email friends, colleagues and business associates.  As it turns out, your daily banter may not be so private after all.  A recent article in Fortune Magazine, “Judge Rejects Google Deal Over Email Scanning” caught my attention and an immediate thought dominated my curiosity…Google email and scanning scam.  

In essence, the article describes Googles’ agreement to change the way it scans incoming messages so that it no longer reads emails while they are in transit, but only when they are in someone's inbox! So, what exactly does that mean? Judge Koh, a San Francisco federal judge, said she's not so sure about that. Her ruling claims the settlement does not provide an adequate technical explanation of Google's workaround, which involves scanning in-transit emails for security purposes, and then later parsing them for advertising data. The judge also proposed a legal settlement to pay $2.2 million to lawyers, but nothing to consumers.

My interest in this story is not so much about the proposed settlements or the specific details about how Google or any of the web giants settle claims based on vague legal language. It is however, more about the naiveté of myself and perhaps many others that never question how the email scanning process really works. I wonder, do most of us really care that Gmail uses contents of our mail to display targeted ads?

Studying a functional programming language is a good way to discover new approaches to problems and different ways of thinking. Although functional programming has much in common with logic and imperative programming, it uses unique abstractions and a different toolset for solving problems. Likewise, many current mainstream languages are beginning to pick up and integrate various techniques and features from functional programming.

Many authorities feel that Haskell is a great introductory language for learning functional programming. However, there are various other possibilities, including Scheme, F#, Scala, Clojure, Erlang and others.

Haskell is widely recognized as a beautiful, concise and high-performing programming language. It is statically typed and supports various cool features that augment language expressivity, including currying and pattern matching. In addition to monads, the language support a type-class system based on methods; this enables higher encapsulation and abstraction. Advanced Haskell will require learning about combinators, lambda calculus and category theory. Haskell allows programmers to create extremely elegant solutions.

Scheme is another good learning language -- it has an extensive history in academia and a vast body of instructional documents. Based on the oldest functional language -- Lisp -- Scheme is actually very small and elegant. Studying Scheme will allow the programmer to master iteration and recursion, lambda functions and first-class functions, closures, and bottom-up design.

Supported by Microsoft and growing in popularity, F# is a multi-paradigm, functional-first programming language that derives from ML and incorporates features from numerous languages, including OCaml, Scala, Haskell and Erlang. F# is described as a functional language that also supports object-oriented and imperative techniques. It is a .NET family member. F# allows the programmer to create succinct, type-safe, expressive and efficient solutions. It excels at parallel I/O and parallel CPU programming, data-oriented programming, and algorithmic development.

Scala is a general-purpose programming and scripting language that is both functional and object-oriented. It has strong static types and supports numerous functional language techniques such as pattern matching, lazy evaluation, currying, algebraic types, immutability and tail recursion. Scala -- from "scalable language" -- enables coders to write extremely concise source code. The code is compiled into Java bytecode and executes on the ubiquitous JVM (Java virtual machine).

Like Scala, Clojure also runs on the Java virtual machine. Because it is based on Lisp, it treats code like data and supports macros. Clojure's immutability features and time-progression constructs enable the creation of robust multithreaded programs.

Erlang is a highly concurrent language and runtime. Initially created by Ericsson to enable real-time, fault-tolerant, distributed applications, Erlang code can be altered without halting the system. The language has a functional subset with single assignment, dynamic typing, and eager evaluation. Erlang has powerful explicit support for concurrent processes.

Computer Programming as a Career?

What little habits make you a better software engineer?

Structure Rule Language

To aid in the ease of rule authoring, Blaze Software, now Fair Isaac, created the proprietary Structure Rule Language (SRL), an object-oriented programming language designed to enable those with little or no background in software development to pen rules. Although the capabilities of this language are far too extensive to detail in this article, we can examine the basic rule syntax.

Rules in the SRL take the following form:

rule RuleName [at | priority M] is

A business rule is the basic unit of rule processing in a Business Rule Management System (BRMS) and, as such, requires a fundamental understanding. Rules consist of a set of actions and a set of conditions whereby actions are the consequences of each condition statement being satisfied or true. With rare exception, conditions test the property values of objects taken from an object model which itself is gleaned from a Data Dictionary and UML diagrams. See my article on Data Dictionaries for a better understanding on this subject matter.

A simple rule takes the form:

if condition(s)

then actions.

An alternative form includes an else statement where alternate actions are executed in the event that the conditions in the if statement are not satisfied:

if condition(s)

then actions

else alternate_actions

It is not considered a best prectice to write rules via nested if-then-else statements as they tend to be difficult to understand, hard to maintain and even harder to extend as the depth of these statements increases; in other words, adding if statements within a then clause makes it especially hard to determine which if statement was executed when looking at a bucket of rules. Moreoever, how can we determine whether the if or the else statement was satisfied without having to read the rule itself. Rules such as these are often organized into simple rule statements and provided with a name so that when reviewing rule execution logs one can determine which rule fired and not worry about whether the if or else statement was satisfied. Another limitation of this type of rule processing is that it does not take full advantage of rule inferencing and may have a negative performance impact on the Rete engine execution. Take a class with HSG and find out why.

Rule Conditions