λ Tony’s blog λ

I came across a thread today on javalobby. Actually, I was referred by Ricky Clarkson who seems to challenge the Java Religious Establishment with seemingly greater patience than I could possibly exercise. Here is a link to the thread.

I have long postulated that programming in general and Java particularly, exhibits some strikingly similar attributes of religious establishments. I have discussed this hypothesis with a few people and we have even come up with the idea of finding a correlation between preferred programming language and religious conviction. Of course, this was all discussion and no “doing”, but it’s an interesting discussion nevertheless. We even entertain conjectures about what we believe the outcome to be. Mostly, correlating religious ideologies that are founded on the most powerful delusions and programming languages that are also founded on extreme delusion and then extrapolating along less mature religions with more transparent delusionary characteristics.

Many people point to some of the absurdities that come out of religious establishments for humiliation, because they are well, quite blatantly in violation of sound logical reasoning. As a side note, I often observe this violation being resolved by resorting to Fideism — a symptom of the religion sickness that I hope to write about soon. I actually empathise with the people who have been manipulated into such extreme delusions. I do not encourage human suffering and I do whatever I can in terms of self-discipline to ensure that I do not denigrate to the perverted practice of esteem boosts by pointing at the weaknesses of others — mostly, because I hope and expect the same from others (I am a moral Altruist).

I encourage you to do so as well as you read the following quotes from the aforementioned thread:

• Other languages have lots of problems that java just doesn’t have.
• Most language concurrency models are inferior to Java’s.
• Most languages don’t have as good functional programming as Java.
• Java’s type system is precise and predictable, more so than many languages.

Notice how this person is convinced that these statements are true. There is no act of conscious intellectual fraud here. Ask yourself why? How on earth could someone have been led into believing such absurdities? My point is for example, there are some very plausible explanations and methods of counselling for believers in the Judæo-Christian delusion; can we use these lessons to describe the behaviour of the person quoted above, and therefore, offer counsel to this person, who is also suffering delusions? Is the approach that Ricky Clarkson is taking — assumingly to heighten the awareness of the audience of his words — a sound one? Can we make predictions about its outcome?

The infamous Robert M. Pirsig (Zen and the Art of Motorcycle Maintenance) quote seems apt:

When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion, it is called Religion.

C, Java, C# et. al. (imperative with poor type systems) languages are low level languages. Many people are not aware of this fact, especially those who are only aware of languages that are imperative with poor type systems. This behaviour is probably best described by Psychologists than I will attempt, so I will not attempt any explanations for it.

I refer to pages 58-61 of Types and Programming Languages (0-262-16209-1) on the chapter about the untyped lambda calculus where author Benjamin Pierce notes that the the value false for the Church Boolean encoding is the same as the value zero for the Church Numeral encoding.

λt. λf. f
λs. λz. z

Pierce then goes on to note that:

Similar “puns” are common in assembly languages, where the same pattern of bits may represent many different values — an int, a float, an address, four characters, etc. — depending on how it is interpreted, and in low-level languages such as C [emphasis mine], which also identifies 0 and false.

I wonder if the aforementioned programmers — those aware of only low-level languages, therefore call languages of “the highest level that I am aware of”, high-level languages — are willing to claim that Pierce has made a grave mistake, or if it will invoke the possibility that maybe there are more levels out there.

If, for just one person, it is the latter, then the objective of this post has been achieved

From http://cafe.elharo.com/java/internal-and-external-exceptions/

Perhaps the continuing confusion over the difference between checked and runtime exceptions in Java is because we haven’t named them properly.

Yippeee! About time a Jumping Java Joey took notice of that fact that language has an enormous power to influence if you are incapable of independent thought.

…I think we should should start calling checked exceptions “external exceptions” and runtime exceptions “internal exceptions”.

Ugh.

How about type error? bottom? Or undefined partial function? Or ⊥

As abruptly as there was hope, that same hope was ripped away.

I am absolutely surprised at the number of failed examples of inheritance. What troubles me is the extent of ignorance prevailing on the subject of inheritance. Every once in a while, I read an old rant by a Blub programmer making claims to an understanding of a topic while simultaneously proclaiming that there are so many others without this understanding. Less often, I am compelled to write something myself.

I will start by using Blub grammar and syntax, but try to keep the usual euphemisms and loaded words to a minimum (I have two, annotated with warnings).

Look at the following interface declarations:

interface I {
  T i();
}
 
interface J {
  U j();
}
 
interface K extends I, J {}

If a method accepts a type K, what that method really means is that it accepts a type that is composed of both type I and J, which is more general than type K. I am ignoring the fact that interface K may have some additional restrictions that are not enforced by the type system, because well, this is Blub after all and using type systems to denote formal requirement specifications is well beyond Blub. If you have a type L that is composed of I and J, you will not be able to pass it to the method. Instead, you need to write an “Adapter” (WARNING: euphemism) from L to K.

I now propose a hypothetical language (still Blub though) that allows you to pass a “I with J“, which means it might be a K or it might be some other composition of I and J. Note that a compiler can not deduce that K is composed of I and J and generalise this type, since this requires the compiler to compile I, J, K and all compositions of I and J, which is potentially infinite. In other words, time goes this way —>, not that way <–, despite what the Blub type systems say.

