SIP-18 (and the Scala collections library for that matter) is no different to Haskell’s (dreaded) monomorphism restriction (DMR). The DMR was introduced specifically because of another chronically bold over-estimate of one’s ability to understand the process of learning. It is now an undesired language issue that hinders all users, especially newcomers. In other words, it serves nobody’s interest, hinders everyone’s interest and especially, the interest of those for whom it was meant to serve. You need only spend a short period of time with newcomers to Haskell to be overwhelmed by the prominence of this fact.

I can hear the pragmatists in the background muttering something about trade-offs, not being so extreme and keeping it relevant to the real world and blah blah blah, <insert the usual pragmatist bullshit here>. There is nothing to be traded off when you offer to take $5 from me for the low cost of $10. Now stop it and get your head out of the clouds so I can talk to you sensibly.

Not only does SIP-18 not help newcomers at all, it helps nobody, hinders everybody and especially newcomers. It is not a trade-off, it is not a good idea; it is simply a bold, severely misguided assertion about how learning takes place — it’s not even an approximation. I have seen only scant pseudo-psychology to support its existence, which obviates its predictable failure.

Hopefully, the Scala guys will work this out, but if Scala’s remarkable precision to repeat historical mistakes is anything to go by, I do not hold high hopes.

Thanks for asking.

• L4/L5/S1 fusion performed 15 March 2011
• Sacro-iliac fusion performed 01 November 2011

You’re being told that you cannot? What is the reason given? Because “blah blah fucking said so blah blah.” There’s your problem — you subscribe to the illusion of authority and attribute it to the claimant. Abandon the illusion. No; actually abandon it to the extent of total non-existence. “Yeah but blah blah blah…” — I totally didn’t hear what you just said, intentionally. The consequences are not what you think they are.

“Oh but how come you get to use Haskell in your job?” Because I refuse to be bullied by fools proclaiming their authority with disregard for the common goal of getting the job done. Don’t give them the leverage — by way of believing it even exists — it doesn’t. I use whatever is appropriate and Haskell is often appropriate. It’s as simple as that.

HTFU and just do it properly. Unicorns do not exist. Deal with it accordingly. HTH.

Brisbane Functional Programming Group

01 September 2011

Data Parallelism in Haskell from Rob Manthey on Vimeo.

1. Option.flatMap
   In Scala where we would normally write:

   (a, b, c, d) => for {
     aa <- a(argsa)
     bb <- b(argsb)
     cc <- c(argsc)
     dd <- d(argsd)
   } yield f(aa, bb, cc, dd)

   While in Java we write:

   // ceremony in the absence of closures
   // has been omitted (and altered slightly) for brevity
   a(argsa)?.b(argsb)?.c(argsc)?.d(argsd).f();

   This syntax denotes the bind operation of Option monad, while Scala’s for-comprehension works for any monad. A pedantic point of note is that, from a particular perspective, Java’s syntax is slightly weaker than monad syntax, in that it is in fact, an applicative functor comprehension (not monad), since subsequent computations do not have access to previously computed values along the chain (if this is confuzzling, never mind — it’s important point otherwise, but not so much here). Scala’s for-comprehensions allow this, but it hasn’t been demonstrated above.

2. Option.getOrElse

Java calls this ?:, so while in Scala we might write value getOrElse k, or if you prefer Scalaz, value | k, in Java we’d write value ?: k. The Java version maintains the usual lack of safety of null, while Scala uses an algebraic data type.

Among many differences between Scala and Java here, one is that Scala does not introduce syntax for these two specific functions — after all, why would you? Further, what about the zillions of other useful functions? Java has no user-defined call-by-need unification, which means it is not possible to write ?: yourself (even with a different valid Java identifier as a name). I wrote about this once before. I expect this is the reason for introduction of syntax for representing individual functions.

Scala’s representation is also safer, in that it uses a data structure to denote a list with a maximum length of one, rather than a value with type T, oh wait, just kidding, it might be null!

My favourite part of Java’s proposed introduction of syntax for two very specific functions (among hundreds of others), watered down to be not-quite-as-useful, is the assurance that I am still going to hear about how Scala is complex, while Java is not. Fun times.

Edit: Proposed Java syntax.

trait Lift[F[_]] {
  // Spot the pattern in these type signatures
  // of increasing arity.
 
  def lift0[A]:
    A => F[A]
 
  def lift1[A, B]:
    (A => B) => (F[A] => F[B])
 
  def lift2[A, B, C]:
    (A => B => C) => (F[A] => F[B] => F[C])
 
  def lift3[A, B, C, D]:
    (A => B => C => D) => (F[A] => F[B] => F[C] => F[D])
 
  // ... and so on
 
  // The relationship between lift<N> and lift<N-1>
  // can be given by a function,
 
  def ap[A, B]:
    F[A => B] => (F[A] => F[B])
}
 
trait LiftImpl[F[_]] extends Lift[F] {
  // Each lift function uses
  // the previous lift function and ap.
 
  def lift1[A, B]:
    (A => B) => (F[A] => F[B])
    = ap compose lift0
 
