Free flowing wiki domain models and racer kids

The spirit of the naked objects applications and frameworks is to have a platform that allows one to define a domain model with some structure and behavior. The platform then will just "act" out the domain model and behave as a specialized application.

Pushing that to the extreme, there's nothing more flexible and free-flowing as a wiki. How about describing the domain in a set of wiki pages and then "act" that out?

Well - I just put the idea to the test in this new website I am playing with: http://www.racerkidz.com

This is an example page or topic, describing a 'Club': http://www.racerkidz.com/wiki/Category:Club The "Categories" stand for concepts normally represented as classes in say a UML diagram. All the domain stuff you normally define in UML can be defined as you can see here, via annotations such as "[[Roles:User:Member,Coach,Fan]]" which imply that a User can associate to a Club in one of the respective roles.

This can drive out a lof of things, including:
- capturing information
- validation of info and associations
- display and behavior of the application etc

Wiki Surfers and Wiki Snakkers

The normal function of a wiki is to describe topics and allow one to surf them as topics are related. Simply because a topic is mentioned in another topic, we know it is related. If the 'domain model' told me how the 'kinds' relate, we can make that surfing so much more interesting and functional.

Snakking, which I explored in a separate project stands for quickly grabbing some information or data from some source, based on an XPATH-like navigation model.

You can see how easily we can extend the concept of XPATH from an XML file with tags that represent concepts to a wiki structure that represents... well, concepts. As long as we know the 'kinds' of the related topics, we can surf say from a Club to its Events with something like "Club/Events" with some sort of an... Wiki Path? What do we call this? WPATH?

Actually, you can see that at work right here: http://www.racerkidz.com/wiki/Season:OO_XC_2012/xp/Race/@date which will show you the dates of all the Races of the respective Season. Note that as of right now, most of those links do not even have their topics created... yeah, there's some magic going on!

DSL vs Wiki

You could say that the tide is now firmly in the DSL's court (Domain Specific Languages). How about wikis instead?

The parallels are I think rather obvious: DSL is mostly structured with maybe free text comments as annotations while this approach in a wiki is mostly unstructured free text with structured annotations here and there...

Putting it all together

In this -I think- ultimate of incarnations of naked object models, the domain model grows as needed.

The domain model mingles domain artifacts (properties, types, kinds, categories, relationships) with free-flowing descriptions, eskeqing the need for conventional documentation. I mean everyone is able to read a wiki topic, even if they have to skip those funny annotations, right?

Filling out the actual data is also free-flowing from this domain model. At the very minimum, no extra syntax is needed, since one can simply link out and connect the topics, then the surfers and snakkers do the mining and custom logic.

Extracting data in different easily customizable ways is done easily via snakkers. The bit about behavior is a little harder and we'll explore that some other time.

Now what?

Where can we go from here? Well, there's many obvious directions.

The Semantic Wiki initiative implies the need for interaction between the separate wiki 'islands' - that implies an API.

Collaborative directories and/or indexes like DMOZ are another way to organize information. There's clearly a connection there that deserves exploring.
In fact probably a majority of new websites are the same: trying to index and organize someone else's data, drive some traffic and drink away the ad moneys. How do we instead derive new information from existing one? Or make it functional and useful at least?

Throwing some RDF, OWL and others into the mix.

Exploring the behavioral aspect - some scripting of some kind, reactive or not?

Including comments in the surfing and snakking.

Marrying this obvious graph with some graphical, visually striking presentation? My favorite is TheBrain?

The RacerKidz website

It's been fun trying out newer technologies like Play, Mongo and Scala to explore these concepts and I think the site may be useful on its own. I certainly hope for more and more active users, not only to create the oh-so-lacking contextual content about local competitive sports but to also continue exploring the possibilities of this approach.


I am generally depressed at the stupidity and laziness embodied in many a website and software today, so expect this website to become as smart and easy-to-use as I can make it.

So, if you or your kidz are interested in any competitive sports, please join in and play with it.

Cheers,
Razie

OMG, scala is a complex language!

NOTE that I cross-posted this to http://blog.coolscala.com/2011/10/omg-scala-is-complex-language.html


I keep seeing this and, maybe it’s true. Let’s chase this complexity for a bit and go through some of the biggest scala differentiators (from Java or C++, as major OO languages).

Smart compiler infers types

The compiler can infer the types for the most part, so people have to type a lot less repetitive information, which they used to type in both Java and C++. For instance, since “john” is obviously a String, the type of the variable is inferred by the compiler to be String so I don’t have to type it again:

val someone = “John”

I have seen this feature both praised and held against the language as “added complexity”, so I don’t know what to say. I just love typing less and feeling less stupid, every time I declare a value or variable.

