I’ve recently returned from CodeMesh conference in London. Here are my impressions.
Good: it made me realize we can actually use Amazon Lambda in our projects. Especially with the servers that have little to no traffic on them.
Bad: It wasn’t really a Dev thing, it was more of an Ops thing. Also, it turned out that following their instruction cost attendees money — not much, but I would appreciate being warned to delete the created Kinesis stream afterwards, since it keeps chugging away money even if unused.
Good: not so much actually.
Bad: First of all, it wasn’t a tutorial. It was a talk. Surely, attendees were provided with Jupiter notebooks that were supposed to let them play with the database the speakers were talking about. In reality, those notebooks simply didn’t work at all (I managed to make one of three work, but had to give up on others), and even one of the speakers admitted having lots of problems trying to use them. Why they went with those notebooks anyway instead of, say, simple CUI, is anyone’s guess.
Secondly, I’m pretty sure I’ve heard most of that stuff before. Looks like Nuno Preguiça talks about the same stuff over and over again.
That was a disaster.
Hewitt started with a fairly common stuff: Actors model. Then he made some eyebrow-raising comments about inheritance being bad for security (because “anybody can pretend to be you”). After that he quickly descended into incoherent ramblings about military hackers, hologlasses (whatever that means), and, I kid you not, gender identity.
I quite understand that, if Carl Hewitt wants to give a talk at your conference, you are legally prohibited from saying “no”. But it was definitely the lowest point in the whole conference.
That was fun.
For those readers who are not sure what this even means: for example, in Scala you can have, say, a Proxy type defined as ‘class Proxy[T]’. Then we can have instances of ‘Proxy[Int]’, or ‘Proxy[String]’, or ‘Proxy[List[Int]]’, or ‘Proxy[List[String]]’. But we can’t have ‘Proxy[List]’ — because the type ‘List’ is of the wrong kind: it doesn’t itself has any values (there is nothing of type ‘List’), but instead acts as a type-level function: you apply it to some type that has values (like ‘Int’) and get a type that also has values (‘List[Int]’).
This might seem pointless, but actually appears a lot in various generic programming libs.
Anyway, seems like Sabin’s work made it into Dotty, so, at some point we might see it in production.
That was... strange. I expected some advanced math, but Lopez kept walking in circles around the topic, never addressing it directly. I think the talk as it was could be boiled down to “you can look at the distributed system as a topological object, and it might help you”, but there wasn’t a single word about how.
This was mostly an opinion — which features of F# make the code cleaner or not. My main takeaway is that our company’s developers are generally smarter than Don Syme: we consider ‘fold’ to be easy enough and do not replace it with imperative loops, although those are, of course, possible in Scala.
That could be quite interesting — that was about actual physical robots, completing certain tasks (Chechina’s go-to example was robots doing rescue work after some natural disaster) and actually helping each other, providing the estimated cost of actually getting there where the help is needed does not make the help completely pointless. It would be more impressive if Chechina would actually present some robots implementing her strategies, or at least a video of them, but as she herself admitted, implementing it on a real hardware proved to be more difficult than expected.
That was controversial. Bailly and Schwartz argued that logging should be a) structured, using JSON instead of strings, and b) unified, with exactly one log stream that is later filtered and fed into different systems — be it Datadog (both metrics and events), or Logentries, or something else. Which might make sense, but I think it also means creating a lot of intermediate infrastructure, which might not ever pay off.
Fun. First of all, spirographs; this Google Images find gives a rough idea of what it is and does:
Harding made a nice intro into PureScript, choosing the task of generating spirograph images programmatically.
Fisher used to work for DARPA, and talked about using formal methods to create an impossible-to-break code for drones: one commercial, that they bought from Amazon, and one military. In particular, they hired a group of hackers, who managed to break into both drones without much difficulty... before the software was altered by Fisher and others. When the software was rewritten and verified using formal methods, they couldn’t do that, despite being given full source code and even direct access to some non-critical systems, like camera control. They even allowed those hackers to work on the military drone while it was flying.
This actually seems to be exactly the case where formal methods should be used: where the increased price of the software is way lower than the potential cost of a mistake.
This was, mostly, a progress report. Banek is working on a distributed graph database, and he was talking about how it works internally. Which seems somewhat interesting, but mostly reinforced the general belief that MySQL would live long and prosper.
This was about declarative generative art (which, IMNSHO, is not art at all, but still fun). Apparently, most generative art is created using an ugly imperative programming language called “processing”. Goncalves created her own engine, and, since she wasn’t shy of using words like “Monad” or “Applicative”, that actually has a lot of chances to be good (and not a lot of chances to become mainstream). Unfortunately, the GitHub repo for that is still private.
That was interesting for, it seems, unintended reasons. Coglan talked about handling breaking changes in Node.js projects; however, most of his talk was about changes that would be easily caught by the type system. That is, if Node.js (his primary tool) had one. So, basically, the (unintended) message was: use something better.
Wayne talked about property-testing distributed systems, which is apparently what TLA+ does. It seems to me, however, that you need to implement pretty much all of your system in TLA+ itself, which essentially doubles the workload and is very easy to get wrong. Also, I’m not sure how it would work if a bug is there but requires millions of steps to reproduce. It might just gives us thumbs-up.
On the other hand, Wayne convinced me to read more about this TLA+ system.
Also quite fun. Most of the talk was a live demo; Brady is currently developing Idris 2 in Idris, and is apparently quite confident in how it works. Probably the nicest feature there is the addition of linear types: they guarantee that some argument of a function must be used by that function exactly once. Surprisingly, it makes a lot of programs/proofs in Idris much easier.
Strange. Eta appears to be a port of Haskell to JVM, which is nice; and it contains some FFI, mapping Java types to Haskell types. However, when I asked Patnam how inheritance is represented (there is no inheritance in Haskell, although Oleg Kiselyov managed to add something similar), she just couldn’t understand the question. She also mentioned her own latest contributions: apparently, when you program compiles without errors, you get a nice pat on the back by the compiler, saying, in green letters, “you did great, happy hacking”. Really?
I have to admit, I skipped this one. I’ve seen enough of such talks and have a certain bias against those who talk about ethics on technical conferences.
Sabin’s talk about Scala, Harding’s spirographs, Fisher’s formal methods, Goncalves’ generative “art”, Brady’s talk about Idris. Overall, a pretty good conference.