Dynamic vs Static

A Semantic Web Primer for Object-Oriented Software Developers "In contrast to object-oriented systems, where objects normally cannot change their type, applications based on Semantic Web technology can follow a formal, yet dynamic typing system. RDF and OWL classes themselves are also dynamic, it is possible to create and manipulate them at runtime. For example, one could define a temporary class that is formally represented as an OWL expression and then ask the reasoner about the instances of this class. This means that reasoners can be compared to rich query answering systems. These queries can not only be asked at ontology design time, but also at execution time."

Sheeple

Happy sheep (mp3) "There are more than 110-million sheep in Australia. Almost 3-and-a-half million are exported overseas every year. In a bid to allay public concern about sheep welfare, a group of CSIRO scientists in NSW is working on a rather unusual project.

They're trying to work out how to tell if a sheep is happy."

Firstly, they have been able to train sheep to press a lever when they were discontent and they also found that sheep have a sense of time.

Now to the point, when sheep are in a paddock without shade they will just be distributed throughout the paddock. However, if they are hot (discontent) and there are trees they will obviously move to the shade. So it's difficult to tell the difference between a discontent sheep that has no other option or a content sheep. If there is an alternative and they are discontent then they will move to the better alternative.

Two Steps Further

Clearing the Air - More Languages that Suck taking the sucks and other words in combination with computer languages to the next level. Where Fotran sucks the least and Javascript sucks the most. There was also a correlation between hackiness and suckiness.

Update: Javadevelopers f*** the least "Just to add a further number to the study -- because Andrew unexplicably omitted Python -- here's the data: about 196,000 files / 200 occurences -> 980. That's the second highest result, placing it between Java and Perl (note that the higher the number, the less f***s -- I would have normalized that by taking it 1/n, but, fuck, there's always something to complain)."

Update: Using Google Code search to find the programming language most likely to drive you mad "From this we can clearly see that C is leading the pack, with TCL obviously a pretty mind-bending second place."

OO is a trick, functional programming is a lie and C# sucks

Good Ideas, Through the Looking Glass (PDF) "Enough has been said and written about this non-feature [goto] to convince almost everyone that it is a primary example of a bad idea. The designer of Pascal retained the goto statement (as well as the if statement without closing end symbol). Apparently he lacked the courage to break with convention and made wrong concessions to traditionalists. But that was in 1968. By now, almost everybody has understood the problem, but apparently not the designers of the latest commercial programming languages, such as C#."

"To postulate a state-less model of computation on top of a machinery whose most eminent characteristic is state, seems to be an odd idea, to say the least. The gap between model and machinery is wide, and therefore costly to bridge. No hardware support feature can wash this fact aside: It remains a bad idea for practice. This has in due time also been recognized by the protagonists of functional languages. They have introduced state (and variables) in various tricky ways. The purely functional character has thereby been compromised and sacrificed. The old terminology has become deceiving."

"...this writer believes that a more effective way to let a system make good use of parallelism is provided by object-orientation, each object representing its own behaviour in the form of a “private” process."

And on Object Oriented Programming: "Objects are records, classes are types, methods are procedures, and sending a method is equivalent to calling a procedure...Was this change of terminology expressing an essential paradigm shift, or was it a vehicle for gaining attention, a “sales trick”? "

The State of the Semantic Web

TripCom define their project as: "We will improve the ideas of Tuple Space computing by adding semantics by use of a graph-based data-model to rely on Triples. The Triple Space serves as a persistent publication system for semantically linked information in semantically clustered subspaces. We will develop a scalable and linkable Triple Space storage, based on improving and combining current RDF Stores and Tuple Space infrastructures."

I came across their "State of the art and Requirements Analysis" it mentions YARS, Jena, Sesame, 3store, Kowari, JRDF, Edutella and Oracle. They seem especially keen on YARSQL and its support for provenance. They also seem interested in extending SPARQL to support subqueries and inserting and deleting statements.

I'm Sick of the Anti-Thor Rhetoric

The flying spaghetti monster "Why do you call yourself an atheist? Why not an agnostic?

Well, technically, you cannot be any more than an agnostic. But I am as agnostic about God as I am about fairies and the Flying Spaghetti Monster. You cannot actually disprove the existence of God. Therefore, to be a positive atheist is not technically possible. But you can be as atheist about God as you can be atheist about Thor or Apollo. Everybody nowadays is an atheist about Thor and Apollo. Some of us just go one god further.

When you're talking about God, are you really talking about the God of the Bible -- Yahweh of the Old Testament?

Well, as it happens, I am because I have an eye to the audience who's likely to be reading my book. Nobody believes in Thor and Apollo anymore so I don't bother to address the book to them. So, in practice, it's addressed to believers in the Abrahamic God."

More provactively, "My sense is that you don't just think religion is dishonest. There's something evil about it as well.

