Interoperability Happens

Ever thought of being a writer?

2010-08-25T22:21:40.6037081-07:00

CoDe Magazine (for whom I do a back-cover editorial every other month) has been running a different kind of column recently, one which has not only been generating some good buzz, but also offers a unique opportunity for those who are interested in maybe dipping their toes into the technical writing game. This message was posted by Markus Eggers, the publisher of CoDe, on several different mailing lists, and he asked me to spread the word out:

As you may know, each issue of CODE Magazine has a PostMortem column, where the author discusses a .NET related project and points out 5 things that went well, and 5 things that didn’t (we call them “challenges” ;-) ). This column has been pretty popular and provides some great visibility for the author and the companies involved in the project.

We are looking for more authors for upcoming issues. If you are interested, please don’t hesitate to contact me.

For more info on PostMortems, check out this writer’s guide:

http://codemag.com/Write/PostMortem

For an example PostMortem, check out this recent article:

http://www.epsdownloadsite.com/downloads/d1392e8a-ddcc-4507-95e7-5d933574d997/PostMortemExample.pdf

As an added incentive, if you think you have an interesting project that would work well for a PostMortem, but don’t feel like your writing is quite “up to snuff”, feel free to loop me in on the conversation, and at the very least I’ll offer a “pre-editorial review” of the article and offer up some suggestions on how to make it stronger. (But Rod Paddock, CoDe’s editor, is also a pretty good editor, and so you might just submit it to him first to get his take on it.)

In any event, take the shot and see if you’ve got some writing chops in you. :-)

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

Death to Best Practices

2010-08-10T00:08:53.2072432-07:00

Can we please put the whole term “Best Practices” to rest now? Apparently, according to this link (forwarded to me by John Dietz, thanks!), the very place where it originated (or was best popularized, depending on your interpretation of history) has now seen the whole concept basically debunked:

