weight transfer

Quote

Here's why understaning and managing weight transfer is critical: many crashes are due to locking up the front wheels under braking. This, more often than not, is due not to braking too hard but simply not waiting for the weight to transfer forward, increasing the traction!

Read more: http://www.enduroschool.com/wiki/Razie_Enduro_School/Weight_Transfer

weight transfer for control

Quote:

As you enter a turn, you may transfer some weight to the inside peg, to help push the bike into the turn.

Read the rest: http://www.enduroschool.com/wiki/Razie_Enduro_School/Weight_Transfer_for_Control

The Option monad pattern thing

A new pattern to use Options to simplify lots of code.

This post moved to a new location: http://www.coolscala.com/wiki/Cool_Scala/The_Option_monad_pattern_thing

Knowticing

Quote

Serious practice is about knowticing. I don't think one can excel or get any better in fact at any sport, without knowticing.

http://www.racerkidz.com/wiki/Blog:Razie_Coaching_Blog/Post:Knowticing

Enduro School - standing position

Quote

The best enduro riders today have a trails background and they tend to stand all the time (trials bikes have no seat by the way).

Read more here: http://www.enduroschool.com/wiki/Razie_Enduro_School/Standing_position

Adjusting and setting up a Dirt Bike

Quote:

You should setup the dirt bike properly even if you don't want to race but just ride around for fun. A properly adjusted bike makes it that much more enjoyable and easy.

Read more here: http://www.enduroschool.com/wiki/Razie_Enduro_School/Dirt_Bike_Setup

Enjoy!

Dirt bike - Adjusting the levers

Quote:

Adjusting the levers is as important as getting shoes the right size!

Read the rest here: http://www.enduroschool.com/wiki/Razie_Enduro_School/Adjusting_the_levers_for_a_dirt_bike

Enjoy!

Handlebar Setup for a dirt bike

Quote:

Setting up the handlebars is important for comfort and control

 Read the rest here: http://www.enduroschool.com/wiki/Razie_Enduro_School/Handlebar_Setup_for_a_dirt_bike

Enjoy!

Choosing a Dirt Bike

Quote:

Each of us is different, in terms of height, weight, phisical condition, biking experience etc, so it's hard to give you guidelines. I will instead tell you my story.

Read the rest here: http://www.enduroschool.com/wiki/Razie_Enduro_School/Choosing_a_Dirt_Bike

Enjoy!

2010 KTM 690 Enduro Review

Quote:

Riding it to work the next morning, strait from the dealer, 1 hour on the freeway up to 130 km/h, I must say I was really doubting my choice when I got to work.

Read the rest here: http://www.enduroschool.com/wiki/Razie_Enduro_School/2010_KTM_690_Enduro_Review

Enjoy!

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

Scala DSL technique - if-else constructs

Post moved to http://www.coolscala.com/wiki/Cool_Scala/Scala_DSL_technique_if-else_constructs

A scala DSL technique - collecting

This post was moved to http://www.coolscala.com/wiki/Cool_Scala/A_scala_DSL_technique_-_collecting

My worst internet shopping experience - gogglesgiant.com

My worst internet shopping experience, by far, has been with GogglesGiant.com , trying to get replacement goggles for my son's ski goggles, in the middle of the season.Order two pairs, in early February, from their online store at gogglesgiant.com, promises of fast shipping etc.

After two weeks I ask them that I haven't' seen a shipping notice and what's the delay and they reply that there's a high order volume and will ship when they can! Seriously, I will forward anyone their email!

I know I should've asked for the order to be cancelled right there, but I can't take a hint, eh?

After another week I receive a shipment notice with no tracking number. After another 3 weeks I receive the package, for a grand total of 6 weeks.

By now is late March and the season is basically over!

Done? Nope.They screw up and send me the wrong size for one of the lens. I write them back with a photo of the SKU and get ignored! After 1 week, I write again and receive this reply: mail us back the wrong lens and we will refund the cost of the lens. They refuse to send me the right lens, will just refund the cost, without shipping charges.

Reason: "we can't modify the original order". Seriously? I know it sounds too hard to believe, but these guys are for real! Again, I will forward anyone their original emails!

