- A Developer’s Journey from Object Oriented to Functional Programming, by Reid Evans
- Async Everywhere!, by Stephen Cleary
- Deep Dive into Deep Learning, by Gary Short
- Functional Browser Automation Testing for Newbs, by Bryan Arendt
- Programs that Write Programs: How Compilers Work, by Craig Stuntz
- Recognizing patterns in noisy data using trainable ‘Functional’ State Machines, by Faisal Waris

- Erlang, or How I Learned to Stop Worrying and Let Things Fail, by John Daily
- Functional Programming Basics in ES6, by Jeremy Fairbank
- Genetic Algorithms in Rust, by Raymond Chandler III
- Scala: the pointy bits, by Nathan Dotz
- We Got the Func—Python Functional Programming, by Brian Costlow
- Well Behaved Elixir, by Chris Keathley

- 7 Languages in 7 Hours, by Amber Conville

Improving is hiring developers and talented QAs in the Columbus area. It’s a nice place to work. We do interesting stuff. If that sounds good to you, talk to me! We don’t have remote positions at this time, but I’m trying to make that happen. Stay tuned!

**Programs that Write Programs: How Compilers Work**Dog Food Conference and CodeMash**What Testing Can Never Do and How to Do It Anyway**Dog Food Conference**Machine Learning with Azure ML**CloudDevelop

`StringLengthAttribute`

, but you have to write code in `OnModelCreating`

to indicate a `CHAR/NCHAR`

fixed length field:

public classMyEntity { [Key]public intId {get; set;} [StringLength(2)]public stringFixedLengthColumn {get; set;} }public partial classMyContext : DbContext {public virtualDbSet MyEntities {get; set;}protected override voidOnModelCreating(DbModelBuilder modelBuilder) {if(modelBuilder == null)throw newArgumentNullException("modelBuilder"); modelBuilder.Entity() .Property(e => e.FixedLengthColumn) .IsFixedLength(); } }

I find it a bit confusing to split configuration like this, especially with a real model containing lots of fields and not this trivial example. Fortunately, you can fix it! Add these:

`/// <summary> /// Used to mark entity properties that are fixed length strings (CHAR(n) DB fields). /// </summary> [AttributeUsage(AttributeTargets.Property | AttributeTargets.Field, AllowMultiple = false, Inherited = true)]`

public sealedclass FixedLengthAttribute : Attribute {}public classFixedLengthAttributeConvention : PrimitivePropertyAttributeConfigurationConvention {public override voidApply(ConventionPrimitivePropertyConfiguration configuration, FixedLengthAttribute attribute) { configuration.IsFixedLength(); } }

And change the model configuration to:

]]>

public classMyEntity { [Key]public intId {get; set;} [StringLength(2), FixedLength]public stringFixedLengthColumn {get; set;} }public partial classMyContext : DbContext {public virtualDbSet MyEntities {get; set;}protected override voidOnModelCreating(DbModelBuilder modelBuilder) {if(modelBuilder == null)throw newArgumentNullException("modelBuilder"); modelBuilder.Conventions.Add<FixedLengthAttributeConvention>(); } }

When you leave Lambda Jam and return to work, do you expect to apply what you’ve learned here to hard problems, or is there just never time or permission to venture outside of fixing “undefined is not a function" in JavaScript? Many of us do use functional languages, machine learning, proof assistants, parsing, and formal methods in our day jobs, and employment by a CS research department is not a prerequisite. As a consultant who wants to choose the most effective tool for the job and keep my customers happy in the process, I’ve developed a structured approach to finding ways to use the tools of the future (plus a few from the 70s!) in the enterprises of today. I’ll share that with you and examine research into the use of formal methods in other companies. I hope you will leave the talk excited about your job!

For Columbus friends who can’t make it to Chicago, I’ll be rehearsing the presentation this coming Saturday at 3.

]]>Write a Ruby program that determines the smallest three digit number such that when said number is divided by the sum of its digits the answer is 20.

In case that’s not clear, let’s pick a number, say, 123. The sum of the digits of 123 is 6, and 123/6 = 20.5, so 123 is not a solution. What is?

Here’s some Ruby code I wrote to solve it:

