{"id":1347,"date":"2013-09-22T14:05:32","date_gmt":"2013-09-22T14:05:32","guid":{"rendered":"http:\/\/www.syslog.cl.cam.ac.uk\/?p=1347"},"modified":"2013-09-23T15:11:09","modified_gmt":"2013-09-23T15:11:09","slug":"liveblogging-cufp-2013","status":"publish","type":"post","link":"https:\/\/www.syslog.cl.cam.ac.uk\/2013\/09\/22\/liveblogging-cufp-2013\/","title":{"rendered":"Liveblogging CUFP 2013"},"content":{"rendered":"

I'm here at the Commercial Users of Functional Programming<\/a> workshop at ICFP 2013<\/a>) with Heidi Howard, David Sheets and Leo White.<\/p>\n

\"marius1\"<\/p>\n

Marius Eriksen and Michael Sperber are co-chairing this year. Functional programming is a hot topic these days, and this\u00c2\u00a0year's program reflects the maturing nature of the program. Record number of submissions, and we could easily have made this a multi-day\u00c2\u00a0program. \u00c2\u00a0Videos will be available online after the event.<\/p>\n

Keynote is from Dave Thomas<\/a> on what we can learn from the \"language wars of the past\". \u00c2\u00a0His talk will cover the business, social and technical ends of building Smalltalk and his \"objaholic\" experiences with pushing language technology into businesses, where they never had any intention of changing in this regard. \u00c2\u00a0This worked over the years because it made a material difference to these businesses. \u00c2\u00a0Dave still uses the K<\/a> programming a lot at work.<\/p>\n

<\/p>\n

\"clark1\"<\/a><\/p>\n

Dave is responsible for the Eclipse IDE and the IBM Java virtual machines, and has delivered software on everything from mainframes to wristwatches.<\/p>\n

Rush in the 70s with Symbolics and the amazingly cool hardware, followed by the rush to logic programming that led to his grants disappearing. Midway through the 80s, they discovered we wouldnt get parallelism for free with all this magic. After that came the era of machine learning and knowledge ontology crusades, but they are very specialised bits of tech. There remain sectors where ontologies are useful. Nowadays its the multicore crusades, and FP is emerging as useful.<\/p>\n

Every road leads to some form of FP, because the principles underlying it apply. Dave does vector programming, Haskell does this with array transformation.<\/p>\n

Dave was talking to Simon PJ outside and claimed that \"FP has won!\", at which point Simon replied \"really?\" (laughter). OO techniques can also lead to a lot of tangled code: witness the evolution of Smalltalk to the current generation of languages.<\/p>\n

FP technical challenges: what happens when you have a lot of functions, and a group of consenting adults are doing it together. This is called software engineering, or at worst, IT!<\/p>\n

Lots of good work in the community on approaching large scale programming. Scala is a bit too complex for Dave (and audience rumbles in agreement or disagreement?). Java and JNI should just die. Erlang and actors are successful to decouple software. But do we really need to hide all our queues, and do we really need to hide our queues? Static analysis of queues are desired.<\/p>\n

Want to go fast? Computers like rectangles, all the way down! Array operations and vector processing is the way to go in the long-term.<\/p>\n

To go to industry, we need end-to-end toolchains. If you use MS Project, then you probably shouldn't introduce any new tools.<\/p>\n

The first commercial customer for Smalltalk in the 1980s was Techtronix, who wanted to embed reusable tech in their oscilloscopes. If you're building a serious product like this, it needed language interop between C++ (the logic sensor) and the Smalltalk. Respect the language cultures among components (anyone remember s-records?). ROM had to be replaced with Flash because noone can write code that doesn't need upgrading (groans from the audience).<\/p>\n

With the right tools, programmers will be able to go as quickly as Smalltalk, or at worse Java. We need the work of Simon [PJ] and colleagues on Haskell. Scala is so complex will become the Java (which is the Cobol of tomorrow).<\/p>\n

When shipping products, you need to track all the versions of language components in the toolchain. Too many FP toolchains are monolithic and make it hard to track components in the field. JVMs are so slow because they don't have a good sharing model (DLLs).<\/p>\n

What Dave would like is version-to-version transformation in languages. Y2K was a problem not because IBM hadn't fixed it in their OS, but because customers had modified their local installations and were pinned 6-10 versions behind! The same will happen for existing FPs that fragment into multiple implementations, so will they descend into multiple version hell or will standards emerge from the community?<\/p>\n

Also, lets not leave the data behind. Can we alias data from existing legacy sources into our new languages, and not aim for the perfect representations? Most of our programs are dealing with problems with existing data, not code.<\/p>\n

Onto deployment issues. Erlang works very well for the problem domain that it's designed for, but more complex domains exist like OSGI. Hot codeswap and live updates are often viewed as \"boring problems\" but are vital to real world deployments. Space usage must be paid attention to: how long can a given JVM stay up without leaking? Serialization is important to persist data across versions. If we're going to use \"esoteric control structures\" like CallCC, tailcalls or tags, the JVM isn't going to get us there.<\/p>\n

These days, if you can't stay in your local cache, you will lose several orders of magnitude performance... you'll need directly connected CPU (or SSD!) memory, and static initalization, and language interop (eagerly vs laziness). Functional data structures and immutable collections are still immature, but need more work to convince doubting Thomas' about their scalability in real applications.<\/p>\n

Hardware support for these are important. Intel Haswell has hardware transaction support (hence can be used by Azul JVMs etc) but we need more for functional langauge performance. There have been $2bn put into speeding up the JVM to make it as fast as C++. Google has a technology called Pinnacle which uses software write barriers that use VMs that execute directly, with a register model and not a stack model (which is easy to put together but hard to make fast). The new generation of language VMs will support direct execution and support modern functional programming languages.<\/p>\n

\"We all love types\" -- Dave on objects, but not variables (\"its easy to be cooperative with that definition!\"). Pluggable types by Gilad are really cute, because they move us towards a world where particular features (Dave likes behavioural types) can be woven in. Perhaps can be done in a dependently typed world. Another good candidate are approximate types and dimensional types. When all these are put together though, it all needs to fit together with sound compositional semantics.<\/p>\n

When using an interesting PL, Dave wants warnings to be emitted when the compiler makes space\/time tradeoffs so that the programmer can decide between elegance and performance (also mentioned that Haskell programmers do this for .<\/p>\n

How does language evolution work? Arthur Whitney maintains K, and he ensures that every version of K is incompatible with the previous one. This is a blessing (!) since it avoids a kitchen sink language and ensures a high quality set of libraries. Quite often there's a tussle between languages and libraries because there's not enough coevolution. For example, are closures in Java really useful for the tradeoff in the complexity of the VM? Perhaps we should be looking towards a collection of small correct languages instead of a few partly right and largely wrong languages such as Ada or Java (the Java hate is strong here -- editor).<\/p>\n

Those of us that have programmed in vector languages (going back to APL) are largely write once read once languages because the code is so hard to read. One trick Dave does with K is to annotate comments inside expressions and use cold-folding without a point-free style to understand vector codeflow better. Also seeing the environment and current name bindings is extremely useful for teaching new languages.<\/p>\n

The real problem is: comprehensions, folds, monads -- WTF? Yet to see anyone from the monad community give a talk to understand monads. It's typically \"you dont need monads\" and then the word is used multiple times in the talk. If it's not important, why mention it so often? Quite often, the FP experience makes normal programmers feel stupid because they don't break through this terminology barrier. We as a community need to help people break through the barrier of not being formally trained in mathematics for whatever reason (\"category theory for breakfast?\") and *be productive* in FPs.<\/p>\n

Smalltalk was like this in the early days. People see a blank window and aren't sure what to do next. Objects irritated people when they came out, but FP scares people. This is a danger as we go through and wow people with what we can do, but make it look like magic. People change their habits are different rates and we need to understand that. With Haskell, it was odd that he had to get the program \"right\" (or right\/wrong) before it work, as opposed to not working.<\/p>\n

Bill Buxton (UI researcher friend) pointed out that people can't much get beyond programming a VCR. 4GLs were pretty much their limit. Dave's done a lot of work on evangelizing Smalltalk, but feels it was still too hard. People just didn't understand how to separate behavior, as the best practices on how to build objects were foreign to most of them. This all settled on some mix of SQL and some glue code, which doesn't require learning a lot of new technologies.<\/p>\n

Given there are many different types of programmers, do they all really need the full power of FP? Some subset of features is more useful, with one way to do things that doesn't change from release to release. For example, a simple dictionary keeps changing from Hashmap to concurrent Hashmap to something else, but ultimately is still a dictionary. How do we separate the reasoning over performance and structure and not scare people with both at the same time. Knuth started doing this decades ago with literate code, and we *still* dont have a decent way of writing documentation and code in the same place.<\/p>\n

We are still missing a pure FP book that is built in the same style and comprehension as SICP<\/a>. We need thinks that you look the code and represent things more densely (for example, why don't we use Unicode in the same style as APL symbols to increase the succinctness?). They are working on J programs that move glyphs around on the iPad as an example of this 4GL density.<\/p>\n

We need to take all these ideas and *talk more* about metaphors in FP. Where's the \"Scala, F#, Clojure, the good parts\" and a frank exposition about the antipatterns? Don't lie about where the dragons are, but colour code them appropriately to not surprise programmers.<\/p>\n

We need to understand how to design with types. In the vector languages, this is called \"shape shifting\" as they don't have types, but similar concept. It's also hard to get the community people to talk about shape shifting, and as a result the art is being lost in the new generation of languages. For FP, can the Yodas in the audience help their audience to \"trust the types\" ?<\/p>\n

Q: In the top 20 languages, every language has a free-or-open-source runtime. This will make a huge difference as it lets people experiment.<\/p>\n

A: It's not been a barrier in experimentation for Dave, but it has been a barrier for commercial use. Dave would not attribute a particular significance to open source as it's never been a real problem for him (using trial versions and so forth). Open source is a mixed sword, as it tends to product impoverished language teams that don't have enough resources to move forward. The really good virtual machine implementors are commercially polished (c.f. the $2bn behind the JVM performance from earlier). Clojure is a great example where they appealed to the community to pay on their own behalf to donate for a production version. To build a serious production PL, you need a lot of government research money or a major commercial sponsor.<\/p>\n

Q: Marius asks about mobile and embedded and why FP hasn't cracked it.<\/p>\n

A: they are often late to the game, and it's often not easy to target the runtimes with a high performance runtime. You have to be willing to understand the interface.<\/p>\n

Q: Phil Walder says the scariest thing is that if you become a success, then Smalltalk takes the form of C++<\/p>\n

A: (or Java!). Being able to maintain the independence of the language creators vs a major player is crucial to conceptual integrity. (Phil) Tools that will migrate between version X and Y and a sustainable ecosystem. It's important to ensure that the creators get paid to maintain -- even the JVM only has 10-20 people in the core team and a vast ecosystem.<\/p>\n

OCaml at Facebook via the Hack language<\/h3>\n

Julien Verlauget is talking about how Facebook is adopting OCaml.\"1148380_10151682552766094_1789859397_n\"<\/a><\/p>\n

Why PHP is good: fast installation times, lots of libraries, easy to learn, and scales in a parallel way (multiple instances).<\/p>\n

However, Facebook doesn't care about any of these features. What Facebook wants is a fast feedback loop between writing code and having it appear on screen. There's no good way to write a unit test for an experience, and instead a fast feedback loop between code and a live site is how people still work at Facebook today.<\/p>\n

Performance at the scale of Facebook really matters. 1% can be a huge bump, but PHP is really hard to optimize due to all the dynamic features in the language. Aside from runtime performance, the other concern is development time for engineers, who need to avoid security problems and general bugs in an incredibly large codebase.<\/p>\n

The first attempt at this was to scale the runtime via HipHop. The first attempt was to compile PHP into an interpreter (via sandboxes) and then compile production code to C++. Unfortunately this lead to a huge divergence in performance characteristics between the interpreter and compiled code which led to confusion in production.<\/p>\n

The current one is HHVM which is a combined model via JIT runtime that patches code at runtime and helps merge these models.<\/p>\n

HHVM is still a PHP platform, and a new model called Hack provides a *new programming language* that targets HHVM (which is essentially a PHP runtime).<\/p>\n

Hack is a statically typed language for HHVM<\/b>. It's compatible with PHP and interoperates with no overhead and has the same runtime representation as PHP. It has evolved from PHP, and so if you know PHP, you know Hack. It's designed for incremental adoption<\/i> via introducing gradual typing (c.f. keynote talk about not scaring programmers not used to types).<\/p>\n

function foo(): void {\r\n  $x = 'hello';\r\n  return $x;\r\n}<\/pre>\n
This returns a readable error message in the style of a statically typed language, since the inference algorithm keeps a witness about every value's type and shows counter examples.<\/p>\n
The Hack type system must be annotated with class members, function parameters and return types. Everything else is inferred to minimize programmer burden.<\/p>\n
Hack types include:<\/p>\n