Scala Application Programming is not Math

Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.

- Edsger W. Dijkstra

There is this notion that programming is doing math. It 's not true. Or to put it in a more nuanced manner: It is not true in any meaningful way for an application programmer like me.

I realized how difficult it is to speak to non-application programmers from the reactions I got to last weeks "How to not learn Scala fundamentals". We live in different worlds, me and academia. I tried to expand on my arguments in the follow up, but I probably missed the mark.

The thing is, m.map { t => val (s,i) = t; (s, i+1) }, probably is elegant, and maybe even easy to read for someone exposed to abstract functional code all day long. But for someone who uses Scala as tool, not to improve Scala, but to solve real world problems, abstract descriptions are more or less opaque. We can't easily pick up our rusty university ML experience (if we have that at all) and wrap our heads around "elegant" code like the snippet above. And we shouldn't have to.

If Scala is going to be a main stream language, usable by main stream application programmers, we need to acknowledge that most programmers don't ascribe to the maths based approach to programming.

If you learn Scala without understanding how it all works underneath, you will be less efficient, and sometimes a leaky abstraction will pop up and bite you. But that's ok. You'll still be better off than if you stick to Java. And you will understand more in time, and you'll learn to handle surprises better too.

Scala can boost productivity a lot compared to Java, and you don't need to learn all the "fundamentals" first. That's my message.

XXD Hexdump Tip

I wanted to include a png image in Scala source code as a bytearray. Just use xxd from the terminal:

$ xxd -i icon.png
unsigned char icon_png[] = {
 0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d,
 0x49, 0x48, 0x44, 0x52, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x10,
 0x08, 0x02, 0x00, 0x00, 0x00, 0x90, 0x91, 0x68, 0x36, 0x00, 0x00, 0x00,
 0x01, 0x73, 0x52, 0x47, 0x42, 0x00, 0xae, 0xce, 0x1c, 0xe9, 0x00, 0x00,
 0x00, 0x8d, 0x49, 0x44, 0x41, 0x54, 0x28, 0xcf, 0x9d, 0x92, 0x41, 0x0e,
 0xc3, 0x20, 0x0c, 0x04, 0xc7, 0x56, 0xc5, 0x03, 0xa2, 0x7e, 0xb4, 0x27,
 0xde, 0x90, 0x13, 0xef, 0x85, 0x4a, 0x56, 0x0f, 0x31, 0x14, 0x51, 0x1a,
 0xda, 0xec, 0xc9, 0x02, 0x0f, 0xac, 0x17, 0x24, 0xcb, 0xc6, 0xa1, 0x5d,
 0x79, 0xb0, 0xd4, 0xcd, 0x5b, 0x81, 0x68, 0xb0, 0x66, 0x24, 0xcb, 0x46,
 0x51, 0x80, 0x04, 0xd1, 0xbc, 0xfe, 0x2e, 0xe5, 0x4f, 0x75, 0x40, 0x34,
 0xf7, 0xb6, 0x06, 0x82, 0x11, 0xcc, 0x87, 0x0e, 0xe6, 0x3b, 0xad, 0x18,
 0x87, 0x2e, 0x7a, 0xd5, 0xd2, 0x45, 0x60, 0x57, 0x77, 0x78, 0x28, 0x55,
 0xc3, 0x75, 0x45, 0xf2, 0xf3, 0x3e, 0x32, 0xa9, 0x66, 0x50, 0x94, 0x30,
 0x06, 0x3d, 0x03, 0xda, 0xd0, 0x33, 0x40, 0x27, 0xc7, 0xb7, 0xd0, 0x7a,
 0x87, 0x69, 0x79, 0xc3, 0xd4, 0xe1, 0x4f, 0x40, 0xef, 0xd0, 0x3f, 0xdf,
 0x79, 0x5f, 0x4b, 0xef, 0xfd, 0x5b, 0x4f, 0xf4, 0xf1, 0xac, 0x2f, 0x59,
 0xca, 0x36, 0xcb, 0xec, 0xe8, 0x2f, 0xba, 0x00, 0x00, 0x00, 0x00, 0x49,
 0x45, 0x4e, 0x44, 0xae, 0x42, 0x60, 0x82
};
unsigned int icon_png_len = 211;
$ 

Copy the hex lines into your source:

val favicon:Array[Byte] = Array(...hex values here...)