defdigitSum(num, base = 10) num.to_s(base).split(//).inject {|z, x| z + x.to_i(base)}enddefsolution (100..999).step(20).reject {|n| n / digitSum(n) != 20 }.firstendputs solution

Problem solved, right?

Well, no. For starters, it doesn’t even execute. There’s a really subtle type error in this code. You probably have to be fairly good with Ruby to figure out why without actually running it. Even when fixed, the cognitive overhead for understanding the code to even a simple problem is very high! It doesn’t look like the problem specification at all.

Does this version, when the bug is fixed, actually produce a correct answer to the problem? Does it even produce an incorrect solution? It’s not quite clear.

So maybe my solution isn’t so good. But one of my colleagues had an interesting solution:

defthe_solution 180end

Well, that looks really, really efficient, and it typechecks. But is it the correct answer? Will you know, six months down the road, what question it’s even trying to answer? Tests would help, but the word "smallest" in the problem turns out to be tricky to test well. Do you want methods like this in code you maintain?

Is there a solution which is as efficient as just returning 180 but which also proves that 180 is, in fact, the correct solution to the problem? Let’s encode the specification for the problem in a pure specification language, SMT-LIB:

`(`

define-funmatches-problem ((n Int)) Bool (and (>= n 100) (< n 1000) ; three digits (= 20.0 (/ n (digit-sum n)))))

Z3/SMT-LIB doesn’t ship with a `digit-sum`

function, so I had to write that. You can find that code in the full solution, below.

That’s most of the problem, but not quite all. We also have to show that this is the smallest solution. So let’s also `assert`

that there exists a "smallest" solution, which means that any other solution is larger:

`(`

declare-constnum Int) (assert(and (matches-problem num) ; "num" is a solution (forall ((other Int)) (implies (matches-problem other) (>= other num))) ; any "other" solution is larger ))

Now let’s ask Z3 if this specification even makes sense, and if it could be reduced into something more efficient:

`(`

check-sat) (get-model)

And Z3 replies…

`sat (model (define-fun num () Int 180) )`

A round of applause for the theorem prover, please! To see the full solution, try it yourself without installing anything.

One interesting point here: The output language is SMT-LIB, just like the input language. The "compile" transforms a provably consistent and more obviously correct specification into an more efficient representation of the answer in the same language as the input. This is especially useful for problems which do not have a single answer. Z3 can return a function matching a specification as easily as it can return an integer.

What does it mean when I ask "if this specification even makes sense?" Well, let’s say I don’t like the number 180. I can exclude it with an additional `assert`

:

`(`

assert(> num 180))

This time, when I `check-sat`

, Z3 replies `unsat`

, meaning the model is not satisfiable, which means there’s definitely no solution. So 180 is not only the smallest solution to the original problem, it turns out to be the unique solution.

Formal methods can show that your problem specifications are consistent and that your implementation is correct, and they can also guarantee that "extreme" optimizations are correct. This turns out to be really useful in real-world problems [PDF].

]]>`> f [1; 2; 3];;`

valit : (int * int list) list = [ (1, [2; 3]) (2, [1; 3]) (3, [1; 2]) ]

Here’s the implementation I’m using:

letf (items : 'T list) =let recimplementation (start : 'T list) =function| [] -> [] | item :: tail -> (item, start @ tail) :: implementation (start @ [ item ]) tail implementation [] items

Anybody know a standard name for this function?

In case you’re curious, the reason I want this is I’m implementing a decision tree. I have a list of functions which are predicates over the domain of my example data. I need to try each function in the list, pick the "best", and then recurse over the rest of the functions. "Best" is usually measured in terms of information gain.

It’s never a great idea to do equality comparisons on functions, so it’s helpful to transform this list into a list of functions paired with the remaining functions.

]]>What if simply writing "unit tests" was enough to produce a program which makes them pass? What if your compiler could guarantee that your OpenSSL replacement follows the TLS specification to the letter? What if you could write a test which showed that your code had no unintentional behavior?

Microsoft Research is well known for its contributions to Kinect, F#, the Entity Framework, WorldWide Telescope, and more, but it’s also the home of a number of programming tools which do things which many programmers would consider surprising, if not impossible. But they work, and in this session you’ll see them in action.

Like the idea of code contracts, but concerned about runtime performance and errors? The Dafny language can check contracts at compile time. Sounds a bit magical, but it works! I’ll use the Z3 theorem prover to generate working programs from specifications alone. Sound impractical? I’ll explain how it is used to make Hyper-V and Windows Azure secure. I’ll show the F7 specification language for F# and relate how its authors used it to not only produce a TLS implementation which probably follows the spec, but to also identify dangerous holes in the TLS specification itself. You’ll learn how Amazon uses the TLA+ specification language to prove that there are no edge cases in its internal protocols.

Far from being research toys, these tools are in daily use in cases where stability, security, and reliability of code matters most. Can they help with your hardest problems? You might be surprised!

]]>I’ve written about proving systems in the past, and will have more to say in the future, but today we’ll talk about homomorphic encryption.

