I gave Rust a quick go on the weekend. It's more interesting than I thought, I like the idea of everything being an expression and the emphasis on immutable data structures was unexpected but makes sense in light of its co-routine lightweight concurrency.
There is a definite kinship with Go but Rust feels more "modern" at the moment.
I'm not sure I like the inconsistent assignment operators in Go. := is the initialiser operator but then values in mutable collections are assigned with just =
Interoperating Java and Akka's expectations of concurrency seems very difficult. I'm not sure that going async by default is a very human-friendly thing to do.
Starting to play around with React. I found JSX off-putting at first but the reactive paradigm and virtual DOM are pulling me in.
Playing around with the live JSX compiler is also interesting for understand what the value of the syntax sugar is.
I built my own browser for the first time since Gecko back in the late Nineties, I wanted to give the new Servo build a go.
It built pretty quickly and managed to render a test page but with no CSS or Javascript support it seemed to barf on most actual sites.
A few myths about microservices:
After all the praise at Scale Summit (and from other people I respect) I gave the Docker interactive tutorial a bash.
There were a few subtleties that I hadn't grasped like the way that you can "layer" images in the same way you have git commits on a project. Also the container is linked more intimately to the process it runs than I had imagined.
Looks like virtualisation technologies that might actually be usable by the rest of us. Although only running on Linux 3.8 kernels is a bit of blocker at the moment. I would love this on OSX and allow us to get away from the OSX-Linux disconnect.
LightTable's support for Python is not as rich as Clojure's Insta-repl. Things only appear in scope for evaluation if they have been previous evaluated and values only change when they are re-evaluated.
It feels somewhere between Insta-repls and iPython.
Disappointed that Mozilla Persona has failed/"transistioned to the community". It was the one federated identity system that felt like it was genuinely dev-friendly.
It is also a shame to see a new entry in the open source, community-support elephant's graveyard.
Just been playing around with Julia via this quickstart tutorial and wrote a fib function. Win!
Syntax is very Python with optional typing, and blocks denoted by an end keyword.
I'm interested to see Dropbox's new Python JIT Pyston announced. At first I was sceptic about what the value of yet another JIT was (even backed by Guido).
It is interesting to see the directions they are pursuing and it would be good to maybe seem some consolidation in approaches towards a performant general-use Python interpreter.
Do programming languages matter?
I think at the very least it is interesting to see that different languages encourage and prevent different behaviours. Depending on the value you put on those behaviours then it is possible to have a value judgement about a programming language that is not purely aesthetic.
The issue with Google's Cloud offering is that they can't see themselves accurately in the market. They, despite the infrastructure they've set up for themselves, are actually a fast-follow late entrant into the market.
It's not good enought to point at the engineering superiority they may or may not have. They have to realise that developers are going to compare them to the total AWS experience as it stands today. Not how AWS was when it originally started.
Going through the introductions to Angular.JS. On the surface the whole world of factories, controllers and dependency injection seems like a mad trip back to J2EE only this time in Javascript.
Not only that but it's also verbose:
angular.controller('ControllerController', ...)
I'm doing a talk next week about Mori the library of immutable data structures for Javascript and this week Facebook releases... a library of immutable data structures.
Cue panicked reading... fortunately both libraries have interesting areas of overlap and difference. Essentially both use hashmap tries to create immutable structures without cloning. Both appear to unify collections into sequences and their related operations. Both aim to provide simple memory-reference comparison for changes in support of virtual doms and reactive event streams. Both avoid intermediate forms an allocation during transformations.
Immutable.js is smaller in scope that Mori though with less operations available on sequences. It has also taken an object-orientated interface approach to expose the functionality on the immutable collection types. This seems to be the major point of difference so far and also seems an odd design choice as it limits its opportunity for composition.
There seems to be some definite convergence in the Javascript sphere after a period of massive experimentation.
Virtual DOM is a clever idea and here to stay, in fact why not turn it into a proper browser standard?
Two-way databinding doesn't scale and just as with any kind of programming scope and dependencies need to be careful managed. One-way event propagation as per Facebook's Flux pattern may not be the final word on this but it massively clear that simplifying and decoupling change is not optional in complex client-side apps.
I have been taking a quick survey of Clojure web frameworks, particularly in terms of their use (or not of asynchronous handlers).
The leading contenders still seem to be Luminus and Caribou. Hoplon seems to be the new Pedestal for completely Clojure development.
I also came across Joodo which seems to be a new framework focussing on middleware features.
So the short summary is that all of these frameworks use Jetty and a lot of their functionality seems bound up with lein ring integration so switching Jetty for HttpKit does not seem trivial.
There seems to be three ways of doing async web requests in Clojure: ring-async which uses Jetty's async features, Aleph which passes channels to handlers and HttpKit which obtains the channel once the request is in flight.
Server-sent events seem really exciting.
It came as a little surprise that Golang is still distributed by Mercurial rather than Git. Had to mentally brush the dust off my hg-fu.
An addition to your bash shell that should make the GOPATH bin directory executables directly available.
export PATH=$PATH:$PATH:${GOPATH//:// bin:}/bin
An addition to your bash shell that should make the GOPATH bin directory executables directly available.
export PATH=$PATH:$PATH:${GOPATH//:// bin:}/bin
Got Racket to build in a relatively short amount of time by using the pre-built source package. The default prefix is weird (local to the build location) so remember to set it to be /usr/local if you want it available globally on a machine.
I should not attempt the perfect stairway to the top of each mountain. Get to the top, then build a staircase if time allows.
Python Dynamic Type System idea
@constrain(name=str, value=int_between_0_and_100)
def foo(name, value):
pass
def foo(name, value):
"""
Where:
- name (unicode)
- value (int): > 0, < 100
"""
@alt(foo)
def foo(name, coef):
"""
Where:
- name (str)
- value (float): > 0
"""
LiveScript is a descendant of Coffescript (which I still have a fondness for) but seems to be taking some inspiration from Purescript/Haskell as well.
Typescript is a typed superset of Javascript that has been released by Microsoft. It is used to write ImmutableJS
The JVM will only inline methods if they are less than 36 bytecodes long putting an emphasis on small methods if you want to get the best out of the auto-optimisation at runtime.
nproc
tells you number of processing units your Linux instance has available
I've been doing a lot of JavaScript lately... and had a chance to spend some time on VPSpay.com - a really mature Python app.
Wow, Python is clean.
It's so easy to pick up Python and just start coding. Readable code really helps.
A few years ago, I blogged that you should code in a language you like.
Six years later, I'm glad I followed that advice. It's so much easier to enjoy life when you enjoy work... mainly because for at least 40 hours a week, life is work.
Jetbrains Kotlin has a new fresh background image on its project site.
What does this tower mean? Somehow this is very impressive.
The first time I saw variable and return types on the right side after a colon was in ActionScript. This was beautiful.
function repeatString(string:String,
numTimes:uint):String
{
var output:String = "";
for(var i:uint = 0; i < numTimes; i++)
{
output += string;
}
return output;
}
Now a lot of very nice modern programming languages use this convention: TypeScript, Scala, Kotlin, Rust, Swift.
There is also a lot of beauty in the polymorphic defined recursive functions I first saw in Erlang:
-module(fib).
-export([fib/1]).
fib(1) -> 1;
fib(2) -> 1;
fib(N) -> fib(N - 2) + fib(N - 1).
Similarily, there is also a lot of beautyness when we consider logical programming and this substitution and unification stuff in Prolog. I first saw this, when I learned about contraint satisfaction problems.
append([], X, X).
append([X|XS], YS, [X|ZS]) :- append(XS, YS, ZS).
% ?- append([], [1, 2], [1, 2]).
% true.
% ?- append([6], [1, 2], [6, 1, 2]).
% true.
% ?- append(X, [1, 2], [6, 1, 2]).
% X = [6] ;
This academic stuff is very arcane somehow. Let's go mainstream, but with a bit pattern-matching sugar:
fun fib(n: Int): Int {
return when (n) {
1, 2 -> 1
else -> fib(n - 1) + fib(n - 2)
}
}
fun main(args: Array<String>) {
for (n in 1..10) {
println("fib($n) = ${fib(n)}")
}
}
Is recursion good? I don't know. Just make sure you use the iterative version in production code.
Some Mozilla guys released a paper about programming experience with their new programming language Rust and this Servo web layout engine.
I didn't program much in Rust, but follow a lot of their work on Github and Reddit. I have some old Rust code of a "CPU emulator" inspired by LLVM and libcpu by Michael Steil et al with deprecated sigil syntax ~
for pointers.
I really like Rust but the borrow checker is not my best friend.
"Java is a blue collar language. It’s not PhD thesis material but a language for a job. Java feels very familiar to many different programmers because I had a very strong tendency to prefer things that had been used a lot over things that just sounded like a good idea."
I think Kotlin is a language that adopts this idea really good.
via: http://www.reddit.com/r/Kotlin/comments/30vgnn/does_kotlin_have_any_killfeatures/crxbe25
James Gosling (1997): "The Feel of Java", http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java.pdf
IO is infectious. How can we make it less infectious. See for instance https://effect.readthedocs.org/en/latest/intro.html which boils down to a form of DI - the performing of the Effect can be precisely controlled, but you still have had to write all three functions as though they might fail in arbitrary ways, rather than writing just one of them that way.
There has to be a better way.
Some links for the Kotlin programming language:
I love where meteor is headed. There are now a ton of really good open source apps that can quickly be deployed to container hosts like Amazon, Modulus and Heroku. It's starting to feel a lot like something is emerging that could replace the LAMP stack... and it's high time that happened.
Kotlin now has sealed
classes. I think they primarily resemble the concept of "tagged union"s. Rust has a similar elegant construct in form of enum
s.
sealed class Type () {
class Named(val name: String): Type()
class Nested {
class Function(val param: Type,
val result: Type): Type()
}
object Top: Type()
}
when (type) {
is Named -> println(name)
is Nested.Function -> println("$param -> $result")
// Alternatively, we can omit is here
is Top -> println("TOP")
}
Good news.
The Kotlin plugin will be part of IntelliJ IDEA 15.
Today, we’re excited to share with you that the EAP build we published yesterday comes with a bundled Kotlin plugin
JetBrains aims to release Kotlin 1.0 this year.
If you’re following the latest news in the Kotlin blog, you may know that its team is working hard to make it ready for the release this year.
http://blog.jetbrains.com/idea/2015/07/intellij-idea-15-eap-kotlin-love/
I need to learn more about how folk test IO code in Haskell. Functional tests are unsatisfying.
The Python effect library is pretty interesting, but its not as close a mapping to IO as I once thought.
Effect models an entire program as two things. A parameterisable interpreter(1) which interprets a DSL(2) that describes how to link together [relatively] pure code that depends on IO of some form. I say relatively pure code because its Python and you could do whatever you want. But the intent is that you'd have one type to represent writes, another to represent reads, and something like a WSGI app would become a single somewhat static data structure you can pass off to the interpreter at the start of things, and the interpreter can evaluate when to read, when to write, and when to throw. So its kindof cool, but this is fundamentally different to IO <type>. The DSL here is effectively a tree AFAICT - it's not particularly suited to e.g. describing things recursively. Types in the DSL related to the IO to perform, not the datatype returned. The DSL itself encodes the assumption of (approximately) the Either monad everywhere - which is why a tree is formed: A single Effect has function references for both Left and Right (failure and success), and they get recursively evaluated during interpretation. There are two specifically nice things here. Firstly, one can potentially run tests against the structure of the tree generated: though its able to be dynamic via the do decorator, or returning Effect objects in response to IO, so its not fully static. The other thing is the decoupling of IO and computation, so its possible to take one set of code and run it with threads, with Twisted, with asyncio, solely by writing replacement performers: the things bound to actual IO. That makes test doubles quite a bit easier to write and test.
Contrast with Haskell itself, where what happens is that the IO monad acts as a decorator turning all your functions that (say for [readline[(https://hackage.haskell.org/package/readline-1.0.1.0/docs/System-Console-Readline.html#v:readline)) take a string and return a string, and wraps them up so that they take and return a RealWorld parameter as well - but this gets optimised out by the compiler, and the coolness of Monads is they also get optimised out of the source code :). But its this threading of a hypothetical data parameter through all the functions (including recursively defined ones) that gives you ordering, and lets you write 'imperative' code in a purely functional language. You never see RealWorld in function definitions because the the type of the function is input1, ..., inputN -> IO (output), but return binds it in via State.
If you look closely, you'll see that IO String actually holds a function parameterised by String. IO (State# RealWorld -> (State# RealWorld, String))
- the extra input T and output T in (T,a) are supplied entirely by the monad instance. So all the machinery is doing is letting you say 'this into that into other thing' without having to manually express data dependencies. Something that Python doesn't need at all (because it isn't lazy, things are always evaluated.
There doesn't seem to be any mechanism in the IO Monad for switching in a wholly different implementation of the functions one calls: yes they're first class objects, but you need to arrange to pass the right ones in: readline is going to do readline, not some synthetic thing that aids testing.
Don't have a 'common' library!
I've seen this in a lot of bigger code bases. There are multiple projects that share functionality. For example a solution with web and cli interface. Typically this shared functionality gets shoved into a library called 'common'. It does sound like a good idea at first but it can get very messy after a while.
Here is the problem: Programmers are lazy and creating a new library is painful. So everything that is or just seems to be shared functionality will end up in the 'common' library. After a while this library will be big and bloated and probably will have lots of dependencies on its own.
Let's imagine you need to implement a new client, say for Android. This new client needs only some of the functionality of 'common'. This means including 'common' and all of it's dependencies. More code means more bugs and more things that can go wrong.
A better approach is to have multiple smaller libraries with a defined very specific scope. That way it is easier to reuse only small parts of the overall functionality. As for the pain of creating new libraries: This can be automated to a degree.
Bottom line: Keep things small and simple for best re-usability!
When trying to incorporate some ideas of functional programming into my Python code, I tend to end up with lots of parameters in my functions.
Some questions to myself:
Some resources:
Benefits of using pure functions:
Taken from: http://stackoverflow.com/questions/4565325/too-many-arguments-for-function
Ways to address too many arguments:
It is very hard to change the data structures in functional languages because of the ripple effect.
I.e.
def a(data):
b(data)
c(data)
Change data
would mean changing three functions.
Testing XPath in Firefox:
F12
to open the developer tools$x("//div[@class='switcher_bar']//button")
“If you don’t make experiments before starting a project, then your whole project will be an experiment.” - Mike Williams (Creator of Erlang)
hash -r
to rehash an executable that previously was not found and does now exist on your path
Convert an SVG to a PNG easily:
convert -resize <x>x<y> input.svg output.png