I get stuff shipped for free from Hong Kong in 3 weeks and these guys take 5-6 weeks! They refuse to make good on the order! It's insane, really! I would seriously suggest you look elsewhere for goggles. Ebay hasn't failed me yet. Actually this was the first time I strayed from Amazon and Ebay and I get screwed.

Also, they are a Yahoo Store and theirs is the worse complaining and merchant rating system ever. I hope they go banckrupt. I will and you should avoid any so called Yahoo Store.

I won't send them the wrong size only to get screwed again. I'll loose 40$ but I won't throw more good moneys after the bad.

Again - Goggles Giant cost me 40$, send me the wrong size, didn't send the order until after the season was over and have the worse customer service online... who lies through their nose!

Unfortunately I don't have a lot of recourse here. I can't even open a ticket with my credit card company because it has been like 9 weeks already now... smart buggers! Yahoo stores accept complaints only 6 weeks and after 30 minutes of browsing their website I can't even figure out how to rate this store or open a complaint!

Argh!

Scala DSL - realistic looking options

Trying to simulate the way options are passed to unix commands via '-'.

This post was moved to http://www.coolscala.com/wiki/Cool_Scala/Scala_DSL_-_realistic_looking_options

Embracing change

A little story of changes and why having options is awesome.

My favorite browser was Chrome, obviously. Until I got a tablet PC and Chrome sucked at multitouch and gestures. Then my favourite browser became IE… of all things. Then I wanted to disable flash to get more juice out of the battery and less crap on the screen… now my default browser is Firefox.

My favorite Twitter client was Tweetdeck until I got really bored with its inability to browse wide when I turned the iPhone around. Now my favourite tweet client is Twitter’s.

A few things to note from this:

• The “bar” keeps rising as useful features become standard.
• Change is accelerating and the world is a better place because of this.
• Competition and voting with feet is insanely healthy (or healthy for the insane?).
• I think that most people put up with missing features only for a while and what really kills software is slowness to evolve as well as lack of frequent releases.
• One must always have some cheap features on a short term roadmap, to ensure that clients will get something continuously

It also begs a few questions:

• Do you think that people become accustomed to seeing through the software they use and focus on the actual problem, switching said software often?
• How does this translate into a change-hating enterprise environment?
• Why do we still have politicians?

P.S. I wrote this using vi inside a Word document, on my tablet, while commuting to work; published it by tethering my internet connection through the iPhone while listening to an internet radio station stream…how cool is that? Can that be considered “giving back to the internet”? Are we Borg?

P.S. 2 - right after, iPhone crashed 3 times trying to sever the tether...not sure what that means...

A scala Workflow: Engine and DSL

I've been meaning to write a workflow engine/language for sometime and recently, some scala DSL discussions gave me the motive. I know there's tons of workflow products but none complete and to my liking.

The rest of this post moved to http://www.coolscala.com/wiki/Cool_Scala/A_scala_Workflow_-_Engine_and_DSL

The Book Of JOSH