Well, yes. I think there's something very evil about faith, where faith means believing in something in the absence of evidence, and actually taking pride in believing in something in the absence of evidence. And the reason that's dangerous is that it justifies essentially anything. If you're taught in your holy book or by your priest that blasphemers should die or apostates should die -- anybody who once believed in the religion and no longer does needs to be killed -- that clearly is evil. And people don't have to justify it because it's their faith. They don't have to say, "Well, here's a very good reason for this." All they need to say is, "That's what my faith says." And we're all expected to back off and respect that. Whether or not we're actually faithful ourselves, we've been brought up to respect faith and to regard it as something that should not be challenged. And that can have extremely evil consequences. The consequences it's had historically -- the Crusades, the Inquisition, right up to the present time where you have suicide bombers and people flying planes into skyscrapers in New York -- all in the name of faith."

Precedence in SPARQL

A recent, "bug report" on the Jena mailing list was sent to me. Basically, it's saying that ARQ doesn't execute SPARQL the way that was expected and JRDF was being held up as correct.

This has to do with the "Nested OPTIONALs" problem, as described by Richard Cyganiak. It basically boils down to the fact that ARQ interprets queries in a left to right, top to bottom fashion; which is the way the SPARQL standard defines it. For example, { <pattern 1> opt { <pattern 2> opt { <pattern 3> } } } should be executed as: take the results of <pattern 1> opt <pattern 2> and then take the results and optionally match <pattern 3>.

This is contradictory to the expression: 6 / (3 - 2), where you perform what's most deeply nested first. To me SPARQL is saying the correct answer is 0 (2 - 2) rather than 6 (6 / 1).

For JRDF to meet SPARQL's requirements I'd either have to reorder the query or change to another compiler compiler, as SableCC is only an LALR parser. Again, not currently a problem for my current JRDF work but if I really want to stamp it SPARQL, when there are test cases that will fail, it will have to be fixed.

Update: This still seems an ongoing issue with the DAWG, "Issues with evaluating optional: Commutativity of AND".

How to Win Against Terrorists? Don't Fight a War

Fighting terrorism with justice "What is remarkable is how American policy-makers have refused to learn from the historical experiences of Great Britain, a country that faced terror threats for decades in Northern Ireland, from no surrender zealots motivated by religious and nationalist fervor. In the case of the IRA, several hundred terrorists were organized after 1978 into secret cells that could wage terror pretty much indefinitely. The IRA was embedded within a global terror network that included Marxist guerrillas in South America, ETA in Spain and foreign governments, such as Libya. Not so different from al Qaeda.

Even a passing familiarity with the history of Northern Ireland would provide us with pointers on how not to deal with Islamist terrorists. First, between 1761 and 1972 the British government passed 26 legislative acts containing features designed to combat Irish nationalists, including measures seen in the US Patriot Act such as detention without trial and the suspension of habeas corpus. In the 1970s, the war model led British security services to use harsh interrogation techniques such as hooding, subjecting suspects to loud noises, sleep deprivation, prolonged standing, slaps to the face and slow starvation of detainees. When this severe ill treatment eventually [as it always does] becomes public knowledge, it undermined the legitimacy of government counter-terror policies, and created new constituencies of sympathizers in Northern Ireland. Repressive British government policy in the 1970s-from massacre of 'Bloody Sunday' to the internment of terror suspects without trial and a 'shoot-to-kill' policy in the 1980s, opened up a wellspring of support for a militaristic and Marxist-inspired IRA, which may not have existed otherwise.

In the end, it was only in the 1980s, late 1980's, when the British government moved from a 'war on terror' model to a law enforcement model that it began to win the struggle against Irish nationalist terror groups."

A BBC article supports this: "...the most recent example happened in 1971, when the British Government introduced the internment of hundreds of republican suspects in an attempt to shut down the IRA. The tactic was abandoned four years later and is thought to have increased support for the IRA."

See previous post from 2002, "Using the American model to solve all acts of terrorism".

Agile Bigger than Jesus

Software Development: It's a Religion "But software development is, and has always been, a religion. We band together into groups of people who believe the same things, with very little basis for proving any of those beliefs. Java versus .NET. Microsoft versus Google. Static languages versus Dynamic languages. We may kid ourselves into believing we're "computer scientists", but when was the last time you used a hypothesis and a control to prove anything? We're too busy solving customer problems in the chosen tool, unbeliever!"

Robert Glass

Author Interview: Robert Glass "If you had to sum up today's state of the art from the perspective of someone who experienced software development in the sixties, seventies, and eighties, what would you say are our best and worst traits.

Bob:Best traits? The depth and quality of available tools. The Agile belief in people over process. The Open Source focus on fun over duty.

Worst traits? The "us vs. them" mentality which causes today's programmers to see themselves as a separate and competing breed from yesterday's programmers. The tendency to reinvent wheels. The belief in Agile processes as being good for all problems. The hyped belief in Open Source as the best of all possible ways of building software."

Developer.* has some of his work, "Software Maintenance is a Solution, Not a Problem", "Success/Failure Criteria: Some Surprises", and "The Many Flavors of Testing".

Egomania Itself

"How many 2-word anagrams of "Agile Manifesto" do you think there are?" Follow up to Good Agile, Bad Agile.

