VS Code

One of the things I learned at Go Maryland tonight was that VS Code is not just for Windows; they have versions for Linux and OS X too! With a name like Visual Studio Code, I just assumed it was a Windows thing. Not so!

Naturally, when I got home I had to try it! And here it is running on my Linux machine!

Screen shot of VS Code

As you can see, it understands Go code (on the left), but not Elixir (on the right). At least, not yet. I’m sure it will eventually. I also tried out Perl (yes), Python (yes), and Ruby (yes) — no surprises there — as well as Erlang (no), Pony (no), Rust (yes), and Clojure (yes) — a couple of nice surprises there!

The cursor blinks by default, so the first thing I had to do was figure out how to shut that off 1. It only took me a minute or two to find and change the configuration to a non-blinking cursor. Well done, VS Code!

I doubt I’ll be giving up Emacs any time soon (indeed, I’m typing this blog entry with org2blog), but it’s nice to see another open source editor available. Great job, Microsoft!

Update: In case you’re curious, here’s a shot of the same two files opened in Emacs, which has an Elixir mode.

Screen shot of same two files in Emacs

Footnotes:

1
I can’t stand blinking. I think it’s genetic. My Mom never let us have Christmas lights that blinked either. And to be fair, my beloved Emacs has a blinking cursor by default also
VS Code

Swift 2.2

A while back, I mentioned Swift was open sourced. Today, they released version 2.2, the first release with non-Apple contributors.

There are also binary releases, so it’s even easier to install!

$ wget https://swift.org/builds/swift-2.2-release/ubuntu1510/swift-2.2-RELEASE/swift-2.2-RELEASE-ubuntu15.10.tar.gz{,.sig}
$ gpg --verify swift-2.2-RELEASE-ubuntu15.10.tar.gz.sig
...
$ tar xf swift-2.2-RELEASE-ubuntu15.10.tar.gz
$ rm swift-2.2-RELEASE-ubuntu15.10.tar.gz{,.sig}
$ export PATH=$PATH:$HOME/swift-2.2-RELEASE-ubuntu15.10/usr/bin
$ cd swift
$ rm hello
$ swiftc hello.swift
$ ./hello swift 2.2
Hello, swift!
Hello, 2.2!
Swift 2.2

Pony Lang

The other day, I watched Mark Allen‘s talk comparing Erlang and Go Concurrency and I really enjoyed it. Near the end, he mentioned a new programming language called Pony which uses the Actor Model.

What? I’ve never heard of this! So I did a search on “pony lang” and got a bunch of pictures of glamorous women. At first, I thought maybe there was an actress or model named Pony Lang. Then I realized they weren’t all pictures of the same person, though they did have similar hairstyles. It turns out “pony lang” is Dutch for “long bangs”.

Anyway, ponylang.org is where to start if you want to learn more about the Pony programming language. I installed it

sudo add-apt-repository "deb http://releases.ponylang.org/apt ponyc main"
sudo apt-get update
sudo apt-get install ponyc

added the Emacs mode for it