Simplified class definitions

Since OO is all about defining classes, scala made do with a bunch of stuff in one go, so that my domain models are dead-simple:

class Person (val firstName:String, val lastName:String)

This, in Java and C++ takes about one page of code: with constructors, getters, setters etc. Scala observed that people don’t need to type one page to inform a stupid compiler that they want a person with a first and last names, so it’s all condensed in this one line, much like a table would look in SQL.

Is this added complexity? Well, I do need to worry about overriding the generated getters/setters ONLY if I need to, so I don’t really know if it’s more complex.

Me? I love this particular feature so much, that honestly, I don’t care what you think J

Unifying methods and operators

All programming languages I know discriminate between methods with names like “append” and operators like “+=”. Some do not even allow re-definition of some hardcoded operators (Java) while some allow infix notation only for operators (C++).

Scala simply makes do with ALL these restrictions and states that the name of a method can be pretty much anything and all can use the infix notation, so I can have:

ListBuffer(1,2,3) append 4

As well as

ListBuffer(1,2,3) += 4

The only difference would be the precedence rules, which are customary in all languages.

Some people obviously would see this as “more complex” than both Java and C++ since they can now do whatever they can… but I see it as “simpler” than both. Operators have been held against C++ before so it really is not surprising that they are held against scala as well.

This is, after all, what makes scala such as perfect DSL framework, allowing natural language such as:

“Mary” with “a purse” and “red shoes” should look “nice”

Types – variance

In both Java and C++, the generics have certain hard-coded and limited behavior (i.e. non-variance) and allow only a few constructs (like List<T extends Person>).

In scala, there is a default behavior, where List[Person] is non-variant, but everything is customizable. If you want co-variance, just tell the compiler List[+Person] or List[-Person] for contra-variance. Just like Java, I can use List[T <: Person] but I can use the reverse just as well: List [T >: Person].

Since scala supports implicits (with finer control than C++), another construct is available: List[T <% Person].

Is this more complicated? Well, just like the operators – it lifts certain limitations of other languages, so it’s both more complicated, since there’s more stuff to learn and simpler, since there’s less rules to live by.

I personally enjoy the extra control… do I actually use it? Not on a daily basis, the defaults are good enough.

Constructors only?

Most languages only allow data types (objects) to be constructed. This is normal in Java and C++.

Well, there’s the flipside, where I can de-construct an object and I don’t mean de-allocating its memory. Consider this:

someone match {

  case Person(first,last) => println (“ name is “ + first + ” “ + last)

}

You can see what I mean by de-constructing: took an already created object, someone, and de-constructed into its components. I know this looks foreign to most OO personnel, but trust you me, it is insanely cool and useful. Think what you would have to type in either Java or C++ to achieve the same thing, with if (instanceof) and then type cast and assign two variables and whatnot.

Is this more complex? Well, this is totally new functionality so I guess it is. But I love having it! Trust me, you will, too!

By the way, the match/case construct is way more powerful than your regular switch/case which can only handle constants… we can de-construct types, match constants, match types… and more! Check this out:

someone match {

  case Person(first,last) => println (“ name is “ + first + ” “ + last)

  case “John” |”Mary” => println (“hello, “ + someone)

  case s:String => println (“name is “ + s)

  case _ => println (“don’t know what this is…”)

}

Is this more complex? I don’t know… in Java or C++ this is between one and two pages of code. This looks simpler and more intuitive to me… granted, I got used to it but so can you!

Conclusion

There’s more areas of the language, but these are some of the major differences I have time for right now. If you have others, post up and I’ll get into those as well.

I did not get into the functional areas of the language, since that would require comparing with other functional languages and I’m not an FP guy. C++ comes close by allowing passing pointers to methods to other functions while Java 8 I think has some proposed lambda syntax.

Is it more complex? Well, there’s two ways to look at it:

Yes,

• There are more symbols and features that one can use
• There’s more computer science I need to learn (contra-variance, pattern matching, lambdas, closures etc)

No,

• The real-world problems to solve are the same and
• To do the same in either Java or C++ is either impossible or takes many times more code… and uglier code at that

What do I think? I don’t really care. To me it was cool to learn these concepts that I had forgotten since university and my new vocabulary allows me to solve the usual problems in just a few lines of code and head for an early lunch, while my mates are still writing some getter or setter…

What do you think?

P.S. This is a great detaiked discussion of complex vs complicated: http://lamp.epfl.ch/~odersky/blogs/isscalacomplex.html

Quick scala – step 1: setup

This post has a new home. If you want to setup a scala development environment, read: http://blog.coolscala.com/2011/10/quick-scala-step-1-setup.html