Done.
People tend to forget that OS X is built upon a sturdy Unix with all the power of bash and Unix commands.

Follow Up to How to Not Learn Scala Fundamentals

I got some feedback on twitter for "How to Not Learn Scala Fundamentals", so I'll try to clarify my position a bit.

• My post is not intended to be a replacement of the original piece ("Learning Scala? Learn the Fundamentals First"), but rather a criticism of the unnecessary complexity used in his example.
• My example is not supposed to be equivalent from a teaching perspective. It is merely a supposition that if you want to add 1 to a field in a container there are easier ways to do so. And by easier, I mean easier to read. As a reader you are left with the impression that this is how it's done in Scala, and it's not.
• I do not advocate not learning the fundamentals first. I do, however, think that trying to cram 5 fundamentals into one line of code is not conductive to learning those 5 fundamentals. Maybe it works person to person, but it does not work in a blog post.
• My example is not supposed to be cleaner than the original line of code, more on that later.

To reiterate my position from the first post: I firmly believe that if you create an unnatural amalgam of many new concepts in the form of a short code snippet, you will confuse and maybe scare would be converts away. I.e., it is detrimental to getting more people using Scala. This is especially true if you claim that the snippet "is a really simple example".

As to the allegation that my code isn't as clean as the original, I can only agree. At least if immutable is cleaner than mutable.

class Cake(var name:String, var egg:Int)
...
for (cake <- cakes) yield { new Cake(cake.name, cake.egg + 1) }

Fixed. But now I would have to explain yield too. That would be my second example, building on the knowledge gained from the first example.

How to Not Learn Scala Fundamentals

Read this and shed some tears for Scala:
http://tataryn.net/2011/10/learning-scala-learn-the-fundamentals-first/
It's all about a "really simple example":

m.map { t => val (s,i) = t; (s, i+1) }

The author picked this example since it "shows off almost everything you need to know in order to get started ". Had I needed to know this to get started with Scala, I would never have started at all. Scary.

I wonder what the example does...

This is a perfect illustration of how many Scala proponents make Scala look hard, something for the elite. Maybe they find it more important to show off their skills than to help others to get started with Scala.

To be fair, the snippet above is a slide from a talk. Maybe a riddle can be a good presentation tool, but as used in the blog post it only makes Scala look cryptic and difficult to learn.

How would I write the code snippet? I don't know, perhaps something like:

for (cake <- cakes) { cake.egg += 1 }

Or if I had to use the cryptic notation from the snippet:

for (t <- m) { t.i += 1 }

But it doesn't do what the example does, you say. Correct, I cheated a bit and introduced a new class instead of resorting to using tuples:

class Cake(var name:String, var egg:Int)

A small price to pay, wouldn't you agree?

Ok, using tuples here is for demonstration purposes only. But demonstrating several new concepts in one go makes for a steep learning curve indeed.

Having said all this, I must be humble (people who know me would say "Well, that's a first.") and acknowledge that my own published code is wanting. Most of my posts containing code, have the code there to support the text rather than attempting to teach Scala. I write blog post code to be runnable. I should pay more attention to making it readable.

The Zombie Programmer

Should I try to learn new stuff? What should I learn? Learning is an investment, and with all the things I can learn, it's difficult to know where to start. What is most important right now?

Fortunately, learning can be fun, so I read about and experiment with random stuff I find interesting. For me, most of the time learning isn't an investment, it's pure entertainment.

And we all know that entertainment is what's slowly turning us into mindless zombies. That's who I am, the zombie programmer. But a fairly knowledgeable zombie...

Nothing New to See, Move along Folks

I stumbled upon this while researching my opkoko CQRS presentation (in Swedish):

"So CQRS is just what E. Yourdon described 2 decades ago but with a new name and new terms. Furthermore, readonly databases for retrieval of data and DML databases for data manipulation have been common for a long long time. Why is this suddenly ‘new’? ..."

(Comment at http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/)

Yes, it is new, but new ideas are seldom all new, usually there are older parallels. It is folly to discard new ideas just because someone said something similar 2 decades ago.

Most useful new ideas are just minor variations of old ideas, sometimes it's just that the environment has changed. Maybe CQRS is just a repurposing of Yourdon's ideas, I wouldn't know, but that is irrelevant. Putting it in the context of domain driven design makes CQRS useful, a new tool in the toolbox.