3 posts tagged “liverpool”
Thanks to Chris and Thom for organising the recent GeekUp Liverpool talks. The evening started well with Martin Owen's very interesting talk on justifying Erlang, and why FP is going to become a major factor in tomorrow's concurrency-oriented world. I demonstrated the wisdom of always saving a copy of your talk in PDF to a FAT formatted USB drive by being able to seamlessly present from Martin's laptop when my own decided that it really wanted to do a fsck right now, thanks very much.
My talk went well, thanks in no small part to a very receptive and welcoming audience (largely non-Perl programmers). I've now posted the slides to http://greenokapi.net/talks/ReadablePerl.pdf under a Creative Commons Attribution-Non-Commercial 2.0 UK: England & Wales license. Comments and questions welcome!
A varied discussion ensured, spanning legacy code, the value (or not) of training, vitamins and handmade chess-sets, Liverpool city of cultcha, and much much more.
Thom has posted the details of the next Liverpool geekup, Tuesday May 27th at 3345 Parr Street.
Last time, I admitted to programming in Perl and got ribbed about it being unreadable. Fueled by the fervour of the righteous (and maybe a pint or two of Cains bitter) I volunteered to do a talk on Readable Perl.
People like to claim Perl is line noise, with its sigils and regular expressions. But a lot of the features that make it possible to write, yes, truly awful, unreadable Perl, also let you write clean, maintainable code too.
- those $%&* sigils!
- there's More Than One Way To Do It
- strings and data structures
- map, grep, first class functions
- metaprogramming and the CPAN
- modern Object Oriented programming with Moose
Martin Owen will also be talking on Erlang, which I'm very much looking forward to!
Hope to see you there :-)
I'd been out of Liverpool for 3 years or so, and I completely missed GeekUp: a loosely affiliated, grassroots tech meetup society in the North West. The Liverpool branch is pretty active, and linked with various other groups, such as the DotNet user group, where Chris Alcock gave a very interesting talk on F#.
Not sure what the Dot Net programmers made of it, there were some questions afterwards amounting to "What's the point? Are academics going to use it?" :-) Which I thought was amusing as I was looking at it from the perspective of a Haskell newbie, thinking a) that's cool, b) it's simpler than Haskell, c) it plugs into the .Net libraries and development environment, and had concluded that it could (possibly) become a massive hit in real-world programming too...
Some notes, mainly comparisons with Haskell:
- The #light pragma adds syntactic sugar, very much like the Haskell do notation. (No need for open/close/statement delimiters, whitespace significant, skip in off let statements)
- The REPL is multiline by default (dons on #haskell noted that ghci supports this with :{
- Functions aren't recursive by default and have to be introduced as such (let rec factorial = ...)
- Lists aren't lazy, but there's a separate datatype called Seq which is.
- You can use yield in a function to define lazy sequences.
- Like Ocaml, F# supports mutable data, though the default is pure data.
- It also supports reference types - I'm not sure I understand what these are for in a functional programming language, or if they're just for updating, then how they're different from plain old mutable data. The example Chris gave was the classic closure example of a counter function.
-
The examples he made of pipelining with |> and >> looked very much Haskellish monads (especially in a #light style block). I quickly leafed through Chris's copy of till I found the section on monads. They're called "Workflows", because that's less scary than Monads. They're also largely transparent, which on one hand is nice, as there's none of the painful and ugly "lifting" of values to the appropriate monad. (On the other, it means that you can't easily separate action and non-action code).
- This of course means that you don't get some of the benefits of FP's purity. Martin Owen, who is keen on Erlang and its capacity for massively scalable, high performance networking, also pointed out that allowing mutability means that you can't guarantee that the application is threadsafe, and is the wrong default as we're coming up against multicore programming.
All in all, it was a very interesting talk, and I'm looking forward to playing with F#. I apt-got Mono, and promptly failed to install F# on it, as the provided install.sh script whined about something to do with gac and aot. Ah well, perhaps that's a good excuse to boot up into Windows...
