Crufter

Why I'm (Almost) Returning to Open Source

Thu, 06 Jun 2024 00:00:00 +0000

This post recounts my journey of developing a side project as closed source, diverging from my usual open source approach, and why I eventually opted for dual licensing.

A few (or many? who counts…) months ago, I started developing an AI desktop app and platform (https://github.com/singulatron/singulatron). Prior to this, pretty much every side project I undertook was open source from the first line of code. But that recently changed…

Feeling Scammed

By Big Corporations

Around the time of the Amazon Elasticsearch controversy, I began to feel somewhat foolish. I often question my core beliefs and wondered: is the open-source ethos merely a ploy to get people to write software for free? Do we conduct the R&D ourselves, only for a larger, well-funded entity to take over the idea and make substantial profits?

Is it about laying the foundations for free, on which giants can stand? To solve the hiring problem for free, to work for free? To suppress wages? To build something awesome that those with the cloud capacity can then take and sell?

Software is all labor and almost no capital. And there is nothing capital (Alphabet, Meta, Amazon) hates more than expensive labor. So why not promote open source? Get the fools to do the labor for free—only you have the capital to deliver it as a service anyway.

By AI Tools

While pondering the above, the icing on the cake was seeing AI tools spit out open-source code verbatim. Now we are getting into the territory of almost outright disrespecting licenses—and potentially the wholesale automation of our profession itself. I know, it’s rich coming from someone whose entire livelihood is made possible by automating away other professions. Still, as much as I try to be a nice guy, I still need to eat.

Of course, I’m mostly joking about the automation part—but not entirely. The sword of Damocles definitely hangs above all of us. How long until it drops is anyone’s guess.

By Bad Actors

To further elaborate on the previous point about respecting licenses… I was born shortly before the Soviet Union fell. In the Soviet Union, intellectual property was not a thing, or if it was, it was only on paper. In the West, we respect IP, but the further east you go, the less concern there is for it.

With China becoming an ever more prominent superpower, the idea of respecting IP seems to be in serious decline. For this reason, I’m incredibly sad to see the West heading in a similar direction.

A Bad Mindset

So I decided, after decade(s) of open source, I’m just going to hack in a closed repo. What’s the worst that can happen, really? I can be messy in private without the prying eyes of the public or coworkers. Great!

And so it went for a few weeks, months, but something felt off…

Boredom

After a while, I started to notice the silence. Nothing was happening! I fixed bug after bug, feature after feature. I figured it was fine because once I’m done, it will be all good. I’ll release, people will see the result of my work, and everyone (or at least I) will be happy.

The problem is, as anyone who has done software development knows, software always takes longer than you planned. Or imagined. Even in your vivid and wild imagination. And when it’s done, it takes even more time.

So the cycle continued. Bugs. Features. Bugs. Features. And intrusive thoughts.

Greed

I started going out of my way to conceal the technical solutions to problems from the end user. Why would I leak technical details when I’m closed source? There is a reason I’m doing closed source, right? What I’m doing must be valuable—at least to me—since I sacrifice so much for it without anything to show for.

When doing open-source development, greed manifests itself as wanting to be first or famous. When doing closed-source development, greed manifests itself as the desire to gatekeep knowledge, to be the only one with the edge.

The first mindset is obviously way more beneficial for the collective knowledge of humanity. But ideology aside, there were more immediate annoying things too.

Practical Annoyances

If emotional traps leading me astray weren’t bad enough I also had to tackle a ton of practical annoyances.

Builds

When doing open source development, builds are not just free but they also run in a fresh VM each time. Using GitHub hosted runners looked to be prohibitively expensive when I often pumped out a hundred commits a day. But since I have my own bare metal servers that should not be a problem right?

So I did that. Initially it was awesome—things were building much faster! I had a full gigabit connection for myself, and caching between runs was easy.

But my software actually installs and uninstalls stuff on the OS—like the docker daemon. Not having a fresh VM each time made me not able to test this startup sequence.

Private Access

Having to access the same codebase from many different machines and VMs becomes tedious in a fast paced environment. Obviously it’s not an overly big deal, but I can’t tell you how many times I rolled my eyes thinking—”Man. I wish this stuff was just open source”.

Couple that with having to invite people when you want to show them something and quickly you will wish you had a well kept open source repo ready to link.

A Closed Desktop App

I quickly realized I picked the worst time to go closed source—when working on my first desktop app, especially a closed Node.js desktop app.

Node.js

Unfortunately, code obfuscation can be undone pretty easily. The hardest parts of my codebase to get right—shell scripts to set up the user’s environment—were the easiest to understand, even when looking at the obfuscated code. They were just simple strings.

Compiling to a binary doesn’t always help either. After the first prototype, I switched the backend from Node.js to Go because I feel more at home with it. Electron became a very thin wrapper without any business logic. However, the shell script strings baked into the binary are still easily viewed in the appropriate editors.

User Trust

Another reason this was probably the worst time to go closed source is because shipping server software is one thing—your users interact with it through the safe confines of their browser. Asking users to install a binary that will install a bunch of things on their computer is entirely different.

This is especially true when you’re starting out and might not even have your binaries signed, which costs around $500 a year and involves a lot of hassle.

The Solution

So this was the journey I took to end up going back to open source, but with a twist. I dual licensed Singulatron, it’s free for personal use but not for commercial use.

I should and probably will find an existing license later that words my actual intentions clearer than this current commercial license I have: to make well funded companies pay. I’m definitely not after the small company hustlers similar to me. I know their pain all too well.

Singulatron: Free desktop AI app and on premise AI solution for companies

Wed, 22 May 2024 00:00:00 +0000

Introducing the Singulatron! Visit us at https://singulatron.com/home.

I’m thrilled to announce that, after extensive effort, Singulatron is now achieving a commendable level of stability. But what exactly is Singulatron capable of?

Empowering AI on your desktop

https://singulatron.com/desktop-ai

The genesis of Singulatron is straightforward: we encountered a lack of accessible options for running ChatGPT-like AIs locally. Given the novelty of the industry, this was hardly surprising. However, driven by our desire for a user experience akin to the renowned one, we delved into extensive hacking and custom scripting. Our vision? A seamless, user-friendly platform.

Best of all, Singulatron is both free and private. After tireless development, our dream has become a reality. Join us and embark on this thrilling new journey! And that’s not all:

Tailored AI solutions for your company

https://singulatron.com/office-ai

We’ve meticulously engineered Singulatron to seamlessly transition from personal AI use to corporate applications, offering a 99% similar experience. This means no steep learning curves or unfamiliar interfaces when integrating Singulatron into your company’s workflows.

Interested in enterprise pricing? Get in touch with us today.

A word from Janos: Aou guessed it right, this post was written by AI. Fairly bland isn’t it?

Tiredd: a toy Reddit clone built on free APIs

Wed, 29 Sep 2021 00:00:00 +0000

https://tiredd.org

As someone who likes the concept of Reddit but dislikes how the site is run, I keep launching short lived Reddit-like side projects. I mostly use Lemmy, but I can’t justify running a SQL server and a VM for projects nobody cares about!

So as a toy project to test out Micro (disclaimer: it’s my day job), I decided to build a fun little Reddit inspired toy app: Tiredd (github repo)

It is only about a thousand lines, and only a single page. The backend is a single Go file, the frontend is a single Angular component, so should be easy enough to hack on.

What it has

Reddit/HN-like ranking of posts

By a combination of score and time. Algorithm taken from here https://medium.com/hacking-and-gonzo/how-reddit-ranking-algorithms-work-ef111e33d0d9.

Anonymous posting and commenting

But only registered users can upvote/downvote to give the community ability to moderate.

A very rudimentary way to moderate by admins

Make users mods by saving their user ids as a comma separated envar. Unlike normal users, they can vote on an item multiple times, and each time their vote counts as a random value between 4-17. I told you it’s very rudimentary ; ).

