In Relation To

One of the things most people are taught early in their scientific education is that extrapolation is unreliable. And yet it's always seemed to me that the tendency of the Human mind to extrapolate current trends to the unknown future is so reflexive that we barely notice ourselves or others doing it. A huge percentage of popular debate in many fields (politics, economics, culture, science) falls prey to this fallacy. The fallacy is especially visible right now in the totally debased discussion of the causes and effects of climate change. Few of the loud voices on either side of this discussion, no matter how many times they mention the word science are actually doing anything remotely approaching a critical, sceptical, Popperian scientific method. It's the victory of Kuhn's description of science, but vulgarized to the level of cable news, and then repurposed for political ends. There's barely a word written on this topic that isn't dripping with confirmation bias. A plague on both your houses.

Gilad Bracha writes.

A number of people have asked if Ceylon will have tuples. Well, I suppose, why not? It's easy enough to write the following generalized algebraic datatype:

Today I came up with an awesome new way to do annotation constraints in Ceylon, essentially using the metamodel types (yes, I mean the metamodel types, not the actual metamodel type instances) as a kind of query language for program elements. The advantages of the new approach are:

A method reference like Float.times is represented in curried form in Ceylon. I can write:

I just ran across a great usecase for existential types (like Java's wildcard types, which Ceylon doesn't and won't support). It's a little involved, and revolves around an advanced feature of Ceylon that other languages don't have: the typesafe metamodel. But let me see if I can get the idea across.

Despite having spent several years designing frameworks and specifications based around the notion of dependency injection, I've never especially considered myself a big fan of the whole thing. Dependency injection strikes me as more of a fashion within one particular programming community than as some enduring pattern that will be reproduced in future languages by future framework designers.

I've updated Part 3 and Part 11 of Introduction to Ceylon to incorporate some recent revisions to the language and fill in some missing details. I've also added some extra material explaining the reasoning behind a couple of the important decisions we've made.

Folks, all the blogs crowing about the incredible wonders of ohmigod functional programming!!!! — by which you mean using higher-order functions like map() and filter() in some language with ubiquitous side effects — are getting pretty tired. Back in the 80's, Smalltalk guys used to call that object-oriented programming. It's a stupid accident of history that Java doesn't have higher-order functions, and so putting them back in where they should have been all along isn't really some great paradigm shift. Now, there is a lot that the Java family of languages is in the process of learning from the really interesting work on type systems done in the academic community around languages like ML and Haskell, but higher-order functions are somehow the least interesting thing there.

I can't wait to try my hand at creating a Ceylon wrapper for JavaFX 2. The Ceylon language was designed with this kind of problem in mind. And JavaFX was originally designed for a language with some of the same ideas in it as Ceylon. Damn, better get back to work on that damn compiler I keep promising...