(use-package ponylang-mode
  :ensure t
  :config
  (progn
    (add-hook
     'ponylang-mode-hook
     (lambda ()
       (set-variable 'indent-tabs-mode nil)
       (set-variable 'tab-width 2)))))

and dashed off hello world.

actor Main
  new create(env: Env) =>
  env.out.print("Hello, World!")

Now compile and run it!

$ cd ~/pony/helloworld
$ ponyc
Building . -> /home/tim/pony/helloworld
Building builtin -> /usr/lib/pony/0.1.7/packages/builtin
Generating
Optimising
Writing ./helloworld.o
Linking ./helloworld
$ ./helloworld 
Hello, World!

Looks great! Another new language to learn! What fun!

Pony Lang

How to measure your CPU time: clock_gettime!

I loved reading How to measure your CPU time: clock_gettime! by Julia Evans.

In Perl, we can access clock_gettime throught the Time::HiRes module.

#!/usr/bin/env perl

# http://jvns.ca/blog/2016/02/20/measuring-cpu-time-with-clock-gettime/

use v5.22;
use warnings;
use Time::HiRes qw(clock_gettime CLOCK_PROCESS_CPUTIME_ID);

my $start_time = clock_gettime(CLOCK_PROCESS_CPUTIME_ID);
do_maybe_expensive_thing();
my $end_time = clock_gettime(CLOCK_PROCESS_CPUTIME_ID);
say "elapsed CPU time: ", $end_time - $start_time;

sub do_maybe_expensive_thing {
    my $j = 1;
    for my $i (1..int rand 100_000_000) {
        $j *= $i;
    }
}

If we change do_maybe_expensive_thing to just a sleep, we’ll see that it takes up time without using CPU time.

Fun!

How to measure your CPU time: clock_gettime!

Supergood!

I spotted encourage-mode for Emacs on twitter the other day, so naturally I had to try it!

(use-package encourage-mode)
(encourage--toggle-encouragements)

For some reason, I had to toggle the encouragements to get it started (it seems like that shouldn’t have been necessary. Update: It’s not…see the comments!). Then I added some more encouragements to the list (most of these are from the Venture Bros.)

(setq encourage-encouragements
  (nconc encourage-encouragements
    '("Excellent!"
      "Hot sandwich!"
      "Mein lieber Schwan!"
      "Nice!"
      "Outstanding!"
      "Ossum!"
      "Quit it!"
      "Scwhanky!"
      "Spanakopita!"
      "SPHINX!"
      "Supergood!"
      "Sweet!"
      "That is so Batman!"
      "Well done, you!"
      "Whoa!")))

Fun!

Supergood!

GADSWAD

Recently, on the Python-Dev mailing list, Guido van Rossum said the transition to Python 4 won’t be like the transition to Python 3 (“we’ve learned our lesson”).

Yukihiro Matsumoto has said similar things (without the cheap shot at Perl, naturally) recently at RubyConf 2015 and at Full Stack Fest 2015 when he talked about Ruby 3.0. In both of those talks, he gave a pretty thorough outline of the similar transitions that Perl, Python, and Ruby have gone through over the last 10 or 15 years. He talks about how Perl started over from scratch, Python made a set of backwards-compatiblity breaking changes all at once, and Ruby made backwards-compatiblity breaking changes gradually over several minor versions.

Python 3 was released nearly seven years ago, yet a majority of Python users are still on Python 2. It looks as though some might never switch. Ruby users, on the other hand, gradually transitioned from 1.9.1 to 1.9.2 to 1.9.3. They find themselves at Ruby 2 without really noticing.

Both GvR and Matz are looking at it like this

Perl 5   -> Perl 6
Python 2 -> Python 3
Ruby 1.8 -> Ruby 2

and feeling pretty good about themselves. Perl 6 isn’t even out yet, so they both did okay, right? And now they’re looking ahead at things like concurrency and performance that will be necessary for the future.

Perl 5   -> Perl 6
Python 2 -> Python 3  -> Python 4
Ruby 1.8 -> Ruby 2    -> Ruby 3

But despite its decline in popularity, I think Perl 5 has maintained feature parity with Python and Ruby. Since Perl 5.10 opened the floodgates, the updates to Perl are collectively known as Modern Perl. I use Modern Perl every day at my job and it’s fine. While Python 3 and Ruby 2 have kept up with it, more or less, they are not a quantum leap ahead by any stretch of the imagination. So I think the situation today looks more like this:

Perl 5   -> Modern Perl
Python 2 -> Python 3
Ruby 1.8 -> Ruby 2

Perl 6 is threatening to finally come out later this month and it is already prepared for the future. That is, I believe we should be comparing Perl 6 to Python 4 and Ruby 3.

Perl 5   -> Modern Perl -> Perl 6
Python 2 -> Python 3    -> Python 4
Ruby 1.8 -> Ruby 2      -> Ruby 3

Of course, there’s still the whole issue of adoption. If Perl 6 is adopted as slowly as Python 3 (or even more slowly!), then it may never matter how futuristic it is.

I think concurrency is going to matter a great deal in the near future, so my recreational programming time lately has been dedicated to things like Clojure, Elixir, Go, and Rust. I’m betting my professional programming time will go that way soon too. Sequential programming is doomed. We’re going to have to figure out concurrency or find another profession.

GADSWAD