Homomorphic encryption will change the web in the same way that SSL/TLS did. I say this with quite a bit more confidence than I have in the past! If you remember the web in 1993, that’s interesting to you. If not, imagine the web as a magazine which could show you ads, but required calling an 800 number if you wanted to make a purchase, and contrast that with today’s amazon.com.

I have given two presentations with similar titles before. But this presentation will be an almost complete rewrite, just like the last. In the time since my first article on homomorphic encryption, it’s gone from a gleam in a mathematician’s eye to an open source DB access library. It’s a fast-moving technology, which, thankfully, becomes more practical each year.

Interestingly, as the technology for cloud security becomes more practical, the need for it becomes more pressing.

CloudDevelop 2014 is just $20, which is quite cheap, as conferences go, but you can use this link to save 50%, which means that for the $10 you might have spent for lunch that day you get a conference for free!

]]>Here’s the problem I’ll use as an example, which is problem #4 from the Project Euler:

A palindromic number reads the same both ways. The largest palindrome made from the product of two 2-digit numbers is 9009 = 91 × 99.

Find the largest palindrome made from the product of two 3-digit numbers.

The usual approach is to use brute force. Here’s a C# example, which I suspect is similar to what many people do:

`(`

, Factor2 = factor2, Product = product}).First()fromfactor1inEnumerable.Range(100, 899)fromfactor2inEnumerable.Range(100, 899)letproduct = factor1 * factor2whereIsPalindrome(product)// defined elsewhereorderbyproductdescendingselect new{ Factor1 = factor1

This is not a terrible solution. It runs pretty quickly and returns the correct solution, and we can see opportunities for making it more efficient. I suspect most people would declare the problem finished and move on.

However, the LINQ syntax may obscure the fact that this is still a brute force solution. Any time we have to think about how to instruct a computer to find the answer to the problem instead of the characteristics of the problem itself, we add cognitive overhead and increase the chances of making a mistake.

Also, what is that `IsPalindrome(product)`

hiding? Most people implement this by converting the number to a string, and comparing it with the reversed value. But it turns out that the mathematical properties of a palindromic number are critical to finding an efficient solution.

Indeed, you can solve this problem fairly quickly with pencil and paper so long as you don’t do `IsPalindrome`

this way! (It would probably double the length of this post to explain how, so I’ll skip that. If there’s demand in comments I can explain, otherwise just read on.)

For my purely declarative solution, I’m going to use the language SMT-LIB. As a pure specification language, it doesn’t allow me to define an implementation at all! Instead, I’ll use it to express the constraints of the problem, and then use MSR’s Z3 solver to find a solution. SMT-LIB uses Lisp-like S-expressions, so, yes Virginia, there will be parentheses, but don’t let that scare you off. It’s always worthwhile to learn languages which make you think about problems differently, and I think you’ll find SMT-LIB really delivers!

Since this language will seem unusual to many readers, let’s walk through the problem step by step.

First, we need to declare some of the variables used in the problem. I use "variable" here in the mathematical, rather than software, sense: A placeholder for an unknown, but not something to which I’ll be assigning varying values. So here are three variables roughly equivalent to the corresponding C# vars above:

`(`

declare-constproduct Int) (declare-constfactor1 Int) (declare-constfactor2 Int)

In an S-expression, the first item inside the parentheses is the function, and the remaining items are arguments. So

is the function here and the remaining items are the variable name and its "sort" (type).**declare-const**

Next, the problem says that `product`

must be the, ahem, product of the two factors:

`(`

assert(=(*factor1 factor2) product))

"

" sounds like a unit test, doesn’t it? Indeed, many people coming to a theorem prover from a software development background will find that programming them is much more similar to writing tests than writing code. The line above just says that **assert**`factor1 * factor2 = product`

. But it’s an assertion, not an assignment; we haven’t specified values for any of these variables.

The problem statement says that both factors are three digit numbers:

`(`

assert(and(>=factor1 100) (<=factor1 999))) (assert(and(>=factor2 100) (<=factor2 999)))

Mathematically, what does it mean for a number to be a palindrome? In this case, the largest product of 3 digit numbers is going to be a six digit number of the form **abccba**, so product = 100000**a** + 10000**b** + 1000**c** + 100**c** + 10**b** + **a**. As I noted above, expressing the relationship this way is key to finding a non-brute-force solution using algebra. But you don’t need to know that in order to use Z3, because Z3 knows algebra! All you need to know is that you should express relationships mathematically instead of using string manipulation.

`(`

declare-consta Int) (declare-constb Int) (declare-constc Int) (assert(=product (+(*100000 a) (*10000 b) (*1000 c) (*100 c) (*10 b) a)))

