If the intent is to push people even farther away from Java,they're on the right track.
The very first comment there is spot on; Java needs type inferencing. With typeinferencing, we could have gotten some of the benefits that generics were supposedto bring, without the horrifying syntax. # of Google hits for 'java' 'generics' 'horror': 541,000.
I'm not sure what to say about closures, none of the suggestions look very good to me.I'm still trying to recover from having to work on projects where people are starting touse generics. Luckily, because annotations comes along for the ride when with generics(in JSE 5), and Eclipse has handy dandy 'quick fixes' for adding a @SuppressWarnings when I want to write tidy code (ie, remove the generic crud),life is somewhat liveable.
From Peter Fisk'sAlmost Smalltalk:
Smalltalk running in Flash is not that far away.
I got goose pimples.
Check out Peter's site, he's got some pretty cool demos up there. On my DE-mentor's advice, I KVM'd over to my sad, bored, win32 desktop, installed the latest .net and ie, so I could run his.net version. Gorgeous. Check out some of Peter's other recent posts for other demos.
But, I'm not sure I'm ready to go back to Smalltalk. Sorry, John. Or Lisp. I've grown attached to using [ ]'sfor array access. etc. Although I will admit that I just wrote in a note to someone theothe day that I liked Ruby because "it's Smalltalk in text files". The thing I really missthough, is the Smalltalk browser. An unadorned IDE, that I can fiddle with in the IDE itself.
And somehow, this also ties into RESTy resourcey goodness. Somehow.
BTW, the image to the right is in my new style of 'flickr pictur with an attribution'. Got the idea to 'inline' the title, owner, license fromMark Pilgrim, and converted my old Ruby commandline program to build the HTML,getf4b,to a Greasemonkey script,getfwa.
One of the things we discovered in Jazz was that when youstart thinking of defining your product's remoteable APIs asservices, that you find yourself in a position where youwant your server to also be a client to these services.But you obviously don't want to be making a remote HTTP call out,from your server, back to yourself. That's not verylight.
I will tell you that infinite recursive callsin a remote-to-yourself scenario are quite exciting!
Fixing the remote-to-yourself problem is simple when youknow that other service you are calling is available somewherein your current address space. Because you can just 'call'it. There are issues; like thefact that remote calls are always copying the 'parameters', but in many programming languages, passing arguments willoccur by reference. Something to watch out for, whendesigning your services around existing programming paradigmslike function/method invocations, and objects.
Now let's make the story a little more interesting. Sayyou want to call some service, which isn't in your addressspace, but is on your local machine somewhere. Do you justgo ahead and pay the cost of issuing HTTP requests, likea real client, and let your existing server infrastructurehandle it like a remote call? For such local calls, tcp/ip overhead (to localhost) is likely to be neglible,since often this won't hit your ethernet interface at all.tcp/ip stacks aren't that stupid. But there's stillthe HTTP overhead, and that can be significant.
I'm reminded of the old Network Vehicleproject I worked on eons ago. We had this same problem. A Smalltalk programcontrolling all the devices. And a Java program running the user interface.Same box. Needed to chat. This was 1997, and while using HTTP wouldn'thave been out of the question, it was clearly overkill. So, we developed ourown 'protocol' over tcp/ip. Java could send us messages like:
and Smalltalk would receive the message and dial the phone. Smalltalk mightsend a message to Java, in reference to a voice recognition event:
Really, it was that easy. Of course, we had a finite set of messages tosend, so coming up with a simple protocol was quite feasible.
But it makes me wonder if what sort of economies might be available byspecifically avoiding HTTP, in the cases where it's not buying you verymuch to begin with.
Photo 'Think' with a nice CC license, by Francisca Ulloa. Found using the Flickr's Create Commons Search.
I hate software licenses. Well, I kind of like the WTFPL. But most of them I don't like; they're simply too complicated. And there aretoo many of them.I was painfully reminded of this, like I need the reminding, by lookingat theRuby licensewhich leads to the even scarierLEGAL file.
In contrast, thePython licenseis a thing of beauty.
I suppose a lot of folks don't care too much about software licenses.But asa software developer that would like to consume, reuse, and redistribute as muchopen/free software as I can get away with, and workingat a big software development house that has atendency to attract legal attacks,I can tell you, I care. Because my company cares. More complicated licensingscenarios mean more time spent with lawyers, and less time in my text editor.
However, while day-dreaming of our eventual future, SaaS,I happened to think that all the licensing nonsense just goes away. Becausein the future, we won't be delivering software to customers, we'll be deliveringthe results of service requests. The output of some program. And atleast for the GPL, it seems clear to methat I don't have any downstream licensing issues. As long as I never redistribute my programs.
But of course, that really goes against the spirit of certain licenses, andI'm thinking of the GPL in particular. The GPL was designed to allow tinkerersto tinker, but SaaS doesn't really lend itself to that model. Maybe that's abig downside of SaaS; the loss of freedom to tinker. But more importantly,will software licenses be extended so the concept of 'combining source/programs' applies tousing a client program using a service over the network? Or is this already a concern?
Blue sky dreaming? Yeah, probably. But ya gotta dream!
BTW, we will clearly have to deal withsoftware patentsin the SaaS world.
Photo 'DayDream Believer' with a nice CC license, by Becka Spence. Found using the Flickr's Create Commons Search.
Duncan Cragg's Business Functions | The REST Dialoguesjust blew my mind.
Here I was, all this time, thinking myself a RESTafarian. I had however, always believed there wasa place for RPC-styled invocations. This is largely, no doubt, from the work I did on my previousproject, Jazz, where we started with RPC-styled web services, and then added some REST ones. In mymind, I've been thinking all along that REST and RPC-styled services, together, are what it takesto feasibly build a complex web services based system.
But something about Duncan's arguments rings true with me.
One thing does cause me concern though. And that is dealing with concurrency of 'objects' on the server. Once your individual POST requests end up having to hit multiple objects, locking them, you needto start to be concerned about deadlocking. Not that this wasn't a concern before, but it's stilla concern here, though Duncan seems to brush it aside too casually.
I'm not sure I believe everything can be boiled down to state-transition tables, but certainlyit would be nice if they could. Makes me wonder if things like BPEL (well, a non-XML version thereof :-)make more sense than they otherwise seem to, to me, today.
My most interesting thought though, was what this means to programmers, in terms of the APIs they use to invoke these services and get the results back. RPC maps wonderfully to function/method callpatterns. Do we really end up living in a world where every web service has the same set of methodnames available (but different typing for POST parameters, and POST and GET results)? hmmm. How else might we able to make the protocol interaction more palatable to ordinary programmers used todefining, implementing, and calling methods and functions that are more RPC-ish? Or is a functional programming style, that this interaction pattern seems best suited for, just the obvious way to do it?
Anyhoo, got some back-reading to do this week ...
As an aside, I also love the dialog style of argument that Duncan used. Not sure why, maybe it's easier to read thanstraight through narrative. Steve O'Grady also often does this,and I've tried my hand at it as well.
Photo 'Rest, and be Thankful' with a nice CC license, by Brian Aslak. Found using the Flickr's Create Commons Search.
A colleague of mine from the UK, Dave Kelsey, has just uploaded a bit of nifty new functionality for theEclipse PDT Project. PDT stands for PHP Development Tool, thenew name of the PHP IDE project at Eclipse.
The new functionality enables you to use the PHP XDebug extension. As shipped, the PDT project ships support for theZend Debugger.For any of a number of reasons, you might want to be able to use XDebuginstead of the Zend Debugger extension. Now you can!
Brief information availablehere,code and doco availablehere.
Dave hangs out on theeclipse.tools.phpnewsgroup on the news.eclipse.org NNTP server, if you have any questions, bugs to report, etc. Note that you need to be registered to the news server; if you don't already have a userid,you can get one from here.
Also note that Ben Ramsey just posted a blog entry about how to set up the Zend Debugger in Eclipse.
Photo 'Time to debug' with a nice CC license, by Henri Bergius. Found using the Flickr's Create Commons Search.
I've previouslywritten about scripting languages in Javaand some of the interop issues with them. My basic thoughts haven't changed, though I also haven'tbeen playing with any of these lately. But I have some additional thoughts.
My DEmentor, John Duimovich(he's an IBM Distinguished Engineer), found me on Google Talk last night, andwe ended up chatting about all kinds of stuff, and one topic was scripting language / Java interop.John threw out all the usual pro's that come with this sort of interop nirvana:
- You can write your (non-time-critical) business logic in a scripting language, whichwill be smaller and more readable than in Java, but more importantly, you canwrite it quicker.
- Your scripting language can make use of all the great Java class libraries available.
- You can probably make use of at least some class/function libraries in yourscripting language from Java.
I think most people, when they hear interop stories, get afraid ofperformance. Ignore that one for now; consider that you could at least prototype yourJava code in a scripting language, then convert to Java later. Interop would stillbe a huge benefit.
But performance isn't the issue. There are bigger issues. Let me recap, quickly. Readmy previous blog post for more details.
- code completion on the Java you are 'writing' in your scripting language (I can'tlive without Java code completion)
- impedence mismatches between languages; especially typed Java arrays
My experience is that the complete story isn't really all that easy with these interop stories. Which is probably the best reason youwould want to do this anyway. That takes care of the first pro.
For the second and third pro, I'll just ask: what libraries are you wanting to use in the 'other' language (be it Java or scripting language)? Is therereally that much of a difference, these days, between the functionality of,say, Java, PHP, and Ruby? Functionality from 10K feet, because you obviouslyuse Rails when using standard Ruby, and are using Servlets in Java (or worse);think holistically here. The answer is ... not really.
Is all hope lost? For language interop ... yes.
Does that mean implementations of scripting languages on Java is pointless? No.
IronPython performance is on par with python-c. So there's no reason why implementing a scripting language in Java isn't a reasonable option,though you probably want to factor in things like a need for invokedynamicand making Java a better C(more on that last one in a future blog post).
The question is, do you really need user-level language interop, or do you justneed your scripting language and it's typical libraries? I say the typical libraries, because at some point you are certainly dealing with Java objects in yourinterpreter / runtime, but they don't necessarily need to be visible to theend user; the programmer in this case. And you could certainly invent a mechanismto allow scripting language functions / classes to be implemented in Java for those non-mortals amongst us that implement core libraries. Backin the early VisualAge for Java days, the Java natives were implemented in Smalltalk(boy, was that sweet!). Who used it? Not many people (well, we didn't advertise it),but not many people would have needed it anyway. Not many people write thecore libraries.
Taking the burden off of the scripting language implementor to add an'interop facility' is also a huge benefit. At least, an interop facility thatyou have to make available as public API.
End users (programmers) win, to some extent, because they don't have two languages/class librariesto deal with. They lose the theoretical interop benefits, but they never really had themanyway.
In the end, what's the real benefit to doing this? That we get to implementour scripting languages and their extensions in Java. And not C. Or worse.With the recent GPL-ization of Java, I'm hoping that we're going to seeJava available much more widely than it had been before. Time to take advantageof this situation.
I've made all sorts of crazy assumptions here; please attempt to prove me wrong.
Photo 'Keep 'em separated' with a nice CC license, by Mark and Allegra Jaroski-Biava. Found using the Flickr's Create Commons Search.
Update: So one assumption I got wrong was that John was arguing for the level of Java interop that I'm suggesting is pointless. He wasn't. He's on the same page as me (well, closer than I thought). The problem is the term interop was used, and it clearly means different things to different people.
Useful interop are things like JNI, the Zend API, etc. Useful because I can interoperate with C, that can do anything it wants to on a machine. Useful, but difficult to use. Who wants to program in C? Especially with these rather arcane 'extension' libraries. That's not just C, that's complicated C.
When I hear interop, I hear the "end user programmers can talk to Java directly from language-X". When John hears it, he's thinking JNI. I think this is good material for a future blog post - "defining interop".
Mea culpa John. Gotta go find me a little chocolate.
I certainly hope no one mistakes me for some kind of Ruby fan-boybecause of my brand spankin' new Picante Chuck Taylors. Or was that Cayenne?I swear, my wife got them for me for Christmas, I didn't evenpick the color!
I do love 'em.
And to be honest, I am becoming a bit of a Ruby fan-boy.
Time to do a little photoshopping of that picture at the top of my blog page.
I just completed my first 'mashup', of sorts. After I wrote my blog post on Raven Rock NC State Park,I realized the NC State Park system was fertile ground for a map-based mashup.
So I wrote one.
What I did:
- Collected a bunch of information about the parks. Obviously the most painful part of this project. The format of the file is a bit odd, but that's because the URLs of the parks and names were easy to lift out of the html on the 'park chooser' page. The longitudes, latitudes took the longest to gather; I had a little Google Maps 'app' I had written that would dump the coordinates of map locations based on mouse clicks, just pasted that into the data file.
- Started working on a small HTML + JS app using the Google Maps API. My thinking was that I'd have a program I'd run on the server to read the input text file, and generate JSON data, that the HTML + JS app I was going to write would then read, to populate the map. I had some problem with that:
- Making the map 'widget' automagically resizeable was not immediately obvious, and I didn't really have a way to test whether the method I ended up using would work anywhere but Firefox 1.5. (Note I found this page from the Google Maps discussion group).
- Getting additional content on the page, with the resizing map widget, seemed like it was going to be a royal pain. Apparently I'm lost without Motif form attachments. I'm pretty handy with CSS, but never really mastered the layout bits.
- Curiously, the map data from maps displayed with the Google Maps API, and with the Google Maps page, are from different companies. TeleAtlas and NAVTEQ, respectively. According to the legend at the bottom of the maps. I could have sworn the maps were a little different, somehow, but then when I found Lake Norman State Park on the NAVTEQ map, and saw it was called Duke Power State Park on the TeleAtlas map, it was ... pretty obvious they were different. Other differences seemed to be that the TeleAtlas map seemed to show more rivers, and fewer streets.
- Google Mapplications are missing some features found on traditional Google Maps, like, oh, all the trimmings around the map (email, print, directions, search nearby, etc). At one point during prototying, I included a link to Google Maps in the Mapplication popup windows for each park. Which is obviously kinda dumb.
- I discovered KML, and after that, the HTML + JS was too much work.
- I had already written a small Ruby program to generate the JSON based on on the park data file; I just swizzled it a bit to generate KML instead.
- Added some code to get weather data and add it to the 'description' of the park, from Yahoo! Weather.
- Put it up on on the ncParksMap project page at my web site.
- Set up a cron job to rebuild the .kml file every so often.
Note that KML was originally designed for Google Earth, so you can open the .kml file in there, http://www.muellerware.org/projects/ncParksMap/ncParksMap.kml, and specify how often to refresh the file and what-not.
Note that Google Maps has been sometimes complaining that it can'tfind the .kml file. Not sure what's going on. Try refreshing the page if you see this.
Next mapplication: show surf reports at the beach, on a map.
We were watching something new on tv tonight.YouTube.And weather from around the world.
This is all new, for us, on the tv, because we downloaded the newweather service and Opera browserfor the wii.
And they're pretty good.
Here's a movie showing theweather service, although that must have been an early prototype; it looks a littledifferent, but seems functionally the same. Spinning the globe is definitely fun.
As far as the web browsing:
- As expected, web pages don't 'fit' well; we have an old skool tv, maybe an HDTV (or whatever) would do better. NYTimes comes up ok, but is not really readable without zooming,which is pretty easy to do.YouTube movies you want to zoom in all the way, they will then fill3/4 of the screen.
- The YouTube movies looked great, though some/most were darker than you would want. Maybethat's something with the tv.
- Keyboard entry is a soft keyboard (of course), but at least you're using thewand to point, and with it's feedback, it's not too terrible. But it isa soft keyboard so it is horrible. I'm going to want to be able to use a bluetooth keyboard.
- Has a favorites list; looks crude.
- Crude navigation via wand; scroll the page via wand gestures and a button down,page-to-page navigation via on-screen menu.
- last.fm via Flash basically works. Plays for a few minutes and then some page pops up. hmmm
- pandora locked up the wii. Twice. Avoid pandora.
So, whaddya know. I finally got myself a set top box, and didn't even intend to!
And I suddenly have an interest in Flash again (since Flash is supported on this browser).
Makes me wonder what kind of other content I could target for this device.
Makes me wonder when (not if, trying to be optimistic) sites will start targettingthe wii and it's capabilities. It's pretty clear that ui's will need to be drasticallychanged so that they are more navigatable, and easier to read (use larger fonts).
User agent: "Opera/9.00 (Nintendo Wii; U; ; 1309-9; en)"
Photo 'TV screen up close' with a nice CC license, by Francois Bester. Found using the Flickr's Create Commons Search.
I've finally taken the Ruby plunge. It's taken a while. My buddyChris Grindstaff recommended I look at it years ago. I had heard of it, and it sounded interesting, but coming from Chris, I took a closer look. Started following it from afar. Eventually boughtthe book. Still didn't really do anything.
Finally, as I have been posting flickr pix in my blog entries,and copy/pasting the html into new entries, it was time to automate, and thus getf4b was born. Simple command line program,and thus easy to integrate intoTextMate and Eclipse.
(Quick aside: I edit all my blog posts in .html files usingTextMate, then paste into roller when I'm all done.)
So, Ruby. I'm an old smalltalker, so I don't need muchconvincing on the gorgeousness of the language. I am a little suprised there's not much interest from theold OTI crowd in Ruby. They'll come around.
The little program I wrote uses a Ruby gem named 'flickr' to do all the flickrAPI work, but there are some issues. Check the code and you'llsee how I had to hack the photo URLs a bit. I needed to figureout how to get program arguments, the name and location ofthe program being invoked, some basic string parsing, and howto do 'here doc'. Everything else was pretty natural.
Actually, the hardest thing was figuring out to 'require' a gem. Ithelps to require 'rubygems' first, and then use require_geminstead of require for a gem. The doc didn't really make thatclear.
More later, I'm sure.
Photo 'Ruby Falls Barn' with a nice CC license, by Brent Moore. Found using the Flickr's Create Commons Search.
Mike Champion's blog entry,XML 2006 Observations,ends with some thoughts/questions on JSON. Here are my answers.
Will we see JSON substituting for XML in SOAP messages, RSS feeds, etc.?
Kind of, and no. I don't think we'll see a JSON flavored SOAP, but there's already such things as JSON-RPC, so for those SOAP usages that areRPC in nature, the answer is yes. For those SOAP usages that are document-oriented in nature, there are such things as RESTful JSON.
But it's a stretch to imagine taking on the work to enable JSON-flavored [XML-thing]. For those things that XML works well for, follow the old adage:if it ain't broke, don't fix it.
Asking about feeds is telling also. Markup (XML) is fantastic for augmenting text.I have a bias; I've been doing text markup for 20 years (nroff, tex, GML, BookMaster, HTML, XML).Nothing better than to be able to in-line visual or semantic augmentation with your text, becauseit's sooo inline. Readable. Imagining writing a document as a big JSON object, with text stringslittered with objects indicating augmentation is ... horrifying.
But that's just the text. Feeds don't neccessarily carry just text (well, at least in the future they won't). If the feed content is data, then sure, why not JSON. And the feedmeta-data itself probably also better lends itself to a data layout than XML.
So, my take is: XML for text, JSON for data. Until the day the computers take overthe world, we'll always be needing text, somewhere, and XML is the answer. But I'd ratherbe specifying my data in a data definition language like JSON, compared to doing itin XML as wonky marked up narratives.
Will people store JSON persistently?
Yes. If folks are storing XML persistently, and that XML is used to describe data in some way, I will argue that you'll save space by converting to JSON. Unless youperhaps take into consideration the fantastic compression you can get on XML, becauseof the extreme verbosity (what ever happened to anonymous end tags?).
That will require JSON-flavored APIs, schema/"data contract" languages, query/transformation languages, apps, etc.
I'm sure that lots of us at in the MS Data Programmability team are pondering what we should think and do about JSON.
Excellent. Keep us informed.
Photo 'Urban Markup' with a nice CC license, by Gord Fynes. Found using the Flickr's Create Commons Search.
Update: 2006/12/22: fixed a typo
Vacation. Holiday. w00t!
On Wednesday, I took the opportunity to head down to Raven Rock State Park to do some light hiking.Gorgeous morning. Crisp. Empty park, when I got there. I only started getting a bit warm, withmy jacket on, right before I got back to my car. Took a few pictures.
I'm always amazed when I tell people in the RTP area aboutRaven Rock, and so few people have heard about it. It's aboutan hour from the triangle. A nice park with a few miles ofhiking trails, most of which take you down to the Cape Fearriver. The main place to go is Raven Rock itself, whichis a cliff on the river, which you get to via a long setof steps. There's some rocks to climb on for the kids.
North Carolina has a pretty good state park system, witha functional web site listing the parks by name, locationvia a map, current park conditions, and nice printablePDFs of the individual parks.
Raven Rock is pretty tame, itself, though I took my walking stick, and was able to (=forced to) put it togood use a few times negotiating steps on the trail, androcks off the trail. For the more adventurous,Hanging Rock provides a fantastic view with a moderate hike.Stone Mountain is one of my favorites; walkingstick required, and the landscape at the top of the mountain isstrange and gorgeous. Both of those parks are a few hoursfrom the triangle, but worth the trip.
David Shields advises meto:
leave the firewall and use WordPress. It's more fun and more reliable outside the firewall. You'll also learn more from those who will only be able to read your blog because it is in the real world.
I'm not behind the IBM firewall. Developerworks is completely outside of the IBMfirewall.
I switched from a blog at bloggerto this blog at developerWorks about 3 months ago. Why switch?My new job entails doing some community outreach, so I thought itwas appropriate to do some of that, via blogging, at an IBM site.And the price was right.
dWorks is currently using roller, and so I supposethere is some peer pressure involved now, since I occaisonallyhave a beer or coffee with "the Roller guy", Dave Johnson.But seriously, I do like roller, generally. Better than blogger, when I was using it.
There are some downsides with the current blogging situation:
- Our roller is set up to use Velocity as it's templating language.
- It supports tags, but can't automatically generate feeds based on the tags. Though you canhack that.My understanding is that this is resolved in a later (or future) release.
- I don't feel as 'free' to post purely personal stuff at the IBM site.
I also had a blog inside the firewall, and I will concur with Dave on all his pointsw/r/t those types of blogs. I don't have time to blog here the way I'd like to; managing anotherblog isn't very practical. Likewise, per one of the points above, I'd been thinking about settingup a separate personal blog, for those times when I wanted to get personal. But like an insidethe firewall blog, it's another resource to manage, so I'm not going that route now.
I'm not sure that there are limitations on any IBMers creating blogs at developerWorks,so if any IBMers out there want a blog here, let me know, and I'll pass the info along to you. I just asked for one, and got it in two days. I asked for a wiki at the same time, and got that in one day (we use Confluence for our wiki software,which is fantastic).
Photo 'Firewall' with a nice CC license, by Lili Vieira de Carvalho. Found using the Flickr's Create Commons Search.
On JSON, recently:
Dave Winer: IT'S NOT EVEN XML!
James Robertson: Yeah, I really want another parser in my application ...
I'm reminded of the 'debate' between evolution and intelligent design.
Photo 'Change Priorities' with a nice CC license, by Christine. Found using the Flickr's Create Commons Search.