Hot/new page

Adjust to your taste by changing the minimum score on the frontend!

Subs

Each post can be categorized under subs, just like Reddit.

What it does not have

Posts are not linkable

Is it a missing feature or a feature? It might actually prevent brigading :)).

Comments are not tree like

Comments are ranked by score just like posts, but there is no reply, quote, or tree structure like on HN or Reddit.

Probably a tons more

Things like password change are missing, there is a chance I will add them!

How to run

As previously stated, the main goal was to run this for free. There is no SQL server dependency, because it is using the DB and User services of Micro, all of which are free.

The go server is a single HTTP server which an be trivially translated to any FaaS provider (as it is stateless) to host the whole thing for free!

Enjoy!

Why we are building a CLI first PaaS without a web frontend

Thu, 05 Nov 2020 00:00:00 +0000

At the start of this hectic year I have joined Micro, an open source microservices platform. The company was born out of a Go framework. We took the concepts of the framework - interfaces for service discovery, configuration and other pieces which can run on any implementation (from mdns locally to kubernetes) and provide a live platform version of it. It’s kind of like Netlify, but for the backend.

Once we were happy with the local development flow for the micro server and CLI, we decided to start selling the product as a platform. Building a website seemed like an obvious step to do. It’s 2020 right?

So we got to work. Metrics with nice charts. Tracing. Calling services. Listing endpoints. It was all shaping up nicely. But slowly and surely we started missing features we got accustomed to on the frontend in the CLI. Being very heavy command line users, whenever we got something available in the CLI, we reached there first.

And then we realised. Who are we building this frontend exactly and why? We prefer the command line. And none of our many thousands of users were asking for a web UI. At most it was considered a “cool” thing to have.

The past three decades have been all about the world wide web (www) and in that we’ve gone through the multiple iterations of building “web first” experiences which I’d argue really peaked in the Web 2.0 era in the mid 00s with the likes of Facebook and others. At some point we entered the “Mobile first” era and yet for developers, Web still became a horrible platform we were stuck with for any platform or tools, AWS is a great example of how to get it really wrong. If new products and platforms are going Mobile first, maybe we as developers need to go CLI first. So here it is. M3O is a CLI first experience. No context switches, no ugly dashboards, just a simple straight forward command line utility that gets out of your way when you need it to. Our hope at Micro is more learn from this experience and do away with Web UIs entirely. Challenge every assumption you know about Web for backend development and think, do I really need that, or is it better served as a single CLI experience.

So we doubled down. We entirely sidelined the web UI and decided payment will be the only thing on the website, should supplying card details in the terminal feel sketchy.

What we found after this surprised us. By limiting our choices we unleashed a storm of ideas on how to improve the single medium we can express our thoughts in.

We started to make service call feel just like any command invocation.

What was previously

micro call servicename endpoint '{"field":"value","otherfield":{"subfield":"value2"}}'

became

micro servicename endpoint --field=value --otherfield_subfield=value2

On the surface it might not seem much, but when you are living and breathing these commands it provides a great satisfaction to remove even little frictions.

New services and their endpoints feel just like builtin Micro commands, which is why our invites simply became

micro invite user --email=someone@domain.com

Shipping features to end users became as deploying a new service, and users can easily programatically call their endpoints from the terminal.

Bash shines at quick and information dense throwaway scripts, so our end to end test framework is built for tests to be written using Micro CLI commands.

We dream of a future where programming is as close to natural languages as possible. At the moment, the ubiquity of bash provides a great layer for us to quickly interact with microservices. It truly feels like the platform is alive as nouns and verbs are being created by service writers to be composed into sentences.

Why don’t you give it a go? We have a free tier ;).

Co-Authored with Asim Aslam.

Cloud computing needs to be reformed

Thu, 11 Apr 2019 00:00:00 +0000

Amazon derives over 40% of its total value from Amazon Web Services, per Trefis estimates, despite generating only around 10% of net revenues in 2017. This is largely due to the fact that AWS is a high-margin business (25% reported operating profit margin) while non-AWS business streams operate at thin margins. Forbes

But how sustainable are these high margins?

Spend money, because you can

I once worked with a company that spent $350k on Amazon every month to support about a million users. We have had a particularly vocal engineer who often proclaimed that he could run the whole operation on his MacBook with Redis.

I don’t think he was wrong, and in fact he later proved himself right multiple times when making similarly wild claims (altough we did not let him run the whole company off his MacBook in the end…)

A good dedicated server (or a couple of them for resiliency) could have easily done the job. Why were we spending all that money then?

The value you get

There are a few big, undeniable upsides of spending all that money on the cloud:

You get access to quality software that’s not open source
You get managed infrastructure

One could argue that the second point can justify high spendings, because you can save on devops costs. There is definitely some truth to this, although if I have to choose between giving money to Google versus some devops guys I can have beers with, I would definitely go with the latter :). Devops people are some of the most amazingly cynical, bullshit-free and pragmatic people I have ever met. Probably because unlike many other professionals, they can’t bullshit around their metrics.