I implied above that **a**, **b**, and **c **are single-digit numbers, so we need to be specific about that. Also, **a** can’t be 0 or we won’t have a 6 digit number.

`(`

assert(and(>=a 1) (<=a 9))) (assert(and(>=b 0) (<=b 9))) (assert(and(>=c 0) (<=c 9)))

These 4 assertions about a, b, and c are enough to determine that product is a palindrome. We’re not quite done yet, but let’s see how we’re doing so far. `(`

asks Z3 if there is a solution to the problem we’ve posed, and **check-sat**)`(`

displays that solution. Here’s the entire script so far:**get-model**)

`(`

declare-constproduct Int) (declare-constfactor1 Int) (declare-constfactor2 Int) (assert(and(>=factor1 100) (<factor1 1000))) (assert(and(>=factor2 100) (<factor2 1000))) (assert(=(*factor1 factor2) product)) (declare-consta Int) (declare-constb Int) (declare-constc Int) (assert(and(>=a 1) (<=a 9))) (assert(and(>=b 0) (<=b 9))) (assert(and(>=c 0) (<=c 9))) (assert(=product (+(*100000 a) (*10000 b) (*1000 c) (*100 c) (*10 b) a))) (check-sat) (get-model)

When you run this through Z3 (try it yourself!), the solver responds:

`sat (model (define-fun c () Int 1) (define-fun b () Int 0) (define-fun a () Int 1) (define-fun product () Int 101101) (define-fun factor2 () Int 143) (define-fun factor1 () Int 707) )`

That’s pretty good! `sat`

, here, means that Z3 found a solution (it would have displayed `unsat`

if it hadn’t). Eliding some of the syntax, the solution it found was 143 * 707 = 101101. Not bad for zero implementation code, but also not the answer to the Project Euler problem, which asks for the *largest* product.

"Optimization," in Z3 parlance, refers to finding the "best" proof for the theorem, not doing it as quickly as possible. But how do we tell Z3 to find the largest product?

(**Update: **I had a mistake in the original version of this post, and so I’ve significantly changed this section.)

Z3 has a function called `maximize`

, but it’s a bit limited. If I try adding `(`

, Z3 complains:**maximize **product)

`Z3(15, 10): ERROR: Objective function '(* factor1 factor2)' is not supported`

After some fiddling, however, it seems `(`

works, sort of. Adding this to the script above causes Z3 to return:**maximize **(**+ **factor1 factor2))

`(+ factor1 factor2) |-> [1282:oo] unknown --...`

Which is to say, Z3 could not find the maximal value. ("oo" just means ∞, and `unknown`

means it could neither prove nor disprove the theorem.) Guessing that **a** might be bigger than 1, I can change its range to 8..9 and Z3 arrives at a single solution:

`(+ factor1 factor2) |-> 1906 sat (model (define-fun b () Int 0) (define-fun c () Int 6) (define-fun factor1 () Int 913) (define-fun factor2 () Int 993) (define-fun a () Int 9) (define-fun product () Int 906609) )`

The final script is:

`(`

declare-constproduct Int) (declare-constfactor1 Int) (declare-constfactor2 Int) (assert(and(>=factor1 100) (<factor1 1000))) (assert(and(>=factor2 100) (<factor2 1000))) (assert(=(*factor1 factor2) product)) (declare-consta Int) (declare-constb Int) (declare-constc Int) ((assert(and(>=a 8 ) (<=a 9)))assert(and(>=b 0) (<=b 9))) (assert(and(>=c 0) (<=c 9))) (assert(=product (+(*100000 a) (*10000 b) (*1000 c) (*100 c) (*10 b) a))) (maximize(+factor1 factor2)) (check-sat) (get-model)

This bothers me just a little, since I had to lie ever so slightly about my objective, even though I did end up with the right answer.

That’s just a limitation of Z3, and it may be fixed some day; Z3 is under active development, and the optimization features are not even in the unstable or master branches. But think about what has been achieved here: We’ve solved a problem with nothing but statements about the properties of the correct answer, and without any "implementation" code whatsoever. Also, using this technique forced me to think deeply about what the problem actually meant.

At this point, you may have questions about doing software development in this way. Sure, it works fine for this trivial problem, but can you solve real-world problems this way? Is it fast? Are there any other tools with similar features? What are the downsides of working in this way? You may find the answers to these questions as surprising as the code above. Stay tuned!

]]>Homepage · Slides · Presentation

