I had missed Ray's talk and the subsequent panel that Ray and John had been on, and they now picked right up where they'd left off, with Ray saying that the rate of improvement of technology was going to accelerate and that we were going to become robots or fuse with robots or something like that, and John countering that this couldn't happen, because the robots couldn't be conscious.

While I had heard such talk before, I had always felt sentient robots were in the realm of science fiction. But now, from someone I respected, I was hearing a strong argument that they were a near-term possibility. I was taken aback, especially given Ray's proven ability to imagine and create the future. I already knew that new technologies like genetic engineering and nanotechnology were giving us the power to remake the world, but a realistic and imminent scenario for intelligent robots surprised me.

Brilliant 11-year old article, great Sunday evening read.

One of the main reasons why software projects fail is the lack of communication between the business users, who actually know the problem domain, and the developers who design and implement the software model. Business users understand the domain terminology, and they speak a vocabulary that may be quite alien to the software people; it's no wonder that the communication model can break down right at the beginning of the project life cycle.

A DSL (domain-specific language)^1,3 bridges the semantic gap between business users and developers by encouraging better collaboration through shared vocabulary. The domain model that the developers build uses the same terminologies as the business. The abstractions that the DSL offers match the syntax and semantics of the problem domain. As a result, users can get involved in verifying business rules throughout the life cycle of the project.

This article describes the role that a DSL plays in modeling expressive business rules. It starts with the basics of domain modeling and then introduces DSLs, which are classified according to implementation techniques. The article then explains in detail the design and implementation of an embedded DSL from the domain of securities trading operations.

One of the better articles I've read that explain what a DSL is and how you can get started...

About this series

This series aims to reorient your perspective toward a functional mindset, helping you look at common problems in new ways and find ways to improve your day-to-day coding. It explores functional programming concepts, frameworks that allow functional programming within the Java language, functional programming languages that run on the JVM, and some future-leaning directions of language design. The series is geared toward developers who know Java and how its abstractions work but have little or no experience using a functional language.

Series of introductory articles that explain basic concepts like higher-order functions, closures, etc. Check also the second part: http://www.ibm.com/developerworks/java/library/j-ft2/index.html

Scala – a cross between object oriented and functional programming that runs atop at the Java Virtual machine – edged Java on runtime, and it had a smaller code size and a smaller memory footprint. But it still shares some of Java's limitations. "Scala['s] concise notation and powerful language features allowed for the best optimization of code complexity," the paper reads. "The Java version was probably the simplest to implement, but the hardest to analyze for performance. Specifically the effects around garbage collection were complicated and very hard to tune. Since Scala runs on the JVM, it has the same issues."

Well I just started this little jaunt into Scala.  The book I got through Amazon (Kindle App) is “Beginning Scala” by David Pollak.  I spoke with David when discussing whether Lift was a good fit for a project I have.  Now I am reading his book.

The book was written for an earlier version of Scala. Namely; Scala 2.7.8.  I am using it under 2.8.0.  There are some differences in how some of the methods are applied, and what they return.  Most notably was the input.getLines method in the ‘sum.scala’ example.

The error when executing sum.scala

# scala sum.scala
/home/scala/sum.scala:20: error: missing arguments for method collect in trait Iterator;
follow this method with `_’ if you want to treat it as a partially applied function
val lines = input.getLines.collect
                           ^
one error found

What you need to do is add a .toSeq at the end for

val lines = input.getLines.toSeq

Whole file

import scala.io._

def toInt(in: String): Option[Int] =
        try {
                Some(Integer.parseInt(in.trim))
        }
        catch {
                case e: NumberFormatException => None
        }

def sum(in: Seq[String]) = {
        val ints = in.flatMap(s => toInt(s))
        ints.foldLeft(0)((a,b) => a + b)
}

println(“Enter Some Numbers and Press CTRL+D”)

val input = Source.fromInputStream(System.in)

val lines = input.getLines.toSeq

println(“Sum “+sum(lines))

Run it on your box, and it should ask you for some numbers and sum them up for ya.  As David puts it ” [this program] makes use of many of Scala’s features including function passing, immutable data structures, and type inference.”

I think I am going to have fun learning Scala.

Great, stumbled already on my first problem when using David Pollak's Beginning Scala :) Apparently just a minor change in the language.

The Monad Pattern

Any time you start with something which you pull apart and use to compute a new something of that same type, you have a monad. It’s really as simple as that. If it sounds like I’m describing almost all of your code, then good, that means you’re starting to catch on. Monads are everywhere. And by “everywhere”, I do mean everywhere.

Also worth checking the Monad wikipedia page: http://en.wikipedia.org/wiki/Monad_(functional_programming)