Site uptime is an unforgiving master.

However, the same value could be extracted from rock solid open source systems. There is pretty big problem with this however - namely the fact that such open source system does not exist yet.

While the on the hard tech front the industry made pretty big advancement (Kubernetes etc.), most of the complete solutions are still proprietary.

The need is definitely there. About two years ago we released 1backend, which was meant to be a fun little excercise for our dev team, but the feedback was very positive.

If a small team can deliver a project like that, imagine what could happen with a bit of funding and a couple of years.

Open Source will emerge victorious

While Google and co. does a wonderful job with managed services, I think the value they provide does not match the money they make. In fact, it’s getting worse: the next step in this tendency is Functions as a Service.

An amazingly convenient concept, spearheaded years and years ago by the still relatively obscure hook.io, made hosting your code even cheaper for Google but more expensive for you. Combine this with real time databases such as Firestore, which charges you by the number of read operations, things get ridiculously expensive very quickly.

What to build and how to fund

Most probably a sales-savvy open source company who would have the capacity to implement the following things could become a unicorn:

A real time database

A FaaS/Microservices platform

Ability to spin up VMs

Networking and security features

Code around managing common databases: Postgres, Mongo etc.

Making it happen

Monetisation would not be easy initially, but perhaps targeting companies who are required to host their code on premise could provide the initial stream of revenue. Time works against this strategy however, as more and more companies gravitate towards AWS/GCP/Azure.

Capturing the mindshare of developers would not be overly hard, as even though the big tech has amazing infrastructure, they don’t venture into building out anything akin to a framework for backend services. While both Google and Facebook is supporting a front end framework (Angular and React respectively), none of them seem to be interested in providing a similarly seamless developer experience on the backend, let alone providing both and connecting the two together.

Bash - Basics

Sun, 29 May 2016 00:00:00 +0000

In this series we will explore the Linux shell scripting language. Every operating system has a terminal - Windows, Linux/Unix, OSX. A terminal is textual interface to operating system. In the old days of computing (think before 90ies), computers could not display pictures or videos - all they could show was text.

Even nowadays, most servers running the internet do not have graphical interfaces, the terminal is so powerful that you can control a machine with it very nicely - there is no need for animated cat gifs :))

So let’s see how this powerful interface can be used to control machines and do awesome things.

The terminal is basically an interpreter interpreting a language called shell. This language is just like most other languages (like Java or Javascript for example), but the language itself looks rather different. “Functions” are essentially binaries (programs) on the machine and arguments are separated by spaces. The hello world example looks like the following:

$ echo "Hello world, this is my first shell command :-)"
Hello world, this is my first shell command :-)

This is not so exciting so far! We don’t see any context. Where is echo coming from? What is it doing? Where are we? The latter can be answered by the pwd command, which is a short name for print working directory

$ pwd
/

What is this / thing? We are currently at the root (or top level in other words) of the directory tree. If we do an ‘ls’ (short for list), we will see the directories in this root directory. The list will be a bit long, pre prepared :), and scroll to see all of it.

$ ls
bin
boot
dev
etc
home
lib
lib64
media
mnt
opt
proc
root
run
run.sh
sbin
srv
sys
tmp
usr
var

As we can see there are a number of directories and files on the top level. You can explore them by using the ls command and supplying folders to it. How can we have a look inside, let’s say the /bin folder?

$ ls /bin
cat
chgrp
chmod
chown
cp
dash
date
dd
df
dir
dmesg
dnsdomainname
domainname
echo
egrep
false
fgrep
findmnt
grep
gunzip
gzexe
gzip
hostname
journalctl
kill
ln
login
loginctl
ls
lsblk
mkdir
mknod
mktemp
more
mount
mountpoint
mv
networkctl
nisdomainname
pidof
ps
pwd
rbash
readlink
rm
rmdir
run-parts
sed
sh
sh.distrib
sleep
stty
su
sync
systemctl
systemd
systemd-ask-password
systemd-escape
systemd-inhibit
systemd-machine-id-setup
systemd-notify
systemd-tmpfiles
systemd-tty-ask-password-agent
tailf
tar
tempfile
touch
true
umount
uname
uncompress
vdir
wdctl
which
ypdomainname
zcat
zcmp
zdiff
zegrep
zfgrep
zforce
zgrep
zless
zmore
znew

Wow! That’s a long list. The bin folder contains some of the binaries, the programs, or commands you can run. If you look closely echo, pwd, ls are all there in the list! Using the which command we can see (surprise!) which binary will be run when we type a command name into the shell:

$ which ls
/bin/ls

As you can see, when we did an ls on the /bin folder, the ls command was indeed there! So meta :-D! What can you do if you want to peek inside a file? Let’s say we want to read the PERL (which is a programming language) readme on Ubuntu:

$ cat /usr/share/doc/perl/README.Debian
Perl Packages for Debian
========================

  perl             - Larry Wall's Practical Extracting and Report Language.
  perl-base        - The Pathologically Eclectic Rubbish Lister.
  perl-doc         - Perl documentation.
  perl-debug       - Debug-enabled Perl interpreter.
  libperl5.22      - Shared Perl library.
  perl-modules-5.22 - Architecture independent core Perl modules.
  libperl-dev      - Perl library: development files.

To provide a minimal working perl, the ``perl-base'' package provides
the /usr/bin/perl binary plus a basic set of libraries.

The remainder of the application is included in the perl, perl-modules-5.22
and perl-doc packages.

See the 'README.source' file in the perl source package for information
on building the package.

perl-suid removed
=================

suidperl was removed upstream with 5.12, so the perl-suid package which
used to be distributed in Debian has been removed too. Possible alternatives
include using a simple setuid C wrapper to execute a perl script from a
hard-coded location, or using a more general tool like sudo.

Credits
-------

Previous maintainers of Debian Perl packages:

  Ray Dassen <jdassen@WI.LeidenUniv.NL>,
  Carl Streeter <streeter@cae.wisc.edu>,
  Robert Sanders <Robert.Sanders@linux.org> and
  Darren Stalder <torin@daft.com>.

 -- Brendan O'Dea <bod@debian.org>  Tue,  8 Mar 2005 19:30:38 +1100

Idris, a language that will change the way you think about programming

Thu, 01 Jan 2015 00:00:00 +0000

Most programming languages barely differ from each other apart from superficial syntax differences, but not Idris. Idris, having a type system supporting dependent types and other innovative ideas, opens up a host of possibilities few other language provides.