One of the ways that you can describe a coding style is declarative versus imperative. That is, focusing on the desired result versus focusing on how that result should be computed, respectively. Walter Wilson’s axiomatic language attempts to take the former approach as far as possible. It is a pure specification language which attempts to provide a means for exhaustively specifying the output of a program. As such, it is more comparable with specification languages like TLA+ than with programming languages designed around the idea of producing an executable.

If you can specify every property or every possible input and output desired from a system, then you might be able to write a program which could read that specification and produce a program which implements it. In fact, dependently typed languages like Agda can do this today in a more limited capacity.

Actually building such a working system, Walter concedes, is a challenge! I’ll talk more about that challenge in a moment, but first let’s take a look at what he has actually built. I am not aware that there is any working software here; at this point, the project is just the grammar. The semantics include axioms and expressions. Axioms generate valid expressions. The syntax includes four elements:

- Atoms: `abc, `+
- Expression variables: %w, %3
- String variables: $, $xyz
- Sequences:(), (`M %x (`a $2))

Now you can use these to build axioms, with the following syntax:

`<conclu> < <cond1>, …, <condn>. <conclu>. ! an unconditional axiom`

Axioms produce axiom instances, where values are substituted for the axiom variables. Axiom instances produce valid expressions. If the conditions of an axiom instance are valid expressions, then the conclusion is a valid expression. The examples are somewhat lengthy, so I will refer you to the axiomatic language homepage, which includes many sample programs.

This was a very thought-provoking presentation. When I listened to many of the other speakers, I often had mental reactions like, "Hey, that’s a really useful thing!" or "That’s not my cup of tea." When I listened to Walter’s presentation, however, my reactions were more along the lines of, "Is this even possible?" and "If so, is it a good idea?" (In a good way!) I really don’t know the answers. When I spoke with Walter later, thanking him for making me think, he asked me if I thought that an implementation of such a system would be possible. My gut reaction is that, much like termination analysis, the general answer is no, but it might be possible to handle enough specific, useful cases to produce a usable system anyway.

Axiomatic language is clearly useful as an intellectual exercise. Would it also be useful as a practical system? As an industry, I don’t think we know very much about writing great specs. My gut feel is that it is harder to write a spec which is so complete that it can be used to produce a functional system than it is to write correct code. It is usually harder to work at a higher level of abstraction, though it’s often worth the effort!

Although Walter claims that specifications are "smaller & more readable than algorithms," my conclusion is not so clear-cut. Compare this sort in Haskell with Walter’s specification for a sort in axiomatic language. In general, when I look at Walter’s examples, I think it is fair to say that the claim that the specifications would be smaller and more readable than algorithms is, at best, debatable. Very expressive code in a contemporary, high level language, in my opinion, can do better, without introducing too much inessential imperative overhead. You can also compare Walter’s natural number addition from his slide deck with this example in Agda. The advantage of a specification over an implementation, I think, is that specifications can be free of implementation details.

These examples are not a perfect comparison. I would point out that the axiomatic language sort specification there is incomplete because it does not specify performance or space boundaries. Also, the Haskell version does not specify ordering relations, but Walter’s example does. Nevertheless, when I read the Haskell version I can clearly see what is going on, both in terms of what the result will be and I have some idea of the amount of time it will take. I can see the result fairly clearly in Walter’s version, but it takes a good bit more reading. And I have no idea how long it will take.

Actually, I don’t even know how long the sort should take, because that probably depends upon the application. A more complete specification might include information about the expected length of the input and an upper bound on time, available memory, etc. But such details, while important, bring us dangerously close to specifying an algorithm, which is exactly what Walter is trying to avoid!

For more complicated, but still realistic, problem domains ("I need a program which will calculate the correct income tax for any US citizen."), I rather doubt that a complete specification, sufficient to produce a working program, is even possible. The US tax code, vague in some places and self-contradictory in others, certainly would not provide enough information to do such a thing. However, it would still be useful if you were able to somehow translate the US tax code into a machine-readable specification, in order to test the program you produced by other means. There may be subsets of the tax code which are deterministic and it’s probably useful to verify implementations of these via machine-assisted proof.

One might at first be tempted to confuse programming via specification with waterfall, but these methodologies are orthogonal, I think. You can develop a specification in an agile manner, just like you can do waterfall without a formal specification.

Axiomatic language also reminds me of the philosophical languages of the 17th century, which attempted to produce minimal, concise grammars in which it was impossible to make an incorrect statement. Where axiomatic language differs from all of these is the as yet unfulfilled intention of enabling a system by which a program can be automatically generated (as opposed to "merely" checking satisfiability).

In the next post in this series I’ll discuss Matt Graham’s qbert bytecode.

]]>