"In any case, the whole discussion about whether Google's approach is viable for tech companies in other domains is a red herring. Most companies don't use Agile Methodologies, or if they do, it's only a handful of teams, maybe 10% or fewer, I'd guess. At least it's true at the companies I know lots of people from - Sun, Microsoft, Yahoo, Amazon, Google, Blizzard, and other places like them: industry leaders who write kick-ass software. They do it almost entirely without Agile. It's not just Google. It's everyone."

WTF

It's easy to prove what rules vs what sucks using Google. So using the new Code Search it's also easy to find out which language is most likely to produce the word "fuck" is in the code - the ultimate test of how good a language is (or how well things are going).
So here it is (higher the better):

• C++ ~835,000 files / ~2000 fucks = 41.75.
• Java ~766,000 files / ~500 fucks = 1532.
• Ruby ~254 files / ~60 fucks = 4.2.
• Perl ~186,000 files / ~400 fucks = 465.
• PHP ~195,000 files / ~2000 fucks = 97.5.
• Lisp ~400 files / ~100 fucks = 4.
• Scheme ~400 files / ~50 fucks = 8.

Benefits of Spicy Languages

"Functional Programming For The Rest of Us" seems to pretty much cover most topics that I've come across with functional programming, except for monads. There's also an interesting presentation by Shriram Krishnamurthi about Web programming and the suitability of some ideas from functional programming (continuations mainly) and the applicability of the MVC pattern. He also states that languages should incorporate things that people have to do over and over again like garbage collection.

"Since every symbol in FP is final, no function can ever cause side effects. You can never modify things in place, nor can one function modify a value outside of its scope for another function to use (like a class member or a global variable). That means that the only effect of evaluating a function is its return value and the only thing that affects the return value of a function is its arguments.

This is a unit tester's wet dream. You can test every function in your program only worrying about its arguments. You don't have to worry about calling functions in the right order, or setting up external state properly."

"A functional program is ready for concurrency without any further modifications. You never have to worry about deadlocks and race conditions because you don't need to use locks! No piece of data in a functional program is modified twice by the same thread, let alone by two different threads."

"An interesting property of functional languages is that they can be reasoned about mathematically. Since a functional language is simply an implementation of a formal system, all mathematical operations that could be done on paper still apply to the programs written in that language."

"Most people I've met have read the Design Patterns book by the Gang of Four. Any self respecting programmer will tell you that the book is language agnostic and the patterns apply to software engineering in general, regardless of which language you use. This is a noble claim. Unfortunately it is far removed from the truth.

Functional languages are extremely expressive. In a functional language one does not need design patterns because the language is likely so high level, you end up programming in concepts that eliminate design patterns all together. Once such pattern is an Adapter pattern (how is it different from Facade again? Sounds like somebody needed to fill more pages to satisfy their contract). It is eliminated once a language supports a technique called currying."

SPARQL to SQL

Semantics Preserving SPARQL-to-SQL Query Translation for Optional Graph Patterns "...we proposed: (1) an efficient algorithm, BGPtoSQL, that generates an SQL query equivalent to an input SPARQL basic graph pattern to be evaluated over the triple store, and (2) a generic query translation strategy and an efficient algorithm, SPARQLtoSQL, that translates an input SPARQL query with a basic graph pattern or an optional graph pattern to an equivalent SQL query. To our best knowledge, our algorithmic solution for the optional graph pattern query mapping problem is the first published in the literature."

The Common Misunderstanding of Design Patterns

A little while ago, I responded to Andrae talking about how patterns were just language defects. As I pointed out, "Design patterns are not reliant on OO, Java, C++ or any particular language or programming paradigm." and as an example the singleton pattern disappears when you use Spring et al.

Similarly, a much more popular blogging group are talking about the same thing with "Ralph Johnson on design patterns" and one of the author's of "Design Patterns" response, "Design patterns and language design".

Mark Dominus writes, "If you're a language designer, and a "pattern" comes to your attention, then you have a great opportunity. The programmers using your language have a recurring problem. They have to implement the same solution to it, over and over. Clearly, this is a good place to try to expend some design effort; perhaps you can trade off a little simplicity for some functionality and fix the language so that the problem is a problem no longer.

Getting rid of one recurring design problem might create new ones. But if the new problems are operating at a higher level of abstraction, you may have a win. Getting rid of the need for "subroutine call" pattern in assembly language opened up all sorts of new problems: when and how do I do recursion? When and how do I do coroutines?"

And Ralph Johnson, "No matter how complicated your language will be, there will always be things that are not in the language. These things will have to be patterns. So, we can eliminate one set of patterns by moving them into the language, but then we'll just have to focus on other patterns. We don't know what patterns will be important 50 years from now, but it is a safe bet that programmers will still be using patterns of some sort."

So this goes to the heart of what good design is. Putting in double dispatch or multiple inheritance is not necessarily an overall win in language design whereas something like closures may be. But like most things, especially related to design, proficient users are usually too close to the problem to make the right call.