When we want to ensure that a piece of code works as intended the usual tool we use is testing. Testing provides plenty of benefits, but wouldn’t you prefer to encode your tests right in the type signature and let the compiler decide if your code is correct given those constraints? With Idris you can do exactly that.

Let’s investigate how by comparing a very simple list operation, append, also called (++) in Haskell and Idris. Append in Haskell has the following type signature:

Prelude> :t (++)
(++) :: [a] -> [a] -> [a]

Sharing most of the syntax and lot of the type system with Haskell, the append for lists looks very similar in Idris:

Idris> :t (++)
Prelude.List.(++) : List a -> List a -> List a
Prelude.Strings.(++) : String -> String -> String
Prelude.Vect.(++) : Vect m a -> Vect n a -> Vect (m + n) a

When we have a look at the Prelude.List.(++), we can see that it matches the Haskell version - it tells us that it takes two lists and returns a third one - it doesn’t say a single word about the lengths of those lists. But if we look at append for the Prelude.Vect type (vectors are a kind of lists with a size), we see the signature describing the size of the vector:

Prelude.Vect.(++) : Vect m a -> Vect n a -> Vect (m + n) a

In dependent type terminology a vector is a list indexed over its length, or in laymen’s terms the type of a vector is a list with a size. This is remotely similar to the concept of fixed sized arrays, (for example, in Go) a [4]int is not the same type as a [5]int. However in Idris, we can not only describe that those lists have different type, but as we can see above we can also express how a given property - in this case the length of a list - changes as a result of a function. As Wikipedia succintly states:

A promising type-based verification approach is dependently typed programming, in which the types of functions include (at least part of) those functions’ specifications, and type-checking the code establishes its correctness against those specifications.

To understand the importance of this it is not enough to inspect the the above functions’ type signature. What meets the eye there could be considered documentation. But the real epiphany comes when we start to implement a function after specifying its signature. Let’s examine the source code of append:

||| Append two vectors
(++) : Vect m a -> Vect n a -> Vect (m + n) a
(++) []      ys = ys
(++) (x::xs) ys = x :: xs ++ ys

But what happens if we intentionally brake the implementation, for example by appending the first argument to itself and ignoring the second argument entirely? The resulting Vector will have a length of m + m, which is clearly different than the m + n stated in the signature.

import Data.Vect

vapp : Vect n a -> Vect m a -> Vect (n + m) a
vapp Nil       ys = ys
vapp (x :: xs) ys = x :: vapp xs xs

(link)

The compiler tells exactly what we suspected:

Type checking ./vapp.idr
vapp.idr:5:23:When elaborating right hand side of vapp:
When elaborating argument xs to constructor Prelude.Vect.:::
        Can't unify
                Vect (n + n) a
        with
                Vect (plus n m) a
        
        Specifically:
                Can't unify
                        plus n n
                with
                        plus n m
Metavariables: Main.vapp

The above example shows an interesting quality of Idris’ type system: the correctness of the code is checked against any specification in the functions’ type. If the implementation does not meet the specification a compile error is triggered. Naturally, any property not described by those specifications will not interest the compiler. Let’s say we implement our ‘vapp’ function the following way:

vapp1 : Vect n a -> Vect m a -> Vect (n + m) a
vapp1 Nil               ys = ys
vapp1 (x :: x' :: xs)   ys = x :: x :: vapp xs ys
vapp1 (x :: xs)         ys = x :: vapp xs ys

This compiling program almost works perfectly but it does have a quirk; the first element from the first argument is present twice, once on the 1st position correctly, and on the second position incorrectly, deleting the second element:

*vapp> vapp1 [1,2,3] [4,5,6]
[1, 1, 3, 4, 5, 6] : Vect 6 Integer

So we have proved that whatever is stated in the type signature is guaranteed to be correct - but nothing else may be. In our append example we state that ‘given vector a and vector b, calling append with those vectors as arguments will yield a vector with a length of length a + length b’. It does not state that the resulting vector will contain any element from the argument vectors, or if the order is preserved or anything else! But this is pretty obvious since how could the compiler decide wether a code is correct or not if we do not tell it the criteria to judge a piece of code by. Mind reading based programming is not invented yet, unfortunately.

To say the least, dependent types have the potential to become a new useful tool in a programmer’s toolbox - and there is a certain idealistic beauty in building on top of formally verified, guaranteed to be correct code.

Idris version used to compile code snippet(s):

$ idris -v
0.9.14.2-git:45de9ab

Appendix

Everyday hassles in Go

Mon, 01 Dec 2014 00:00:00 +0000

Go became a reliable ally of mine during the past years. I use it in my day job and for side projects alike. I quite like the Go ecosystem, the tooling is great, from go fmt to race detector one can feel that the authors have done their share of coding in the wild. The standard library is very comprehensive (especially considering the age of the language), the documentation is top notch. The language itself though, could be improved a lot by borrowing battle tested ideas from more modern ones.

Unfortunately, a lot of Go programmers are coming from untyped languages, which means they haven’t yet acquired the taste for sufficiently expressive type systems, thus they may not know about alternative approaches. A snarky person might say, they suffer from the blub paradox.

This lack of perspective in the Go community hinders the progress of the language - people do not exert enough force toward the authors (not like they seem to be crowd pleasers anyway) to better the language. While I am grateful for Go as a tool, I am slightly worried about its potential educational effect - or the lack of it. Given it is backed by Google - due to the hype and exposure that brings - even design failures will be accepted as ‘the way to do it’ by a large number of people. People like the authors of Go have an immense responsibility when it comes to improving our industry as a whole.

Here are the analysis of some of the features (or the lack of them) I consider unfortunate, with use cases and accompanying code. The examples may be quite arbitrary. Most of the difficulties listed here could be fixed by a relatively small number of changes (the 80/20 rule?).

Lack of generics

Generics are well supported by a wide range of languages, and is one of the most requested lacking features of Go. The usual response from the Go authors is that implementing generics will either slow down compilation, the code, or the programmer. While that is almost a believable reason, the funnier part of their reasoning is (excerpt from FAQ):

Go’s built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.

(link )

Well, how less smoothly? Let’s investigate.

(Quite a good chunk of this blog post will be dedicated to help people who never used generics to develop an intuition why generics are useful. If you are not interested in this part, scroll down a bit.)

Bye-bye code reuse

A rather surprising set of functionality is missing from the standard library: a type of ‘bread and butter’ code which deals with simple but often encountered scenarios that no programmer should implement, because it is simply a waste of brainpower cycles - there is no gain to be won by reimplementing - let’s say - deduping elements in a slice.

Deduping slice elements

Deduping elements of a slice happens the following way in go:

package main

import "fmt"

func main() {
	// Given the following list:
	xs := []int{8, 6, 8, 2, 4, 4, 5, 9}
	
	// For loop is the only generic way to traverse slices, so we have to write the following:
	index := map[int]struct{}{}
	for _, x := range xs {
		index[x] = struct{}{}
	}
	
	// We can "easily" acquire the deduped slice by using a for loop again...
	deduped := []int{}
	for k, _ := range index {
		deduped = append(deduped, k)
	}
	// Hooray, we can use the 'deduped' slice!
	fmt.Println(deduped)
}

(playground link)

For those who are not familiar with the concept of generics, here is a thought experiment: let’s refactor that bit of code by moving it out to a function:

package main

func deduper(xs []int) []int {
	index := map[int]struct{}{}
	for _, x := range xs {
		index[x] = struct{}{}
	}
	deduped := []int{}
	for k, _ := range index {
		deduped = append(deduped, k)
	}
	return deduped
}

Uh-oh: now our method only works on int slices - our for loops would be still generic, but the function definition forces us to tell the type of the input argument. It is an int slice. If somehow we could tell the compiler that we don’t care what kind of slice it is!

You may ask - what if we use the interface{} interface type? It is a bit ugly, but it works! Let’s try that!

func deduper(xs []interface{}) []interface{} {
	index := map[int

Uh-oh again. We even had to stop typing. We can not use the empty interface as our key in the map… To be able to use something as a map key the members of that type must be comparable (http://golang.org/ref/spec#Comparison_operators). Empty interfaces are not comparable, since they can represent non-comparable types! This way we can forget our neat implementation which reuses the idempotent nature of setting keys of a map!

Let’s look for an other approach - surely the Go authors have paved the way for us. Let’s take a look at the sort package. We see a quite descriptively named sort.Interface type there:

type Interface interface {
        // Len is the number of elements in the collection.
        Len() int
        // Less reports whether the element with
        // index i should sort before the element with index j.
        Less(i, j int) bool
        // Swap swaps the elements with indexes i and j.
        Swap(i, j int)
}

This would be all good, but no methods can be defined on builtin types! Don’t worry! The IntSlice type comes for the rescue! We only have to typecast our []int into an IntSlice and we can use all the functions written by other very smart people. But let’s go back to the deduping function. Let’s try to use the sort.Interface to write our own deduping function. After all, we can compare elements of a slice with it.

package main

import "sort"

func dedupe(xs sort.Interface) {
	for _, v := range xs {
	
	}
}

(playground link)

Before finishing our function we realize one thing - we can not iterate over the sort.Interface:

prog.go:6: type sort.Interface is not an expression
prog.go:7: cannot range over xs (type sort.Interface)
 [process exited with non-zero status]

The main problem here is that we’ve lost information - the sort.Interface is not a slice anymore. We’ve lost the ability to iterate over it the moment we created an interface out of it. We could provide all the operations which can be done on a slice in an interface, in the following way:

type Slice interface{
	Get(i int) interface{}
	// ...

We pretty much had to stop at the very first method, we have to abuse the interface{} type everywhere. If only we could write something like the following:

type Slice a interface {
	Get(i int) a
	Len() int
	Append(a) []a
}

That way, our compiler would know that the Get method of a Slice Int returns an int, the Get method of a Slice String returns a string etc.

In an expressive type system, like haskell’s, we can do exactly that. The deduping example can be stated the following way: “given a type ‘a’ which elements can be compared against each other to see if they are equivalent, we can write a function which removes duplicates from a list of these elements”.

That function, in the Haskell standard library, is Data.List.nub:

> import Data.List
> :t nub
nub :: Eq a => [a] -> [a]
> nub [8, 6, 8, 2, 4, 4, 5, 9]
[8,6,2,4,5,9]
> nub ['a', 'b', 'a', 'c']
['a', 'b', 'c']

The above snippets illustrates how nub works with a list of anything, as long as anything is an instance of the Eq typeclass - ie. there is a defined way to compare them on grounds of equality.

For those who are bothered about the quadratic algorithmic complexity of nub, let’s recreate our efficient (albeit nongeneric) Go solution in Haskell.

Nub requires the elements of the list to be instances of the Eq typeclass, that is why it performs so poorly. If we are stricter and require the elements to be instances of Ord typeclass, as is the case with Go’s maps indices, we can write a more efficient function, which pretty much does the same thing as the Go code snippet above - puts the list elements to a map and then converts back to a list:

import qualified Data.Map as M
let nubWell xs = map (\(k, _) -> k) . M.toList . M.fromList $ map (\x -> (x, ())) xs
> :t nubWell
nubWell :: Ord b => [b] -> [b]
> nubWell [8, 6, 8, 2, 4, 4, 5, 9]
[2,4,5,6,8,9]

Just to show you that it actually works on any instance of the Ord typeclass, let’s nub a list of strings:

> nubWell ["generics", "are", "useful", "useful", "it", "is", "a", "useful", "fact"]
["a","are","fact","generics","is","it","useful"]

Please note that our version of nub is not order preserving - neither is the Go version due to the randomized traversal of maps.

This thread discusses the same problem, without finding a nice solution - because there isn’t any - the type system is just not expressive enough.

Flow disruption

Perhaps the most elusive, but rather destructive aspect of the lack of generics in Go is how the language forces the user to go into uninteresting details while expressing ideas, disrupting the programmer’s flow. We don’t have to venture far to see examples of this - we can stay at the topic of list operations, as we did in the previous example.

Standard list operations

In go we are forced to use iteration as our tool to traverse slices and maps - because iteration is a polymorphic builtin construct. The verbosity of iteration is mind-bogging, combined with appending, ifs and other constructs makes the code way more involved than it should be.

Filter

Let’s observe a scenario when we want to remove elements from a slice:

xs := []int{0,1,2,3,4,5,6}

// Remove elements smaller than 4
smallerThanFour := []int{}
for _, x := range xs {
	if x < 4 {
		smallerThanFour = append(smallerThanFour, x)
	}
}

(playground link)

> let xs = [0..6]
> filter (<4) xs
[0,1,2,3]

Or if we want to remove an element from a slice

xs := []int{0,1,2,3,4,5,6}
noFiveHere := []int{}
for _, x := range xs {
	if x != 5 {
		noFiveHere = append(noFiveHere, x)
	}
}

> let xs = [0..6]
> filter (/=5) xs
[0,1,2,3,4,6]

Map

Increase every number by in in an array:

package main

import "fmt"

func incByOne(xs []int) xs {
	ret := []int{}
	for _, v := range ints {
		ret = append(ret, v+1)
	}
	return ret
}

func main() {
	ints := []int{1,2,3,4,5,6,7,8,9,10}
	fmt.Println(incByOne(ints))
}

(playground link)

> let incByOne xs = map (+1) xs
> incByOne [1..10]
[2,3,4,5,6,7,8,9,10,11]

Folding

Summing numbers:

package main

import "fmt"

func mySum(xs []int) int {
	ret := 0
	for _, v := range xs {
		ret += v
	}
	return ret
}

func main() {
	fmt.Println(mySum([]int{1,2,3,4,5}))
}

(playground link)

> let mySum xs = foldl (+) 0 xs
> mySum [1..5]
15

These operations would be possible in Go with the help of generics… although the type signature of lambdas would have to be stated explicitly, since Go does not support type inference (not the rather powerful Hindley-Milner one anyway).

The billion dollar mistake

Nil pointers, as implicit valid values for all pointer types, and interfaces are one of the most frequent sources of bugs. The problem lies in the fact that one can dereference a pointer without proving that it actually holds a non-nil value, eg.:

file, _ = os.Open("file.txt")
file.Chmod(777)

Is perfectly valid as far as the compiler is concerned. Meanwhile, using Option or Maybe types the same mistake can not be done:

> case find (==2) [3..5] of
>	Just x 	-> print "Found! Yay :)"
>   Nothing -> print "Not found :("
"Not found :("

The different cases must be handled explicitly, forcing the programmer to think about both of them.

Empty interfaces everywhere

Without generics support, it is impossible to create a generic type parametrized over an other one. It is especially painful when dealing with container-like types, sets, trees etc.

The type signature becomes littered with interface{}-s, decreasing the readabilty and the type safety of the language.

Take a look at the following package: The container/list package in the standard library

The type signature of the List type is the following:

type List
    func New() *List
    func (l *List) Back() *Element
    func (l *List) Front() *Element
    func (l *List) Init() *List
    func (l *List) InsertAfter(v interface{}, mark *Element) *Element
    func (l *List) InsertBefore(v interface{}, mark *Element) *Element
    func (l *List) Len() int
    func (l *List) MoveAfter(e, mark *Element)
    func (l *List) MoveBefore(e, mark *Element)
    func (l *List) MoveToBack(e *Element)
    func (l *List) MoveToFront(e *Element)
    func (l *List) PushBack(v interface{}) *Element
    func (l *List) PushBackList(other *List)
    func (l *List) PushFront(v interface{}) *Element
    func (l *List) PushFrontList(other *List)
    func (l *List) Remove(e *Element) interface{}

All the functions that are dealing with the elements of the List are defined with empty interfaces. That could be completely avoided if the List type could be parametrized over other types (like the builtin types map and slice can be). If you want to read more about those types, which seem to require other types to produce a ‘final type’, start here ).

Lack of algebraic data types

Algebraic data types, or sum types are basically types which can represent a certain number of fixed types.

So while in a struct the different fields are present in the same type, an ADT may contain only one of those fields at a time. An example would be:

Nondescriptive types

data Tree = Leaf
          | Node Int Tree Tree

The same concept in Go would be expressed as:

type Tree struct {
	Int int
	Left *Tree
	Right *Tree
	Leaf *Leaf
}

All the possible values would be present at all times - even if they are not being used at all. This gets messy quite quickly.

A rainbow of grey, grey, and grey

Apart from readability, type safety suffers as well. The moment we need something to be able to hold more than one type, suddenly we are forced to use interface{}

A very good example is the definition of a JSON value. In Haskell, the type reads clearly:

-- | A JSON \"object\" (key\/value map).
type Object = HashMap Text Value

-- | A JSON \"array\" (sequence).
type Array = Vector Value

-- | A JSON value represented as a Haskell value.
data Value = Object !Object
           | Array !Array
           | String !Text
           | Number !Number
           | Bool !Bool
           | Null
             deriving (Eq, Show, Typeable)

(link)

A JSON Value is an object, a string, a number, a bool or a Null value. What is the best we can do in Go?

type JSON map[string]interface{}

Multiple return values

Multiple return values are really just a special case of tuples, except they are much less composable. One might argue, they are intentionally hard to compose, so it makes ignoring returned errors harder. However that would be a pretty bad argument. Let’s examine the following code snippet:

package main

import "os"

func main() {
	file, err = os.Open("file.txt")
	if err == nil {
		return
	}
	file.Chmod(777)
}

(playground link)

The compiler happily accepts this while this is clearly a bug. Tools like Go vet may catch the errors - however - that is just band aid. Guaranteeing code correctness is the job of the compiler, a tool like Go vet may utilize ad hoc solutions to detect certain specific problems with the code but that solution will never be as coherent and all encompassing as a sufficiently expressive type system can be.

Interfaces are misdesigned

Interfaces are implemented implicitly

Interfaces in Go are implemented implicitly, which means if someone happens to come along and creates an interface with a method which your type already has your type immediately implements that interface - wether you like it or not. While this happens rather rarely in practice (in my experience), the implicit nature of this feels out of place - usually Go prefers explicitness over implicitness, why the exception here?

When writing a methods which is implementing an interface one has a specific interface in mind anyway - then why lose this information? In fact, readability suffers - one has no way to know which interfaces a type implements. It also prevents us to state how non local types implement an interface…

No way to define how a foreign type implements an interface

Who knows better how a certain type satisfies an interface than the person who defined the interface? Requiring a package to be modified so a type can implement as interface severely hinders extensibility.

Interestingly, Go already has syntax which would be well suited to this (not like syntax is an important matter when it comes to issues like this), as it is noted in this thread by Rasmus Schultz.

I was under the impression that one of the key reasons for the “detached” method-declaration syntax, was that you would be able to extend somebody else’s type with new methods required by your program, in a “non-invasive” manner.

Lack of deriving

Default implementations for certain interfaces should be provided. How can Go print out our structs or maps correctly? We don’t know. It is done with reflection, which is runtime concept and sidesteps the type system entirely. The ad hoc, edge case laden nature of Go shows here again. For those who are unfamiliar with the concept:

If we define a record (struct in Go land), and we want to print an instance of it, we get a compile error.

> data Customer = Customer { name :: String, age :: Int }
> print $ Customer "Joe" 14

<interactive>:3:1:
    No instance for (Show Customer) arising from a use of ‘print’
    In the expression: print
    In the expression: print $ Customer "Joe" 14
    In an equation for ‘it’: it = print $ Customer "Joe" 14

The compiler error tells us that our Customer type is not an instance of the Show typeclass - in Go terminology, the Customer type does not implement the Show interface. Inspecting the type signature of print we see it indeed requires any element passed to it to be an instance of Show:

> :t
print :: Show a => a -> IO ()

Using derive, we can get default implementations for free:

> data Customer = Customer { name :: String, age :: Int } deriving Show
> print $ Customer "Joe" 14
Customer {name = "Joe", age = 14}

Also interesting how our Customer type ‘officially’ became an instance of the Show typeclass:

Prelude> :i Customer
data Customer = Customer {name :: String, age :: Int}
  	-- Defined at <interactive>:7:1
instance Show Customer -- Defined at <interactive>:7:66

So while the implementation is ‘magic’, in all other regards these type classes behave the same way as they would be user implemented.

Type assertions

Type assertions are completely type unsafe - a function should never ever make assumptions about the underlying type of an interface type - that completely defies the purpose of interfaces to begin with.

Other minor annoyances

General inelegance

Superflous syntax

Almost everywhere superflous brackets of all types can be found. What is the purpose of:

map[string]interface{}

Map String Any

(hypothetical Haskell equivalent)

? Go got rid of some of these (for loop, if requires no parentheses), but there are still plenty.

Operators should be functions

The only reason operators are not functions is because the type system is not sophisticated enough to describe them.

No type aliases

Sometimes it is good to have type aliases which are basically macros doing simple string replace in the source, to increase readability, for example the excellent MongoDB driver, mgo defines a convenience type M:

type M map[string]interface{}

This is just to avoid typing map[string]interface{} when defining BSON documents. Compare:

customer := map[string]interface{
	"id": "42"
	"cats": []interface{
		map[string]interface{
			"Name": "Joe",
			"Age": 2,
		},
		map[string]interface{
			"Name": "Joline",
			"Age": 2,
		}
	}
}

vs:

customer := M{
	"id": "42"
	"cats": []interface{
		M{
			"Name": "Joe",
			"Age": 2,
		},
		M{
			"Name": "Joline",
			"Age": 2,
		}
	}
}

Unfortunately, in Go, M and map[string]interface{} become completely separate types - we have to typecast from one type to satisfy the compiler.

Conclusion

Go focuses on simplicity, but the lack of strong foundations introduces edge cases in a lot of places, making the language more complex and less useful than it could be. But even with those edge cases, Go is still easier to learn than most other typed languages, and that is probably its the biggest selling point. It very much feels like a dynamic language with a very minimalistic type system. This has the positive effect of introducing people who were exposed only to dynamic languages to the world of type system due to its approachability. However, this simplicity may very well adversely affect the Go programmers by accepting suboptimal solutions.

The support and hype it receives might be better spent on more novel languages with bigger potential to better our industry.

Appendix

Haskell - Thinking recursively

Wed, 10 Apr 2013 00:00:00 +0000

To understand this post, first you should learn...

Patterns and pattern matching

Patterns allow you to deconstruct certain data structures with the same operators what you use to construct them. This only works in certain places, but we focus on function definitions now. Examine the following one:

summa :: [Int] -> Int
summa list = if length list == 0
    then 0
    else head list + (summa (tail list))

This contains no pattern matching yet. We have to do a lot of grunt work by hand, checking the lenght of the list, accessing the first element (head), calling the function recursively on the remaining list. Pattern matching can help to lessen the pain:

summa :: [Int] -> Int
summa [] = 0
summa (x:xs) = x + summa xs

Much nicer, right? The cons operator (:) appends an element to a list, so the above quite intiutively reads like this: if we have an empty list, the result is 0. If we have a list with at least one element (x appended to the possibly empty xs), the result is the first element + summa the remaining list.

Another good example is the classic (but very inefficient) definition of Fibonacci numbers:

fib :: Int -> Int
fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)

The above calculates the fibonacci number in the nth position of the Fibonacci sequence.

Thinking recursively

Every iterative algorithm and can be expressed as recursion and vice versa. In Haskell, recursion is the norm, since iteration is impossible to do without mutable variables. This can be tricky to imagine for newbies, so let's look at a couple of examples.

-- Counts how many element satisfies the predicate in a list.
count :: (a -> Bool) -> [a] -> Int
count p xs = f 0 xs
    where
        f c [] = 0
        f c (y:ys) =
            let v = if p y then 1 else 0
            in f (c + v) ys

The where construct in the above example is a simple way to define local functions and variables. Where is similar to the let ... in form, the only difference is that ith let the definitions come before the expression body, with where they stand after it.

Our count function works by defining a recursive local function called f, which passes state as one of its arguments. Every recursive invocation can be tought of as one iteration. The same function in JavaScript would look like this:

function count(pred, list) {
    var counter = 0
    for (var i in list) {
        if (pred(list[i]) == true) {
            counter++
        }
    }
    return counter
}

A side note: a nice thing in Haskell is that we can be lazy (pun intended) and use the existing functions to express our thoughts. It really feels like synthesis. Instead of controlling every nuance of the code, we can usually achieve our goals in a couple of steps. Our count function would look like:

count :: count :: (a -> Bool) -> [a] -> Int
count p xs = length $ filter p xs

But currently we care about writing these functions ourselves to learn the thought process behind them. However, it would be silly to ignore the wide range of already written functions in the Haskell standard library (Prelude). Yes, you've heard it! Unlike in C++ or a lot of other langauges, the Haskell Prelude is full of readable, idiomatic functions. Reading them is a pleasure. Let's look at a couple of them.

map :: (a -> b) -> [a] -> [b]
map _ []     = []
map f (x:xs) = f x : map f xs

The implementation is map is actually very straightforward, we apply the function f to the first element of a list, and append that element to the remaining of the also mapped list. If you are not already blown away by the elegance of it, I suggest you to learn Java.

filter :: (a -> Bool) -> [a] -> [a]
filter _pred []    = []
filter pred (x:xs)
  | pred x         = x : filter pred xs
  | otherwise      = filter pred xs

Filter is quite similar to map, but there is new syntax here: guards. Guards are basically pretty switches, the first case evaluating to true will be evaluated. The definition reads: if the list is empty, return the empty list. If the list is not empty, check if the predicate holds true on the first element of the list, if it does, append the given element to the remaining of the list.

Most people when hear that Haskell has no mutable variables (not counting the IO monad, more on this later) are terrified by the idea and they think that working with immutability is half impossible and half crazy. But in fact, recursive solutions are often very concise and easy to write. Pattern matching helps us to visualize corner cases (empty list, zero, etc) when we have to terminate our recursion, or act differently.

Performance

Haskell lends itself especially well to recursive expressions. In imperative languages, recursion is considered slow, and iteration is preferred. Since Haskell is optimized for recursion, you don't have to fear a performance penalty. Tail call optimization actually ensures that when a function calls itself in tail position (see the summa example), the resulting machine code will be identical to loops.

Haskell - Lists

Sat, 06 Apr 2013 00:00:00 +0000

In the previous post we met most of the basic types:

Name        Example     Description
--          -------     -----------
Int         300         Machine word sized integer.
Integer     300         Infinite sized integer.
Float       3.2         Floating point numbers.
Double      3.2         Double precision floating point numbers.
Char        'a'         A single character.
Bool        True        Boolean type, can take two values: True or False.

As you can see, there is nothing complex about them. Lists are a bit different. The term "list" is not a concrete type. We can talk about a list of Chars, a list of Ints, a list of Floats and so on. Please meditate on this since this is an incredibly important and powerful concept: some abstract types need one or more additional types to produce a concrete type. And lists are a very good example to show that. First, note that we could mentally replace the type [a] with List a, as the [] is just syntactic sugar. In this regard, the list type is special, but only in cosmetics.

Higher kinded types

If you want to amuse girls, you may want to learn the proper terminology for those above mentioned "abstract types": they are called higher kinded types. You can also refer to List as being a type constructor, while List a is a lower kinded type, or in layman terms a concrete type, or simply a type. GHCi is still your friend, there is a command, :k, which will return you the kind of a type.

> :k Int
Int :: *

> :k []
[] :: * -> *

>:k [Int]
[Int] :: *

> import Data.Map
> :k Map
Map :: * -> * -> *

Wohoo! We are advancing so fast. The -> symbol means the same as in function type signatures: it separates the inputs and the output of a function. Type constructors are functions too, the only difference is that they work on types, and not on values. Let's interpret those lines. Int is a lower kinded type, [] is a type constructor, [Int] is again a simple lower kinded type, and we imported the module Data.Map just for the sake of it. It serves as an example about how a higher kinded type can need more than one type to produce a concrete type. List needs one, why? The elements in that list have a type too. But a Map can needs one type for the key, and one for the value.

Creating lists

To create a list, we have to list values belonging to the same type, separated by commas, inside square brackets:

> let x = [1, 2, 3, 4, 5]
> :t x
x :: [Integer]
> let y = [True, False, False]
> :t y
y :: [Bool]

We can do enumeration very easily too (if the given type is an instance of the Enum type class):

> [0..20]
[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20]
> ['a'..'z']
"abcdefghijklmnopqrstuvwxyz"

Lazy evaluation

Once thing you must keep in mind that since Haskell has non-strict evaluation, you can work with very large, even infinite lists without killing your machine. We already now the head function.

> -- This is how you define an infinite list:
> let x = [1..]
> head x
1

In strict languages the infinite list would halt our program (at least this thread), but not in Haskell. When we assign x the infinite list, the list is not constructed immediately, only when needed, and even then, not the whole list, but only the needed parts will be calculated. This may seem contrived at first, I mean what was the last time you needed infinitely large lists, right? Our RAM is not infinite? When programming in Haskell, we usually word our thoughts in a way which is very close to mathematics. That's why the language is sometimes called an "executable specification language". The problem is that math definitions do not match the underlying hardware, and this creates performance problems. Non-strict, or lazy evaluation helps to lessen the severity of this problem by allowing us to word our algorithm in a concise and elegant way, without going into details and micro-manage every variable, without suffering a performance penalty.

Working with lists

The module Prelude is imported by default. It contains very useful list manipulation functions. It is worthy to know most of them since many problems can be solved with list manipulation. The most used functions are:

length

> :t length
length :: [a] -> Int
> length [0..10]
11

Length (amazingly) returns the length of the list.

(:)

The cons operator makes it possible to append an element to the beginning of a list. This is an O(1) operation, unlike appending to the end of a singly linked list.

> :t (:)
(:) :: a -> [a] -> [a]
> 1:[1,2,3]
[1,1,2,3]

This operator is right associative, we can conveniently append mutiple elements:

> :i (:)
data [] a = ... | a : [a]       -- Defined in `GHC.Types'
infixr 5 :
> 1:2:3:[]
[1,2,3]

(++)

The ++ operator concatenates to lists.

> :t (++)
(++) :: [a] -> [a] -> [a]
> [1,2,3] ++ [10,20,30]
[1,2,3,10,20,30]

head, last, init, tail, (!!)

These functions allow you to extract elements and sublists from lists easily.

> head [1..5]
1
> last [1..5]
5
> init [1..5]
[1,2,3,4]
> last [1..5]
[2,3,4,5]
> [1..5]!!2
3

Lists are zero indexed in Haskell, which means we refer to the first element as not the first, but rather as the 0th element.

map

> :t map
map :: (a -> b) -> [a] -> [b]

Map is a higher order function, which means that it either takes functions as its input or returns a function. The () in the signature means a function. Map takes a function and a list and it builds a new list by applying that function to every element of the input list. Let's say we have a function double, which can double a number, and a list of numbers. Issuing map double list will return a list with the doubled numbers:

> let double x = x * 2
> let myList = [1..10]
> myList
[1,2,3,4,5,6,7,8,9,10]
> map double myList
[2,4,6,8,10,12,14,16,18,20]

filter

> :t filter
filter :: (a -> Bool) -> [a] -> [a]

Filter takes a predicate (a function returning a boolean value) and a list, and returns a new list containing only the values which satisfies the predicate. An example would be to filter numbers based on whether they are even:

> :t rem
rem :: Integral a => a -> a -> a
-- Integral is a type class implemented by both Int and Integer types.
-- Do :i Integral for more information

> let isEven x = rem x 2 == 0
> filter isEven [0..20]
[0,2,4,6,8,10,12,14,16,18,20]