For example, Jim Collins’ blockbuster business book Good to Great, published in 2001, featured 11 supposedly great companies. All of them did extraordinarily well on the stock market for 10-20 years. But by 2008, when Steven Levitt posted Good to Great to Below Average on Freakonomics, two of them had died.
(Read more: http://timberry.bplans.com/2010/07/the-sad-truth-about-best-practices.html#ixzz0wBOxDrkh)

The point is, best practices just don’t exist. They are an attempt to take a solution to a problem out of the context and apply them across the entire spectrum, and that essentially invalidates the entire thing. A solution is only useful when considered in context.

Don’t believe me? Consider this challenge: when is it not a best practice to breathe? When you’re under water, of course.

(Unless you’re a fish. Or a frog. Or maybe a prince turned into a frog.)

Point is… context matters, folks.

Blind application of best practices don’t work, as Tim Berry’s article quotes from Jim Collins’ book (my emphasis):

Nine of the eleven companies remain more or less intact. Of these, Nucor is the only one that has dramatically outperformed the stock market since the book came out. Abbott Labs and Wells Fargo have done okay. Overall, a portfolio of the “good to great” companies looks like it would have underperformed the S&P 500.

Still think that the “best practices” idea might work? Prove it to yourself: do a detailed study of CEO performance across any given CEO’s career and across a variety of different companies who changed CEOs. In short windows, yes, you can find scenarios where a CEO had a stellar performance with a particular company for a particular period of time. But when you pan back and look across the CEO’s entire career (during which he/she practiced the same “best practices” at different firms), almost none of them have repeatable successes at a variety of different firms in any consistent manner (despite the millions handed to them).

In other words, for a good many of them, their success was nothing but blind luck. A monkey could have done just as well. The “superstar CEO” is generally a product of the five or so years in which his one firm was wildly successful. Attempts to repeat the success at other firms (that is, in a different context) typically have failed or generated mediocre results. (Anybody know what Lee Iacocca is up to these days, he of “I will rescue Chrysler” fame? Come to think of it, can anybody name any of the 70’s or 80’s “superstar CEOs” that is still wildly successful today? Just one?)

How did this “best practices” thing get to be such a common meme? Because “best practices” mean, essentially, that the questioner doesn’t want to have to think. And it’s a seductive premise—if I just push the right buttons, type the right keywords, call the right methods and/or use the right classes, I can get something that “just works” without having to think about all those nasty little details that seem to trip people up: performance, scalability, security, blah blah blah.

Here’s the dirty little secret of our industry: Software development is hard.

Computer science is about tradeoffs and hard choices. Optimizing the code or design or architecture one way means taking hits another way. Trading static typing for dynamic typing means losing a set of already-written unit tests in exchange for a degree of flexibility in certain parts of the design. Using inheritance instead of parametric polymorphism offers some benefits but also adds some restrictions, and vice versa. Choosing an agile approach gains you greater feedback and closer connection to your customer (which typically means you’re closer to budget and critical features being completed on time), but requires more work and expertise to pull it off over other, more waterfall-ish, processes. And so on, and so on, and so on.

Tim says this well:

Don’t ever just blindly follow. You always think about it, consider the options, how it might be different in your case, and then, if it still sounds good, try it. Carefully.

If I ever give you any advice, I want you to please never take it without thinking first, analyzing, and deciding for yourself whether or not, and how, and to what extent what I say fits your situation.

(Read more: http://timberry.bplans.com/2010/07/the-sad-truth-about-best-practices.html#ixzz0wBQU3yCB)

But it’s not just the questioners’ fault: speakers, in their zeal to prove that they were smarter than everybody else, bought into the idea, too, because if I’m the one holding the “best practices”, then clearly I’m the one you want to come to with the development or consulting work. After all, who better to hire than the guy/gal with all the answers? In essence, we fed their addiction by tossing off “best practices” in pithy one-line answers (like “every class a service”) that turned out to be utter B/S pronounced by people who had, in some cases, never actually put that practice into practice for anything other than a demo or an example.

It’s time to say “no” to “best practices”.

Speakers: The next time somebody asks you for the “best practices” on a technology, respond with “The best practice you could possibly employ is to hire me.” That, or else with “There are no such thing. You cannot answer a question about a problem outside of its context.”

Attendees: The next time a speaker starts talking about “best practices”, walk out, because clearly the speaker is trying to feed you easy answers when in fact there are only hard choices.

It’s time for our industry to break the habit of taking hits off the ~~crack~~ best practices pipe, and start facing the fact that software development is hard.

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

A well-done "movie trailer"

2010-07-01T03:06:35.2155888-07:00

The JavaZone conference has just become one of my favorite conferences, EVAH. Check out this trailer they put together, entitled "Java 4-Ever". Yes, Microsofties, you should watch, too. Just leave off the evangelism for a moment and enjoy the humor of it. You've had your own fun over the years, too, or need I remind you of the Matrix video with Gates and Ballmer and the blue pill/red pill? ;-)

This video brings several things to mind:

Wow, that's well done. And take heed, the "R" rating at the front of the trailer is actually pretty serious. NSFW.
I remember speaking at JavaZone a half-dozen years ago, and remember it fondly. Which reminds me, I need to get back there before long. I missed NDC this year, and I need my Oslo on before long.
Whatever happened to Microsoft marketing? They used to do things like this on a more regular basis, but it seems they've been silent over the past few years. C'mon back, guys! The water's fine!

Oh, and by the way, pay absolutely no attention to most of the comments that appeared on the trailer page—most of them are ridiculous and stupid. (To the .NET advocate who said that ".NET doesn't use a virtual machine", you're the biggest idiot of the lot.)

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

Architectural Katas

2010-06-17T01:42:47.5300773-07:00

By now, the Twitter messages have spread, and the word is out: at Uberconf this year, I did a session ("Pragmatic Architecture"), which I've done at other venues before, but this time we made it into a 180-minute workshop instead of a 90-minute session, and the workshop included breaking the room up into small (10-ish, which was still a teensy bit too big) groups and giving each one an "architectural kata" to work on.

The architectural kata is a take on PragDave's coding kata, except taken to a higher level: the architectural kata is an exercise in which the group seeks to create an architecture to solve the problem presented. The inspiration for this came from Frederick Brooks' latest book, The Design of Design, in which he points out that the only way to get great designers is to get them to design. The corollary, of course, is that in order to create great architects, we have to get them to architect. But few architects get a chance to architect a system more than a half-dozen times or so over the lifetime of a career, and that's only for those who are fortunate to be given the opportunity to architect in the first place. Of course, the problem here is, you have to be an architect in order to get hired as an architect, but if you're not an architect, then how can you architect in order to become an architect?

Um... hang on, let me make sure I wrote that right.

Anyway, the "rules" around the kata (which makes it more difficult to consume the kata but makes the scenario more realistic, IMHO):

you may ask the instructor questions about the project
you must be prepared to present a rough architectural vision of the project and defend questions about it
you must be prepared to ask questions of other participants' presentations
you may safely make assumptions about technologies you don't know well as long as those assumptions are clearly defined and spelled out
you may not assume you have hiring/firing authority over the development team
any technology is fair game (but you must justify its use)
any other rules, you may ask about

The groups were given 30 minutes in which to formulate some ideas, and then three of them were given a few minutes to present their ideas and defend it against some questions from the crowd.

An example kata is below:

Architectural Kata #5: I'll have the BLT

a national sandwich shop wants to enable "fax in your order" but over the Internet instead

users: millions+

requirements: users will place their order, then be given a time to pick up their sandwich and directions to the shop (which must integrate with Google Maps); if the shop offers a delivery service, dispatch the driver with the sandwich to the user; mobile-device accessibility; offer national daily promotionals/specials; offer local daily promotionals/specials; accept payment online or in person/on delivery

As you can tell, it's vague in some ways, and this is somewhat deliberate—as one group discovered, part of the architect's job is to ask questions of the project champion (me), and they didn't, and felt like they failed pretty miserably. (In their defense, the kata they drew—randomly—was pretty much universally thought to be the hardest of the lot.) But overall, the exercise was well-received, lots of people found it a great opportunity to try being an architect, and even the team that failed felt that it was a valuable exercise.

I'm definitely going to do more of these, and refine the whole thing a little. (Thanks to everyone who participated and gave me great feedback on how to make it better.) If you're interested in having it done as a practice exercise for your development team before the start of a big project, ping me. I think this would be a *great* exercise to do during a user group meeting, too.

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

Emotional commitment colors everything

2010-05-14T03:40:33.3142582-07:00

As a part of my program to learn how to use the Mac OS more effectively (mostly to counteract my lack of Mac-command-line kung fu, but partly to get Neal Ford off my back ;-) ), I set the home page in Firefox to point to the OSX Daily website. This morning, this particular page popped up as the "tip of the day", and a particular thing about it struck my fancy. Go ahead and glance at it before you continue on.

On its own merits, there's nothing particularly interesting about it—it's a tip about how to do a screen-capture in OS X, which is hardly a breakthrough feature. But something about the tenor struck me: "You’ve probably noticed there is no ‘Print Screen’ button on a Mac keyboard, this is to both simplify the keyboard and also because it’s unnecessary. Instead of hitting a “Print Screen” button, you’ll hit one of several keyboard combination shortcuts, depending on the exact screen capture action you want taken. ... Command+Shift+3 takes a screenshot of the full screen ... Command+Shift+4 brings up a selection box .... Command+Shift+4, then spacebar, then click a window takes a screenshot of the window...."

Wait a second. This is simpler?

If "you're a PC", you're probably rolling on the floor with laughter at this moment, determined to go find a Mac fanboi and Lord it over him that it requires the use of no less than three keystrokes to take a friggin' screenshot.

If, on the other hand, you love the Mac, you're probably chuckling at the idiocy of PC manufacturers who continue to keep a key on the keyboard dating back from the terminal days (right next to "Scroll Lock") that rarely, if ever, gets used.

Who's right? Who's the idiot?

You both are.

See, the fact is, your perceptions of a particular element of the different platforms (the menubar at the top of the screen vs. in the main window of the app, the one-button vs. two-button mouse, and so on) colors your response. If you have emotionally committed to the Mac, then anything it does is naturally right and obvious; if you've emotionally committed to Windows, then ditto. This is a natural psychological response—it happens to everybody, to some degree or another. We need, at a subconscious level, to know that our decisions were the right ones to have made, so we look for those facts which confirm the decision, and avoid the facts that question it. (It's this same psychological drive that causes battered wives to defend their battering husbands to the police and intervening friends/family, and for people who've already committed to one political party or the other to see huge gaping holes in logic in the opponents' debate responses, but to gloss over their own candidates'.)

Why bring it up? Because this also is what drives developers to justify the decisions they've made in developing software—when a user or another developer questions a particular decision, the temptation is to defend it to the dying breath, because it was a decision we made. We start looking for justifications to back it, we start aggressively questioning the challenger's competency or right to question the decision, you name it. It's a hard thing, to admit we might have been wrong, and even harder to admit that even though we might have been right, we were for the wrong reasons, or the decision still was the wrong one, or—perhaps hardest of all—the users simply like it the other way, even though this way is vastly more efficient and sane.

Have you admitted you were wrong lately?

(Check out Predictably Irrational, How We Decide, and Why We Make Mistakes for more details on the psychology of decision-making.)

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

Code Kata: RoboStack

2010-05-10T00:01:36.9808932-07:00

Code Katas are small, relatively simple exercises designed to give you a problem to try and solve. I like to use them as a way to get my feet wet and help write something more interesting than "Hello World" but less complicated than "The Internet's Next Killer App".

This one is from the UVa online programming contest judge system, which I discovered after picking up the book Programming Challenges, which is highly recommended as a source of code katas, by the way. Much of the advice parts of the book can be skimmed or ignored by the long-time professional developer, but it's still worth a read, since it can be an interesting source of ideas and approaches when solving real-world scenarios.

Problem: You work for a manufacturing company, and they have just received their newest piece of super-modern hardware, a highly efficient assembly-line mechanized pneumatic item manipulator, also known in some circles as a "robotic arm". It is driven by a series of commands, and your job is to write the software to drive the arm. The initial test will be to have the arm move a series of blocks around.

Context: The test begins with n number of blocks, laid out sequentially next to each other, each block with a number on it. (You may safely assume that n never exceeds 25.) So, if n is 4, then the blocks are laid out (starting from 0) as:

0: 0

1: 1

2: 2

3: 3

The display output here is the block-numbered "slot", then a colon, then the block(s) that are stacked in that slot, lowest to highest in left to right order. Thus, in the following display:

0:

1:

2: 0 1 2 3

3:

The 3 block is stacked on top of the 2 block is stacked on top of the 1 block is stacked on top of the 0 block, all in slot 2. This can be shortened to the representation [0:, 1:, 2: 0 1 2 3, 3:] for conciseness.

The arm understands a number of different commands, as well as an optic sensor. (Yeah, the guys who created the arm were good enough to write code that knows how to read the number off a block, but not to actually drive the arm. Go figure.) The commands are as follows, where a and b are valid block numbers (meaning they are between 0 and n-1):

"move a onto b" This command orders the arm to find block a, and return any blocks stacked on top of it to their original position. Do the same for block b, then stack block a on top of b.
"move a over b" This command orders the arm to find block a, and return any blocks stacked on top of it to their original position. Then stack block a on top of the stack of blocks containing b.
"pile a onto b" This command orders the arm to find the stack of blocks containing block b, and return any blocks stacked on top of it to their original position. Then the arm must find the stack of blocks containing block a, and take the stack of blocks starting from a on upwards (in other words, don't do anything with any blocks on top of a) and put that stack on top of block b.
"pile a over b" This command orders the arm to find the stack of blocks containing block a and take the stack of blocks starting from a on upwards (in other words, don't do anything with any blocks on top of a) and put that stack on top of the stack of blocks containing block b (in other words, don't do anything with the stack of blocks containing b, either).
"quit" This command tells the arm to shut down (and thus terminates the simulation).

Note that if the input command sequence accidentally offers a command where a and b are the same value, that command is illegal and should be ignored.

As an example, then, if we have 4 blocks in the state [0: 0, 1: 1, 2: 2, 3: 3], and run a "move 2 onto 3", we get [0: 0, 1: 1, 2:, 3: 3 2]. If we then run a "pile 3 over 1", we should end up with [0: 0, 1: 1 3 2, 2:, 3:]. And so on.

Input: n = 10. Run these commands:

move 9 onto 1
move 8 over 1
move 7 over 1
move 6 over 1
pile 8 over 6
pile 8 over 5
move 2 over 1
move 4 over 9
quit

The result should be [0: 0, 1: 1 9 2 4, 2:, 3: 3, 4:, 5: 5 8 7 6, 6:, 7:, 8:, 9:]

Challenges:

Implement the Towers of Hanoi (or as close to it as you can get) using this system.
Add an optimizer to the arm, in essence reading in the entire program (up to "quit"), finding shorter paths and/or different commands to achieve the same result.
Add a visual component to the simulation, displaying the arm as it moves over each block and moves blocks around.
Add another robotic arm, and allow commands to be given simultaneously. This will require some thought—does each arm execute a complete command before allowing the other arm to execute (which reduces the performance having two arms might offer), or can each arm act entirely independently? The two (or more) arms will probably need separate command streams, but you might try running them with one command stream just for grins. Note that deciding how to synchronized the arms so they don't conflict with one another will probably require adding some kind of synchronization instructions into the stream as well.

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

Code Kata: Compressing Lists

2010-05-06T14:42:09.4053432-07:00

Rick Minerich mentioned this one on his blog already, but here is the original "problem"/challenge as it was presented to me and which I in turn shot to him over a Twitter DM:

I have a list, say something like [4, 4, 4, 4, 2, 2, 2, 3, 3, 2, 2, 2, 2, 1, 1, 1, 5, 5], which consists of varying repetitions of integers. (We can assume that it's always numbers, and the use of the term "list" here is generic—it could be a list, array, or some other collection class, your choice.) The goal is to take this list of numbers, and "compress" it down into a (theoretically smaller) list of numbers in pairs, where the first of the pair is the occurrence number of the value, which is the second number. So, since the list above has four 4's, followed by three 2's, two 3's, four 2's, three 1's and two 5's, it should compress into [4, 4, 3, 2, 2, 3, 3, 1, 2, 5].

Update: Typo! It should compress into [4, 4, 3, 2, 2, 3, 4, 2, 3, 1, 2, 5], not [4, 4, 3, 2, 2, 3, 3, 1, 2, 5]. Sorry!

Using your functional language of choice, implement a solution. (No looking at Rick's solution first, by the way—that's cheating!) Feel free to post proposed solutions here as comments, by the way.

This is a pretty easy challenge, but I wanted to try and solve it in a functional mindset, which the challenger had never seen before. I also thought it made for an interesting challenge for people who've never programming in functional languages before, because it requires a very different approach than the imperative solution.

Extensions to the kata (a.k.a. "extra credit"):

How does the implementation change (if any) to generalize it to a list of any particular type? (Assume the list is of homogenous type—always strings, always ints, always whatever.)
How does the implementation change (if any) to generalize it to a list of any type? (In other words, a list of strings, ints, Dates, whatever, mixed together within the list: [1, 1, "one", "one", "one", ...] .)
How does the implementation change (if any) to generate a list of two-item tuples (the first being the occurence, the second being the value) as the result instead? Are there significant advantages to this?
How does the implementation change (if any) to parallelize/multi-thread it? For your particular language how many elements have to be in the list before doing so yields a significant payoff?

By the way, some of the extension questions make the Kata somewhat interesting even for the imperative/O-O developer; have at, and let me know what you think.

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

Comments on the SDTimes article

2010-03-26T17:03:14.8635146-07:00

Miguel de Icaza wrote up a good response to the SDTimes article in which both of us were quoted, and I thought it might serve to flesh out the discussion a bit more to chime in with my part in the piece.

First and foremost, Miguel notes:

David quotes Ted Neward (a speaker on the .NET and Java circuits, but not an open source guy by any stretch of the imagination).

Amen to that—I have never tried to promote myself as an open source guy, and certainly not somebody that can go toe-to-toe on open-source issues like Miguel can. David contacted me specifically to comment on some of Miguel's points, and that's what I tried to do.

Ted tried to refute my point about Java and innovation but seemed to have missed the point.

Again, I don't think I can argue with that. Your point becomes more clear in your blog entry, Miguel, and as you'll see in a second, I disagree with only part of the point, and perhaps it's a semantic discussion that isn't one you (or anybody else) wants to have, but seems important to note, at least in my mind. :-)

The article attributed this to Ted: "Microsoft has made an open-source CLI implementation codenamed 'Rotor' freely available, but it has had little or no uptake".

There is a very simple reason for that. Rotor was not open source and it was doomed to failure the moment it came out. When Microsoft released Rotor in 2002 or 2003 they had no idea what they were doing and basically botched the whole effort by using a proprietary license for Rotor.

And there we have it: "Rotor was not open source". This is the entire point on which the disagreement (or lack thereof) hinges.

Some time ago, on a panel, I mentioned that there are three kinds of common usage when people use the term "open source". (I'm not arguing the 'proper' definition here—I'm arguing the common lay usage, which may or may not actually be correct according to those who define such things.) Those three definitions are:

Free. ("I didn't have to pay for it!")
Source-available. ("I can build it!")
Accepting community contributions, and as a result, forkable. ("I can submit patches!" or "I don't like the direction you're taking it, so I'm taking the source and forking it and going in a different direction!")

Rotor fit the definitions of the first 2, though #1 usually implies an ability to use it in a production environment, something the Shared Source license (the license applying to Rotor at the time of its release) didn't permit in any way shape or form.

And Miguel's exactly right—according to the #3 definition of the above, or the linked definition he cites, Rotor does not fit that. Period.

Alas, it is to the detriment of our industry that people don't use terms according to their actual definitions, but a looser, less precise, usage model. Not being an "open-source guy", I fall into the trap of using the looser definition, and that's what I was using when I read Miguel's point and made my counterpoint.

As to the rest of Miguel's point, that Microsoft "botched" the release of Rotor, I'm not sure that's the case—what I think was happening was a difference of intent versus interpretation of that intent. I don't want to put words in Miguel's mouth, so forgive me if I'm (again) not reading it right, but contrary to what Miguel seems to believe, Microsoft never really intended Rotor as an "open source" implementation in the sense that Mono was.

Instead, Microsoft intended Rotor to be an implementation that universities and research groups could use to hack on the CLR or build languages for the CLR, in an effort to promote .NET and its usage among researchers and universities. Based on the discussions I had with David Stutz during the Shared Source CLI Essentials writing, Microsoft never really thought that Rotor would be all that interesting as an open-source "platform", per se—hence the reason that the GC and JIT that appear in Rotor are "simplified" and "not all that interesting" (David's words, as best I can remember them). At the time, they felt that these (GC and JIT) would be areas that students and companies would want to research around those areas, so a production-ready implementation of either was really not necessary.

In other words, Microsoft saw Rotor as JikesRVM, not as Mono. And definitely not as OpenJDK.

Which gets us right back to Miguel's point, a spot-on analysis:

Had Microsoft been an open company in 2001 and had embraced diversity we would live in a different world. The awesome Mono team would probably be bigger, and the existing team members would have longer vacations.

The Microsoft of 2001 was categorically and absolutely afraid of the open-source community. In fact, I seem to recall David listing a litany of things he'd had to do to get Rotor pushed out the door, even with the license it had. Had David not been as high up in the organization as he was, we probably wouldn't have seen Rotor. And, I believe, we wouldn't see Microsoft being where they are now...

But for everyone that missed the point, luckily, Microsoft has new management, new employees that know open source, fresh new ideas, is becoming more open and is working actively on interoperability with third parties. They even launched the CodePlex Foundation.

... without it, because Rotor made it clear to the powers-that-be that even if they turn loose the "keys to the kingdom" (as the CLR was thought to be, in some quarters) out to the world, Microsoft doesn't go bankrupt. A steady yet slowly-emerging "new Microsoft" is coming, one which is figuring out how to interact with open source in ways that the "old Microsoft" could never consider. (Remember, this is not IBM, a company that makes more money on services than on software sales—this is a firm that makes its money principally from commercial software sales. Anybody who thinks they've got that part of the open source market figured out should probably run out and start a company, because that's a hell of a trick.)

And lest it seem like I'm harshing a bit too much on Microsoft, let's take one of Miguel's points and turn it over for a second:

But my point about the ecosystem goes beyond the JVM, it is about the Java ecosystem in general vs the .NET ecosystem. Java was able to capitalize on having implementations on Linux and Unix, which accounts for more than half the web today. The Apache Foundation is a big hub for Java-based development and it grew organically.

All of which was good for Java.... but not necessarily for Sun, who as most of you know, just recently got acquired by one of their former competitors. We can moan and groan and complain about the slow pace Microsoft has been taking to come to open source, particularly when compared to Sun's approach, but in the end, one of these companies is still in business and listed on the NYSE, and the other isn't.

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

Swinging through Florida

2010-03-26T16:28:11.6113505-07:00

Apparently April will be a pretty Florida-heavy month for me; on top of the No Fluff Just Stuff conference in Tampa on April 16th/17th/18th, I'm going to hit three Floridian user groups shortly therafter:

West Palm user group on Tuesday 4/27/2010
Tampa Architecture Group on Wednesday 4/28/2010
Pensacola SQL Server User Group on Thursday 4/29/2010

... before I head up to Reston, VA for the NFJS show there. Should be a fun time, seeing how the other corner of the US lives.....

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

Another Gartner prediction...

2010-03-24T00:15:23.2958864-07:00

Let's see if this one holds: Gartner says that by 2012, Android will have a larger percentage of the worldwide mobile phone market than the iPhone, 14.5 % against 13.7%.

Reasons to doubt this particular bit of prescience? Gartner also predicts that "Windows Mobile" will have "12.8 percent" of the market. This despite the fact that at MIX last week, Microsoft basically canned Windows Mobile in favor of a complete reboot called "Windows Phone Series 7" based on ideas from Silverlight and XNA.

Huh.

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

Amanda takes umbrage....

2010-03-23T23:38:17.9820035-07:00

... with my earlier speaking about F# post, which I will admit, surprises me, since I would've thought somebody interested in promoting F# would've been more supportive of the idea of putting some ideas out to help other speakers get F# more easily adopted by the community. Perhaps I misunderstood her objections, but I thought a response was required in any event.

Amanda opens with:

Let's start with the "Do" category.

OK, then, let's. :-)

First you say you want the speaker to show inheritance... in a functional-first language. This is an obvious no-no. Inheritance should be used extremely lightly in any language and it should be hidden completely in F#. You should NEVER have a student/instructor/employee inherit from a person. This language isn't used that way.

That's odd.... that's entirely contradictory to what I've heard from the F# team. I've never heard anyone on the F# team ever call it a "functional-first" language, nor that inheritance (or any other object-oriented feature) is something that should be used "extremely lightly" or "hidden completely". Quite the contrary, in fact; when I did a tag-team presentation on F# with Luke Hoban, the PM of the F# team, he gently corrected my use of the phrase describing F# as a "functional-object hybrid" language to suggest instead that it was a "fusion" of both features.

But even if that's not the case (or perhaps isn't the case anymore), I think it's critical to give audience members something concrete and familiar to hang onto as they start the roller-coaster ride of learning not only a new syntax, but new concepts. To simply say, "Everything you know from objects is wrong" is to do them a disservice, particularly when the language clearly is intended to expose object-oriented concepts as a first-class citizen.

Second you say to show interop. This will show nothing about the language. You might as well just say it is a .net language. If you spend your F# session discussing what it means to be on .net, you fail. Nobody expects that one dll will not be able to call another. If they do, I assure you that they will not be writing F# anytime soon.

Ah, but here is where my decades of experience teaching languages to audiences all over the world kicks in: they don't know that. DLLs are not all created equal, as anyone who's ever tried to get COM components to interop with native C++ DLLs that in turn want to call into managed code DLLs will tell you. It's important to stress, again, that what they know is still relevant in this new world. In fact, the goal of showing them interoperability is to reassure them that, in fact, it's not a new world at all, but simply a different spin on the world they already know and love.

Next you say give concrete examples of where F# is a win. This is a sales pitch. It's fine for some audiences but if you intend to teach F# to the audience, you likely are already there. Just make sure your examples are real world and you should be fine. I challenge you to make your next blog a "Why F#" which contains real world examples. I've not ever heard you give valuable advice about when to use F#. Also please post what your real world experience is with F#. Where did you implement a solution? What was that project like? Why was F# the best choice?

Interesting. Based on the conversations I've had with others, the main reason people come to technical talks, at least the talks I've been to (both as an audience member and as a speaker) is to know when and where and how they can use this technology (whatever it is) to solve the problems they face. That means that they need to see and hear where a technology fits well as a solution against a given problem domain or case, and the sooner they get that information, the sooner they can start to evaluate where, how and when they should use a particular technology. This has been true of almost every "new" technology I've evaluated—from the more recent presentations and articles around WCF, Workflow, MongoDB and Axum to the older talks/trainings I've given for C#, Java (including servlets, JSPs, EJBs, JMS, and so on), C++ and patterns. Case in point: does F# offer up a great experience in building UIs? Not really—Visual Studio 2010 doesn't have any of the templates or designer support that C# and Visual Basic will have, making it awkward at best to build a UI around it. On top of that, the data-binding architecture present in both WinForms and WPF rely on the idea of mutable objects, which while something F# allows, isn't something it encourages. So, it seems pretty reasonable to assume that F# is not great for UI scenarios.

Oh, and your memory is letting you down here—your comment "I've not ever heard you give valuable advice about when to use F#" is patently false. You were standing next to me at DevTeach 2008, talking about F# to an audience of about 20 or so when I said that I thought that functional-object languages were a natural fit for building services (XML or otherwise).

More importantly, these were tips to speakers interested in F#—where they think F# is strong and they think F# is weak is a personal judgment, not something that I should dictate. You used F# to implement an insurance-scoring engine, as I recall. I've used it (in conjunction with AbsIL, which used to ship with the F# bits back when they were a MSR technology) to do some IL weaving in the spirit of AOP. I've used it in a couple of other cases, but alas I cannot divulge the details due to NDA. But where I've used it and where you've used it isn't the point—it's what the speaker talking about F# has done that's important. This isn't about us—it's about the guy or gal on the stage who's giving the talk.

Then you say to inform the audience that the language is Turing complete. This seems like a huge waste as well. If the audience needs to understand that you can accomplish the same things in C#/VB/F#/Iron*/etc, you are speaking to people who are very young in the understanding of programming. They won't be using F# anytime soon.

Hmm. I think this is a reaction to the comment "DO stress that F# can do everything that C# or Visual Basic can do", which is a very different creature than simply informing the audience that the language is Turing complete. Again, based on my decade's-plus years of training experience, it's important to let the audience know that they don't have to throw away everything they already know in order to use this language. I know that it's fashionable among the functional programming community to suggest that we should just "toss away all that object stuff", but frankly I've not found that to be the attitude among the "heavyweights" in that part of the industry, nor do I find that attitude laced throughout F#. If that were the case, why would F# go to such great lengths to incorporate object-orientation as a full part of its linguistic capabilities? It would be far simpler to be a CLI Consumer (much as managed JScript is/was) and only offer up functional mechanisms, a la Yeti in the Java space.

I lived through the procedural-to-object transition back in the late 80's/early 90's, and realized that if you want to bring the previous generation of programmers along with you into a brave new world, you have to show them that a complete reboot of their mental processes is not necessary. Otherwise, you're basically calling them idiots if they can't keep up. Perhaps you're OK with that; I'm not.

Finally you say to Tease them for 20 minutes. I am not sure what this means. Can you post those 35 lines to wow us? I'd love to see your real world demo that is 35 lines. I'm curious as to why you wouldn't be able to explain the 35 lines as well. I guess there isn't time because you're busy showing interop examples that prove F# is a Turing complete, .net language.

Alas, I doubt my 35 lines would impress you. However, my 35 lines of F# service code, or Aaron's 35 lines of F# natural-language parser code might impress the crowd we're speaking to. I dunno. More importantly, again, this isn't about what *I* want to do in a talk, it's about helping other F# speakers be able to better reach their audience.

Let's get into the Don't category:

So soon? But we were just getting comfortable with all the DO's being judged completely out of order from their corresponding DON'Ts. *shrug* Ah, well.

First you say to stay away from mathematical examples because people don't write mathematical code every day. I think you already mentioned that F# is not meant to be the language you use for every scenario. Now it seems you want to say it should be the everyday tool. I'm confused. I agree that some of these simple examples aren't very useful but then again it's not because they are mathematical. It's because they are simple and ridiculous. I don't use a web crawler everyday either but I see value in the demo. I think the examples need to be more real world, period. Have you posted that blog I requested yet? :)

Ah, the black/white pedagogical argument: if it's not black, it must be white, and if it's not white, it must be black. Your confusion is clear: if it is not a language to be used for everything, it must be a niche language solely for creating high-end mathematical systems, and if it isn't just for creating high-end mathematical systems, it must be a language used for everything.

My reasoning for avoiding the exponent-hugging example is pretty easy, I think: Mathematical examples reinforce the idea that F# is solely to be used for high-end mathematical scenarios. If you're OK with the language only appealing to that crowd, please, by all means, continue to use those examples. Myself, I think functional concepts are powerful, and I try to show people the power of extracting behavior by showing them widely-disparate uses of foldLeft across lists of things to produce concrete yet widely different results. Simple examples, but without a shred of "derivatives" found anywhere.

Alas, that blog post will have to wait—I have an F# book I'm finishing up, and I'd rather put the energy there.

Next up you say to not stress FSI or the REPL. I'll start by reminding you that FSI is the REPL. There aren't two different things here. I think it's great to show a REPL! This is not just a cool F# thing. It's common to most functional languages, statically typed or not. The statically typed argument might be a better one to have than Turing completeness. I'd much rather discuss those benefits for the types of code that are written in F#.

Wow. I wouldn't have thought I would have to remind you that REPL is a generic phrase that can apply to both FSI and the Interactive Window inside Visual Studio. And while I'm certainly happy to hear that you think it's great to show a REPL, the fact remains that most .NET developers don't know what to do with it. More importantly, demonstrating a REPL reinforces the idea that this is a shell-scripting language like Python and Ruby and PowerShell, hence the questions comparing F# to Python or Perl that come up every time I've seen an F# talk show off FSI or the Interactive Window. Business developers using .NET build using Visual Studio (with the exception of that small percentage who've discovered IPy or IRb) and, again, need to be brought gently into this new approach.

(For those readers still following along, the REPL concept is hardly restricted to the functional language cadre; in fact, object-oriented developers would be well-advised to play with one of their own ancient progenitors, Smalltalk, and its environment that is essentially one giant REPL baked into a GUI image that can be frozen and re-hydrated at any time. Long-time readers of this blog will know I've talked about this before, and how incredibly powerful it would be if we could do similar kinds of things to the JVM or CLR.)

You go back into the Why F# question without giving any real reason. Can you post that blog please? I think many of your readers would appreciate that! PS: The Steelers are fantastic! :)

If I'm following your point-by-point refutation correctly, you're now saying I'm "going back" to the "Why F#" question for no real reason; I would've thought the progression of DON'T followed by DO would've been pretty obvious, but perhaps I was assuming too much on the part of at least one of the post's readership. The DO was designed to offer up prescriptive advice about how to accomplish something I'd said to DON'T previously. And thus is true here: DON'T answer the "Why F#" question with "Productivity", DO answer it with something more concrete and tangible than that, either in the form of real-world examples or concrete scenarios.

I think by this point, given all the wheedling for that blog post, the general readership would probably be very interested in your own rationale blog post, by the way.

Alas, your Steelers barely made it to .500 last year, their franchise quarterback is now the target of his second (and possibly more, if the rumors are to be believed) sexual assault charge, and their principal receiver has a reputation around the league as being a dirty player. So perhaps we will simply have to disagree on how fantastic they are. Which, you will note, proves my point—as the old saying goes, "there is no accounting for taste", because I can't understand how you think. Which then means "It's just how I think" is pretty ridiculous as a justification for using a language.

You say to stay away from the "functional jazz" or the reason why anyone should be looking at F# to start with. People don't come to these types of talks to see how F# is just like C#. They want to see what is different. Don't stress the jargon but if someone asks, let them know there is a name for what they are looking at. I remember when I was learning F# that everyone hid the meaning of let!. They would say "Something special happens here" and that would leave me thinking they were trying to hide the magic. There is no magic! I don't assume people are morons. They can handle the truth. If they want to learn more I want to give them a term to google and some potential resources. There isn't time to cover that completely in most sessions though. It's something to be careful of, not to avoid completely.

Interesting how your anecdotal evidence differs from mine—what I've seen, based on the quick poll I took of the attendees at the user group meeting last night, and based on conversations I've had with hundreds of developers from companies all over the world over the last four years, vastly more attendees come to a talk on a given subject because they have no clue what this thing is and want to see a general overview of it. Shy Cohen, one of the attendees last night, whom I first met during my days as a digerati on the WCF team back when it was still called "Indigo", admitted as much during a whispered conversation at the back of the room. If Shy, old Microsoft hand that he is/was, bright guy that he is, and close friend to Lisa Feigenbaum, who's a Program Manager for Visual Studio, has no clue what F# is and comes to a talk on it so he can get a quick overview of it, how likely is it that everybody is coming to an F# talk with a predetermined idea of what the language is and are thus ready to be given "the truth" complete with all the big dime-store words?

Yes, people want to know what is different, but to do that, they also have to see what is the same. Which takes us back to my earlier points about showing them what is the same between F# and C#.

As for people waving their hands and saying "something special happens here", well, maybe you just listened to the wrong people. *shrug* Can't help you there. For as long as I've been giving talks on F#, dating back to SDWest back in 2005 when I gave a talk on "A Tour of Microsoft Research" during which I talked about Fugue, Detours, AbsIL and F#, I've shown the language, talked about what's happening in there, and shown the IL bindings underneath to give people concrete ideas to hold on to. It's the truth, but without the pretentiousness of big words.

The last point is obvious. Nobody can learn F# in 20 (or 30 as it was) minutes.

Unfortunately, that doesn't stop people from trying to teach the entirety of the language in 20 minutes. Or even in a full day. (From having taught languages for many years, and knowing that it took most of a week to teach C# back in the 1.0/2.0 timeframe, I'm finding that it takes about 5 days of full 8-to-5 training to get them competent and confident in using the language. Less than that, by about a day or so, if they have a strong background in C#.)

Context, context, context.

Indeed. But for now, Amanda, if you take such strong issue with my suggested guidelines for F# speakers, I encourage you to create your own guidelines and post them to your blog. Let's rise the tide to raise all the ships, and encourage a broad spectrum of talk styles.

In the meantime, though, I have a lunch with Michael later this week, some OTN and developerWorks articles to write, an F# book to finish, a Scala book to start, some client code to wrap up, a slew of Scala recordings to work through, soccer practice Thursday night, and a Seattle Tech Speakers Workshop meeting next month to prep for, in addition to a class next week that requires some final polish, so you'll have to excuse me if I don't respond further down this particular path.

Cheers!

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.