[Razie's note] I recently realized that I'm also shifting my mental models trending back to simplicity, so I wanted to re-read this blog...but could only find a copy of it - the original had disappeared. I enjoyed it a lot and figured the more copies the better, so I shamelessly copied the copy below. Enjoy!

---

For reasons unknown, this article has been removed from the author’s blog, but Google Reader remembered it for me! I have not been able to find the author’s contact information.

All credits to The Grey Lens Man!

---

Mar 23, 2009 1:47 PM

The Book Of JOSH

from The Grey Lens Man’s View by The Grey Lens Man

Scala In The Enterprise

Recently, we’ve decided to use Scala as part of an enterprise software solution stack. And I’d like to mention a few things on how the hell that was allowed to happen.

But first lets take a stroll and talk about a thing called enterprise IT.

The Problem

You see, I have a small problem – 3 million lines of RPG and COBOL, 5,500 logical and physical files on a few AS400s that are not exactly cheap. Even better through the years, the system has been cloned and forked so several incompatible versions of exist through out the world.

A few years ago I spent 3 months focused on the “original” implementation in a architectural reverse engineering exercise. The result, I know roughly the raison d’etre for 10% or ~ 300K SLOC of code and a few hundred files. 90% of that self-contained universe of code and tables is my personal dark matter question, I know its out there, just no clue as to its nature.

I won’t go into excruciating detail, but let me leave it like this; within that 2.5 T of data there resides a special flag in the customer file, which determines the fundamental nature of how a customer interacts with the system, and it can be found in Filler3, third byte from the left. In one file, the Account ID column sometimes actually does contain the Account number but not alway, sometimes its something else and its torched us. And you’ll never guess what that ZipLoc3 column_really_ contains (hint: nothing like a zipcode).

Yet this system is responsible for several billion in revenue. If the mainframe goes off line a few pagers chirp, but if that system goes off line, it’s klaxons and battle stations.

Universal agreement, its got to go. It has been end-of-life scheduled more often then a serial killer on death row. IT leadership comes and goes, yet, a full decade later it sits there in the data center laughing at me like an evil essence hosting Steven King basement furnace.

Within the last year of so, it’s reached such a state of chaotic entropy, its decay is not only apparent to IT, but now the business, and worse the customer as well.

What Can Be Done?

No one wants to keep it on life support, so doubling down the head count to reverse entropy, or putting some sort of SOA lipstick on this pig is something we’d like to avoid. The problems are fundamental and systemic.

Being customer facing, it’s where all of the businesses most “brilliant” ideas tend to accumulate through the years. Lets just say they’ve been very creative. Nuff said.

We threw a check at it and a consulting team tried for 18 months to move onto an ERP solution and barely made a dent, though I do believe the team purchased their own private Caribbean Island from the billing fees. It just won’t map to a COTS or ERP package without a struggle and anything less the monetary cost of a government TARP program.

On and off over the years, my boss, out of left field, using the pluralis maiestatis would say “we should rewrite it all from scratch.” Having been broken like John McCain on a few Death Marches I’d look at him repeating “the horror… the horror.”

Then during one of my annual hypomanic phases I’d wake up and just know that if put back together ol’ jelled team from that project back in ‘01, well we could rewrite that sucker in no time. That COCOMO II model, most assuredly did not apply to us. My boss, with a look of concern, would nod sagely and suggest I think about it a bit more. I’d recover my senses in a day or two.

And so it sits in the data center, spewing heat and laughing. And it is evil.

All This Sturm und Drang

As a company we know how to do it by the book as we are several years into an ERP implementation. We have standards documents on how we develop standards, requirements/design/functional templates, change control, copious meetings, PMs, PMO office, analysts, and even a few software developers to actually implement things.

We make RUP look like monkeys with a football, Dilbert but a pale shadow irony of our realism, and Forrestor articles look like descriptions of primitive tribal organization. We have PROCESS.

In addition, we have been a full blown java company for in-house application for years. We got it in spades, Struts, Spring, Hibernate, J2EE, ADF, TOPLINK, Ant, Maven, Eclipse, Rational, …

We drink Kool-Aid by the 55 gallon drum round here.

Java

A number of years ago with the support of a key IT executive, I led a jelled, vertical team which brought Java into the company hard and fast. It was seismic.

There was no end of debate, questions, consternation and gnashing of teeth throughout IT and beyond, which we totally ignored. We didn’t know we were supposed to form a technology introduction committee to shepherd this through the IT Leadership Committee approval process. We damn sure didn’t seek forgiveness after the fact, much less permission before the act.

A wild ride, in a more wild time, this was pre-PROCESS. Small team, modest budget, mega-hours, fun times and a result that the business loved. It gave us the #1 ranking in our industry and we held it for a number of years.

I’m reasonably proficient in and knowledgeable of the Java Universe.

Lets, just say it, Java, by design, is a pretty simplistic language, I would argue even a crippled language for uses other then its original design point, which was certainly not server side enterprise IT. As a result, the cottage industries around Java are practically their own Industrial Sectors.

Java is the Brier Rabbit of IT. Once touched you can’t let go. Its simplistic enough to be inadequate in almost every situation. The commercial world just loves this aspect of Java as they exploit revenue streams from filling these gaps via endless Frameworks, Patterns, APIs, Annotations, IDEs and Toolsets.

The dirty secret of course is 25 – 50% of all of it is pure overhead, without direct value, but necessary to overcome the inherent limitations of Java.

On the other hand, the upside of Java for enterprise IT is pretty obvious. Any problem you might have can be solved with money and armies of plug and play bodies and you get mountains of buzz material for those presentations.

But honestly, is this anyway to deliver the IT solutions your company needs?

Full Circle

Where were we …. Yes, you see, I have a small problem.

So whats the issue, you say? I write a whole blog about nothing, you say? We all know the right answer, you’re pointing out? Yea, I know, its intuitively obvious to the casual observer.

We’ll rewrite it from scratch.

Course we’ll need a cluster of WebSphere Application Servers, and an Oracle RAC cluster for all that data. Don’t forget the middleware needed to transition over from the legacy systems, so toss in an ESB cluster, and what heck a couple of BPEL servers too.

Need a SOA Center of Excellence of course too. Can’t integrate without some common XML Business Object Schemas. Also need to roll the Rational RUP suite and some beefy IDE environments and for that shiny look, sprinkle the works with lots of WS-* sparkly dust. Bake 3-5 years or until done, whenever.

My presentation slides for all this will be killer. I can sell this stuff. I’m good at it. I’ll look like a bloody genius. I’ll have Vendors fawning all over me. And the best part is the bubble on this mess won’t pop for YEARS, when I’ll have plenty of plausible deniability. “Hey the plan was perfect, the business, IT managers and their people were incapable of executing it.”

I feel like the enterprise IT equivalent of an AIG trader pocketing ill gotten gains from writing Credit Default Swaps that we can’t pay off.

Losing My Religion

I’ve lost my faith in it all. I need a new religion.

I don’t want monolithic 10 ton solutions I need to wrestle into place with a small armies. I don’t want clusters of application servers fronting a behemoth RAC data cluster. I don’t want web management consoles which rival the Space Shuttle’s dash board.

I want a simple yet effective structural system where I can select and compose reusable modular solutions into simple, targeted solutions. The solution size should be isomorphic to the problem size. It leverages what it needs to solve the problem and no more.

I don’t want 100K source lines of code, with 33K lines of fluff and stuff. Where one of every in three lines of code has nothing to do with the business logic. Where you can’t even find the business logic in the mounds of patterns, abstractions, frameworks, annotation, cut points and verbosity.

I want the problem domain reflected in the code and the code to capture the essence of the problem domain.

I don’t want massive XML documents constrained by committee designed XSD Schema BODs shuttling around clusters of ESB and BPEL middleware.

I want dirt simple intra system communication in the data center.

The Book Of JOSH

Through a marvelous, even devious, set of circumstances, I’m presented with the opportunity to address my little problem without proscribed constraints, a true green field opportunity.

Json OSGi Scala HTTP

Json delivers on what XML promised. Simple to understand, effective data markup accessible and usable by human and computer alike. Serialization/Deserialization is on par with or faster then XML, Thrift and Protocol Buffers. Sure I’m losing XSD Schema type checking, SOAP and WS-* standardization. I’m taking that trade.

OSGi a standardized dynamic, modular framework for versioned components and services. Pick a logger component, a HTTP server component, a ??? component, add your own internal components and you have a dedicated application solution. Micro deployment with true replacement. What am I giving up? The monolithic J2EE application servlet loaded with 25 frameworks, SCA and XML configuration hell. Taking the trade.

HTTP is simple, effective, fast enough, and widely supported. I’m tired of needlessly complex and endless proprietary protocols to move simple data from A to B with all the accompanying firewall port insanity. Yes, HTTP is not perfect. But I’m taking this trade where I can as well.

All interfaces will be simple REST inspired APIs based on HTTP+JSON. This is an immediate consequence of the JOSH stack.

Scala is by far the toughest, yet the easiest selection in the JOSH stack. I wrestled far more with the JSON or XML or Thrift or Protocol Buffers decision.

Without hesitation I know Scala is the right choice from a pure solutioning aspect. But lets face it, what a tough, tough sell from the propeller headed guys to the pointy headed guys.

First, I’m a bit of a computer language aficionado. I’ve written multiple, actual programs in SML, Scheme, Haskell which I’ve used within the enterprise. Why? Because when faced with certain “one time” problems I can knock out a simple utility far faster XXX then in Java. But in almost all cases these were throw away utilities for one time situations.

I’ve toyed with Dylan, Ruby, Python, Groovy, Lisp, Ocaml, Modula 2, Oberon, …

To date I’ve only advocated and pushed Python for utility scripting at both the Application and System Administration levels. Never, at any time did it ever even cross my mind to advocate anything other then Java and a bit of Python for enterprise application development until now.

Java has been stretched way beyond its modest design point. Its literally falling apart from bloat.

Joshua Boch has numerous presentations of the current state of affairs with Java and the proposed functional extensions and closures are headed. He quotes the following from the Java community.

“I am completely and totally humbled. Laid low. I realize now that I am simply not smart at all. I made the mistake of thinking that I could understand generics. I simply cannot. I just can’t. This is really depressing. It is the first time that I’ve ever not been able to understand something related to computers, in any domain, anywhere, period.”

“I’m the lead architect here, have a PhD in physics, and have been working daily in Java for 10 years and know it pretty well. The other guy is a very senior enterprise developer (wrote an email system that sends 600 million emails/year with almost no maintenance). If we can’t get [generics], it’s highly unlikely that the ‘average’ developer will ever in our lifetimes be able to figure this stuff out.”

That’s just generics. And if you seen the proposed syntax for closures, well its readily apparent, Java’s elastic modulus has been exceeded. A crippled language has been fast marched evolved into a broken language.

Plenty of blame for all here. In the last 50 years academia and commercial entities have given us boutique languages, COBOL, C++ and Java.

A Proper Programming Language For Business Development

It’s the age of the Jetson’s, and a decent programming language for enterprise business applications doesn’t exist.

So lets design one.

1. Simple, clean and full featured.
2. Ready of concurrency, distributed applications on mult-core commodity boxes.
3. Allow for the explicit control of state and state mutation.
4. Support for modularity, and scaling in the large.
5. Multiparadigm to support mapping the commonality and variability of the domain problem to the code.
6. Capable of supporting Application Oriented Language / Domain Specific Language development (AOL/DSL).
7. Cross platform, with a large supporting tool suite universe.
8. Open and not subject to Vendor locking.
9. Fast
10. OO
11. Functional
12. Conceptual Integrity.
13. Allow control of, if not out right banishment of the null pointer.
14. Rich libraries.
15. Strongly Typed
16. Practical and Pragmatic
17. Accessible to the average developer, empowering to your A players.
18. Runs on a portable VM.
19. Leverage existing extensive Java libraries.

This is Scala.

So How Is It Going

Fast forward… Currently a very small team and myself are near completion of the first major functional component on the JOSH stack.

All of the development talent on the team are experienced Java developers. And they have been effective from Day 1.

No real discussions of covariance and contravariance was required. We did discuss HOF, anonymous lamba, closures, cut syntax, maps, folds, reduces. And strangely their heads did not explode. We did discuss the evil of mutable state, and referentially transparent functions.

They were enthralled.

No detailed lectures on the deep underlying structure of Catamorphism, Anamorphism, Apomorphism, Hylomorphism and Paramorphism was required to get solid code at a cleaner and higher level, with less bloat then equivalent Java.

A core aspect of system is combinator based threading state through a composed computation. No problems in understanding were observed.

In fact in terms of difficulty, they struggled somewhat more with Git then they did with Scala, Linux then they did with Scala, IDEs issues then they did with Scala, and Maven then they did with Scala.

At a minimum they wrote better Java idomatic code in Scala then they did in Java and proactively adopted more idiomatic Scala as time went by.

Visual Basic now has lambda and no one expects a VB developer to throw himself off a building. Yet somehow, these days too many think Java developers can’t handle more advanced functionality.

I’ve seen too much of “I just did this fold thingy and my co-workers could _never_ understand that” is a bit overblown. OK, if they have never seen it before, they might not get it in 10 mins. But working with the team on the basics for 10 hours or 10 days will certainly do it.

But bottom line, enterprise Java developers can transition to Scala. I know this, because I’ve directly observed it.

JOSH has no Data

The JOSH stack is lacking a letter, because a solution for persisted data is missing in the stack.

A great deal of what needs to be done does not require a ACID RDB cluster. Some of it does and I’m kicking that can down the road.

For the rest, either the data is ReadOnly and loaded a 1-3 times a day or is best persisted by a distributed Key-Value storage system. A number of these are now available as open source solutions and at the right moment I’ll need to pick one and add that letter to the JOSH stack.