In my hypothetical language, you do not explicitly give method arguments types. Instead, if you call both i() and j() within the aforementioned method, the compiler or type inferencer will determine that the method argument has type I with J. Surely, you have seen software in Blub languages, where you pass a type with a bazillion methods and only one or two of those methods are used when it is passed? It’s a problem, right? Ever used one of those “mock frameworks”? (WARNING: euphemism for “workaround”). Have you ever passed a K and only called i()?

In my hypothetical language, if you only call i(), then the method argument type will be inferred to I, not K, not even I with J, since remember, we do not explicitly annotate types on method arguments.

Now, is my hypothetical language really hypothetical? No! You see, there are (at least) not-so-crap type systems out there that permit this level of flexibility. They are far more powerful than this little rant purports, but you’ll just have to take my word for that. What I have effectively described is (one aspect of) Type Classes from a language called Haskell, which can also be used in Scala and other languages with at-least-reasonable type systems.

In other words, inheritance dunrite is as easy as putting down those languages that have got it all wrong and stop pretending that they are sensible or “industry grade”. Stop trying to understand their inherent contradictions through cognitive dissonance, write books about the nonsense, invent design patterns, refactorings, workarounds and mock this and that and framework foo and blah blah blah (can I breath now?). Furthermore, standing on a pedestal and proclaiming that “I know something that you don’t so na na!” is really quite silly, even if it is true (which it isn’t more often than not as has been seen!).

There is much more to inheritance than even the most expert Blub programmer can possibly imagine. I have only just touched the surface by introducing type classes here.

Most people prefer to believe that their leaders are just and fair, even in the face of evidence to the contrary, because once a citizen acknowledges that the government under which he lives is lying and corrupt, the citizen has to choose what he or she will do about it. To take action in the face of corrupt government entails risks of harm to life and loved ones. To choose to do nothing is to surrender one’s self-image of standing for principles. Most people do not have the courage to face that choice. Hence, most propaganda is not designed to fool the critical thinker but only to give moral cowards an excuse not to think at all.

– Michael Rivero

There is a lot of misunderstanding about the difference between idempotence and referential transparency. My plan here, is to explain the key differences without going into any specific detail about either concept. I plan to write something about referential transparency in the future and when I do, I will refer here to dispel any myths regarding idempotence.

I will assume that my reader is roughly familiar with the concept of referential transparency, but not necessarily its implications (since there are many), even though some clearly demonstrate a lack of understanding of this concept, strangely accusing others of same (go figure?) and even trying to proclaim that Java has higher-kinds while suggesting that others do not understand Java’s (mediocre) type system. Ignorance is bliss and all that, anyway on with the story…

Here is a fact; all idempotent functions are also referentially transparent, but not necessarily the other way around. Let us express this fact by other means; a referentially transparent function is not necessarily idempotent, because it is (only) possibly idempotent.

Idempotence can be easily written as follows. A function (f) is idempotent if the following property holds:

f o f = f

That’s all there is to it. Since many of my audience are Java programmers, I will appeal to their potential misunderstanding here and elaborate. The o symbol means function composition. The statement can be read as “the function f composed with the function f is equivalent to (just) f”.

Function composition comes about by… well composing functions. Suppose a function (f) that accepts a type Y and returns a type Z and another function (g) that accepts a type X and a type Y that returns another function that accepts a type X and returns a type Z. We express this as f o g.

Here is an example in the favourite programming language of some:

class Foo {
  static String f(int i) {
    return Integer.toString(i);
  }
 
  static int g(char c) {
    return c + 7;
  }
 
  static String composeFG(char c) {
    return f(g(c));
  }
}

Easy Peasey right? In my statement above, the type X is char, Y is int and Z is String. Function composition is written in Java as f(g(a)). Back to the definition of idempotence, which states (in Java syntax), that f(f(a)) is equivalent to f(a). Clearly we see that f must at least have the same type in its argument and return type in order to satisfy idempotence. This means that our previous example has no idempotent functions, however, they were all referentially transparent. Furthermore, a function that is referentially transparent and having the same type in its argument and return type is not necessarily idempotent. A counter-example is easily produced:

class Bar {
  static int add1(int i) {
    return i + 1;
  }
}

Since there exists at least one (in fact, all in this case) arg for add1(add1(arg)) such that it is not equivalent to add1(arg), then add1 is not idempotent. For example, add1(add1(7)) is not equivalent to add1(7), clearly.

Here are some insights. Adhering with my naming convention, suppose the function add0. Guess what? It is idempotent. Also, multiply1 is idempotent. Every single function on this web page is referentially transparent, but only the two aforementioned hypothetical functions are idempotent.

We might write this using logic as follows for add0

∀ n | n ∈ Z. n + 0 = n

For all n such that n is an element of the set of integers, n + 0 = n [is a true statement].

…and for multiply1

∀ n | n ∈ Z. n * 1 = n

For all n such that n is an element of the set of integers, n * 1 = n [is a true statement].

For completeness, here is an actual idempotent function with the added twist of a polymorphic type parameter (generic parameter in Java speak):

class Baz {
  static <T> T identity(T t) {
    return t;
  }
}

I hope this clears some things up