  def lift2[A, B, C]:
    (A => B => C) => (F[A] => F[B] => F[C])
    = f => ap compose lift1(f)
 
  def lift3[A, B, C, D]:
    (A => B => C => D) => (F[A] => F[B] => F[C] => F[D])
    = f => a => ap compose lift2(f)(a)
}
 
// Notes
// * lift0 is often called: unit, return, pure, point, η
// * lift1 is often called: fmap, map, ∘
// * lift<N> is often called: liftA<N>, liftM<N>

All that is left to do is to implement the LiftImpl trait! You can do this by implementing the ap and lift0 functions.

Examples of implementations that I know will work out if you try to implement them:

Those last couple are a bit funky, but a lot of that is syntax noise rather than anything too complicated. Fill out the body of those classes!

• The purchase and consumption of 31 medical text books on lower limb orthopaedics, neurology, neuro and spinal surgery and radiology.
• Uncountable subscriptions to medical journals.
• 18 MRIs, 4 CAT scans, 3 XRAY scans, 3 bone scans.
• 12 surgical procedures; 8 to the lower limb, 3 to the lumbar spine. 1 (successfully) minor procedure performed by myself for a medical emergency for which acknowledgement was initially refused and later accepted after surgical extraction of foreign body.
• 29 doctors
• AU$130K (total estimated)
• Having been misdiagnosed by a not-so-clever person named Dr Leigh Atkinson, including the suggestion that my chronic pain is “caused by the holy ghost.” Yes, seriously, he said this — while also in the room with a qualified medical professional (whom he called delusional in the same rant). He also claimed that I did not have Entrapment Neuropathy of SPN when I told him I strongly suspected it. I did — surgically verified by lower limb orthopaedic specialist (November 2009).
• Having been repeatedly told for nearly two years by Dr Michael McEniery, who would threaten to sue me again if I was to call him incompetent or dangerous (even though this might be my genuinely held opinion based on substantiated fact and so he would lose) that I am obsessing about a minor condition, requiring no medical intervention, and that this obsession is because of the athletic demands of myself and my coach.
• Having executed a partially-successful mission to demand immediate medical attention in March 2009 at significant expense.

I have successfully and single-handedly diagnosed:

• Entrapment Neuropathy of the Superficial Peroneal Nerve, 10cm proximal to lateral malleolus (unilateral).
• Foraminal Stenosis of the Fifth Lumbar (L5) Nerve Root (unilateral).
• Spinal instability (Spondylolisthesis) at Fifth Lumbar (L5).
• Withdrawal from morphine and oxycodone after immediate cessation.

These conditions were caused by a single acute sporting injury in July 2007. I have been treated for all.

L4,L5,S1 fusion 15 March 2011

PS: This is why I sometimes demonstrate low tolerance for stupidity and/or failure or refusal to entertain the possibility of thinking. People get hurt. No, I am not sorry.

It’s not possible to write bug-free programs.

This particular myth is quite popular, and its recent inclusion in a discussion I had has prompted me to write this post. The profound fact of this matter is that this statement is “as false as you can get.” In other words, there exists a formal proof of its negation, and subsequent counter-examples. It has also been my experience that belief in this myth has degenerative practical implications.

To emphasise the point, there exist programming languages for which it is impossible to write an incorrect program. What does it mean for a program to be correct? It means the program terminates. Such languages include (in order of my decreasing experience with them): Coq, Agda, Epigram, Isabelle.

Some people like to think “correctness” includes the thoughts of one or more persons in order to make the assessment. For example, one might proclaim, “sure you have a proof of program termination, but that is not the program that I asked for!” I think this is a poor use of the term “correctness” and I am not considering it any further here.

There is a problem with the aforementioned programming languages. A big one. While you always have correct programs in these languages, you cannot have all general programs. This is a well-documented contention. So you might say that these languages set out to achieve the objective of emphasising correctness, but at the expense of generality — in other words, they are exploring the question: “just how general and practical can we get, without sacrificing absolute correctness?” In my opinion, this is a very important question and worthy of further research.

Other programming languages sacrifice correctness for generality. In my typical work (I work for a product company), this includes languages such as Haskell, Scala and even Scala’s type system (which can be used as an embedded language). I expect most of my readers fall into this category of usage of languages. That is, we are all using languages that explore the question: “just how correct and practical can we get, without sacrificing generality?” In my opinion, this is a very important question too.

In the pursuit of answering both of the above questions, there are a number of contentions that arise. This means that there is not a holy grail programming language. It also means that there is a lot to understand before even starting to talk about the merits of correctness (aka static typing). This is unfortunate given the strong compulsion for, and quality of, popular commentary — we spend too much time clearing up myths. I digress.

However, this issue of contentions and trade-offs does not preclude the existence of questions of dismissal of programming languages. That is, it is possible to ask, and even answer, the question of whether or not there are programming languages that offer nothing toward resolving all of these (meaningful) contentions with respect to peer programming languages. These programming languages may be dismissed as offering nothing toward the goals of computability. It may be said that they are “universally impractical” with respect to the goals of computability (I am explicitly distinguishing here from social objectives). This may seem pessimistic, but it’s just a fact of the matter.

I hope that helps.