The Webmechs Press

URL at http://www.google.com/googlebooks/chrome/big_00.html

Since today’s browser environment is rapidly becoming the equivalent of an OS, the innovations in Chrome seem to be ideas whose time has come.  One of the central ideas behind Chrome’s architecture is to assign a different process (not thread) to each tab and the strip explains why.  The section on how they test the browser is also great propaganda that pretty much portrays Google as omnipotent in terms of technical resources. ;-)  Even though it is in comics format, the pages on Chrome’s V8 Javascript engine can get technical (and thus fun to read…).

One interesting revelation found in http://www.google.com/googlebooks/chrome/big_28.html is how existing plugins have to be allowed to get around the sandbox security restrictions built into Chrome, and how Chrome’s architecture still tries to minimize the ill effects of such a requirement. All in all the comic strip has sold me to the idea of adopting Chrome (one day, when it gets out of beta I suppose). We just have to remember to watch out for the privacy issues,  as Google has far greater potential to own us in this regard than Microsoft ever could. See http://www.srware.net/en/software_srware_iron_chrome_vs_iron.php

UPDATE: I tried Chrome out using the portable build from SRware and I have to say I’m impressed.  It really does seem to be crash-proof!  The acid test in my case is to view dozens and dozens of Youtube videos in a single session.  Firefox v3 in fact was more crash prone than v2 in this case, although v2 would also crash eventually.  Chrome was completely stable all the way up to the end of my session.

This blog article by Dare Obasanjo purports to give an insider’s view of how Microsoft might be a more desirable workplace environment than Google, in contrast to all the media portrayals about how working at Google is like being in a playground. In my own blog essay here, I would like to offer the view from the customer/pundit’s side about how Google compares to Microsoft in terms of their technology, marketing and business directions.

While I still overwhelmingly use open source technologies (primarily LAMP), changes in the way Microsoft presents its technologies mean that I no longer find myself averse to integrating with or adopting them in the near future. Gone is most of the closed, proprietary mindset which used to characterize Microsoft technologies and make them wholly unattractive to hardcore developers. Perhaps changes of such nature in the way MS is driving forward their technologies also reflects changes in their corporate culture, hence the reason behind Dare’s observations.

The biggest obstacle Microsoft faces however, is that it is saddled with so much ill will and baggage accumulated over the years, that many technically savvy people just take it for granted that they cannot come up with anything worthy - technologically speaking. The reality on the ground today is pretty different from that old stereotype. Technologies like IronPython and the DLR (both open sourced, by the way), now make .NET a very interesting and capable environment to operate in, certainly superior to Java [grudgingly open sourced very late in the game as an act of near desperation, by the way...] in many ways. Mono, despite heavy initial pessimism, actually saw the light of day and is now a useful, working, somewhat mature platform.

Other Microsoft technologies like Powershell (formerly codenamed Monad) just do not reap the mindshare they deserve. Powershell is MS’ answer to criticisms that the Windows command line is anemic compared to Unix shells, which _was_ most certainly true. Now however, the Windows command line arguably leapfrogs over current Unix shells’ functionality. Moreover, it manages to do so by adopting the most common Unix shell-isms (a sign that the Microsoft engineers involved in this effort are not afflicted with the NIH syndrome), preserving the familiarity of tried and tested conventions but supercharging them with a pipe-based paradigm that operates on .NET objects/properties instead of just plain text.  This sort of innovation is on such a fundamental level that Powershell can be rightfully called a revolutionary advance for the command line interface / paradigm.

I have tried out Powershell and I have to say, that contrary to what one would usually expect from Microsoft and despite my own heavy bias against the OO paradigm, it is _not_ lame. We have heard talk of “[pervasively] Object Oriented OSes” ever since the 90s, back when Taligent and similar initiatives (both coporate and hobbyist) were being touted as the future. Now that .NET is increasingly being overlaid on top of Windows and other Microsoft technologies and having a tool like Powershell give immediate command line access to (more or less) uniformly inspect and manipulate a whole array of .NET objects in the environment, we are effectively there today.

On the hardware front, MS again suffers from lackluster marketing, Microsoft’s multi-touch vision is far more comprehensive than Apple’s and yet it is Apple’s piddling iPhone that reaps disproportionate media coverage. Sigh…

Google’s Android, a Frankenstein-ish stack made up of a deliberately incomplete, incompatible Java implementation running on top of the Linux kernel is the media darling of the moment (scaring Symbian into open sourcing their C++-based mobile device OS, hehe), while MS seems to be doing precious little to let people know of how Mobile Windows can leverage off of the now thriving .NET ecosystem.

Even as MS fails to score points on the marketing side despite what I would consider are far more enlightened efforts today compared to those of yesteryears (karmic retribution, perhaps?), I would say that they have definitely learned real lessons from their open source competition. Many of today’s MS initiatives have genuinely picked up the good traits of the OSS philosophy and should convince those with a more pragmatic bent (e.g. those who do not possess ideological or sentimental attachments to labels and ‘movements’) - to at least reconsider their alienation to MS-originated stuff, if not consider moving to it.

All the flak and lost market share Microsoft has had to [deservedly] endure over the years seems to have changed the company. What is ironic is that while many people still have the narrow-minded view that “MS is evil”, they fail to see that Google, due to its enormous success, is in fact starting to become like MS during the latter’s heydays. We justifiably loathe MS’ former business practices and the parade of lame-ass technologies they used to introduce by the score, but Google isn’t immune to this:

When it comes to online advertising, Google, like any business with a competent, capable CEO at the helm is clearly aiming to achieve as dominant a market share as it can (aka a “monopoly”), which, to lefties, would certainly count as “evil” behaviour.

Another similarity too is that Google, having a cash cow in the form of Adsense, as MS did in the form of MS-DOS, uses it to fund as many throw-it-on-the-wall-and-see-what-sticks projects as it can, and a lot of those projects are insipid indeed. [ Google Base?!? My god, could anything be more uninspired? Fire the guy who "conceptualized" it already! Gmail is ok, but you'd think with all the initial hype, it'd have at least come close to giving Yahoo Mail a run for its money, but up to now I don't think Gmail has even a tenth of the market share Yahoo Mail does. ]

Finally, there are significant numbers of people who blindly adopt and/or defend their technologies simply because of the brand name. Whereas you had “MS zombies” before, you’ve now got uncritical, raving, Google fanboys who think the “Google” name is a rubber-stamp for cool technology. MS was obviously unable to topple Google the way it did Netscape, and now when it comes to the new frontiers of cyberspace such as online advertising, MS is clearly the underdog, while Google, the 500-pound gorilla. Still, I don’t see MS going down that easily. In the face of truly stubborn competition like was the case with Linux, Microsoft has proven quite willing to redefine itself in major ways to stay relevant (but not necessarily dominate).

After having read about the “Da Vinci Machine”,

http://www.infoworld.com/article/08/01/31/davinci-machine_1.html
http://openjdk.java.net/projects/mlvm/

it struck me that Sun/the Java people have finally seen the wisdom of supporting other languages (esp. dynamic ones) on the JVM and have decided to play catch up with the CLR. The closest CLR analog to the Da Vinci Machine would be .NET’s DLR (dynamic language runtime) which got started much earlier. While Java is clearly entrenched and has a lot of momentum behind it, I think that right now the .NET CLR’s design is the one to beat and has had the benefit of being designed from the ground up rather than being retrofitted. Moreover, while such new JVM enhancements cater to dynamic languages, it does not necessarily mean that they address the issue of inter-language operability.

As you know, in the CLR, components written in different languages can call each other very easily and it is quite clear that a lot of design attention has been made by the CLR designers to making this work cleanly from the start.

Could we expect to see languages besides Javascript/Actionscript running on top of AVM2 in the near future? As Flash is actually a far more widely deployed runtime than J2SE, this would be a very welcome and interesting development.

We see today that the OS wars have taken an interesting twist. The former clear winner - Windows - is facing stiff competition on frontiers beyond the desktop, such as mobile. On the server end, what gains Windows NT/Server had earlier made over a fragmented Unix opposition it now cedes to Linux. Because no single OS can stake a total claim over all the various hardware incarnations we have today, the battleground has instead shifted to runtimes. From where I’m standing, it is starting to look like a 3-way fight between:

A. .Net/CLR - MS .NET, Mono, Silverlight, etc…
B. Java - JVM, Google Android, JavaFx, etc…
C. Flash - Flex, AVM2/Tamarin, …

I have come to appreciate A. for its well-defined API choices. For 3D, You can use OpenGL if you want to do cross platform graphics or DirectX if you only intend to run under Windows. For client UIs, WinForms/Gtk is available cross-platform, whereas you can use the [presumably] more advanced WPF for Windows-exclusive clients. And of course, you’ve got Silverlight/Moonlight for browser hosted RIAs under Windows, Linux or OS X.

B. on the other hand is composed of a mishmash of balkanized, bastardized standards. These have sprung around Java due to Sun’s lukewarm leadership efforts and less than forthright licensing tactics and strategy. They compete directly with each other instead of offering clear differentiating strengths. It is Eclipse vs. Swing, Android/Dalvik vs. J2ME, JavaFX vs. Processing, etc… But, on the other hand, is such competition merely an indicator of a healthy, thriving ecosystem?

With Java, there certainly is *more* stuff - technologies, standards, APIs, frameworks - numerically speaking, built on top of it than for .NET, although the latter is catching up and with quality ones too (e.g. F#, IronPython, LINQ…)

C. is the least confusing runtime platform since you only get one language choice - Actionscript - and essentially a single API framework and another advantage is that Flash deployment is far more ubiquitous than either .NET or Java. One thing to note though regarding Flash is that it targets only half of the equation - client development - leaving you to deploy whatever server side technology you choose.

Licensing-wise, all three are roughly comparable with a mix of open and closed source components.

Since all 3 platforms will - ultimately, is the expectation - run more or less equally well under Windows, OS X, Linux and BSD, developers^* now have the freedom to not worry about which OS they target. But… they now have to choose which runtime platform to target!

^*with the exception of primitives who still insist on using C/C++ and the respective OS-specific APIs such as Win32 and POSIX/Unix

FPGAs or Field Programmable Gate Arrays are essentially programmable/reconfigurable hardware. A particular CPU architecture can be thought of as hardcoded whereas in contrast, FPGAs let you change the processor “architecture” any time you like. The trade-off is performance versus flexibility. While their gate configurations are reprogrammable, the different process utilized to make FPGAs mean that their switching speeds are going to be far slower than with dedicated gate designs.

On the other hand, the fact that you can tailor the “hardware” for a particular task or algorithm means that it has the potential to execute way way faster than implementing that algorithm in terms of a fixed assembly language instruction set. The caveat is that assembly language is pretty cumbersome as it is and programming at the gate level is going to be an even lower-level task.

The apparent return you get for having to endure the much more difficult programming task is that you effectively get much more computing power for the same amount of energy/power consumed. The analogy would be that of using a lower-level language to wring more performance out of less powerful hardware.

http://www.fhpca.org/
http://www.forbes.com/2003/03/25/cz_dl_0325star2.html
http://www.newscientist.com/article.ns?id=dn7448

A great, aptly-named FPGA site that discusses fun FPGA projects:
fpga4fun.com

Finally, we have a book that vindicates the desirability of a REST interface over AJAX and SOAP.

http://radar.oreilly.com/archives/2008/01/a_year_in_oreilly_books.html,

I remember back when SOAP, UDDI and all the rest of the corporate web services stack was introduced, many people in the open source community saw it as an attempt to recapture the web, making it complex enough to be an enterprise software play. But those complex stacks never caught on.

gives us a whiff of the commercial motives behind the introduction of technologies that override REST.

The quote in http://www.oreilly.com/catalog/9780596529260/index.html,

RESTful Web Services … provides a practical roadmap for constructing services that embrace the Web, instead of trying to route around it.

is a very telling indictment of the philosophy behind these non-REST technologies. They piggyback on top of HTTP but then seek to subvert the core ideas of the web! In a mailing list post from a couple years back, I expressed similar sentiments.

Back when SOAP and Web services were all the craze and Google introduced a SOAP-based API to their Search Engine some years ago, I frankly could not understand what was going on inside their supposedly brilliant heads. A REST-style URL-based interface would have been immensely simpler to learn and would not really have lost any functionality compared to the SOAP-based API. What happened? Google swallowed the “Web Services” Kool-Aid is what. (Some might even say the blame goes all the way back to Dave Winer and wonder why the rather dubious invention that is XML-RPC ever got all the attention it did)

It is quite interesting to discover that even for more demanding applications such as payment gateways, a REST-based approach is still feasible. A Philippines payment gateway, payeasy.ph, eschews a SOAP-based interface in favor of the much simpler GET and this is apparently enough to get things done. Having suffered the hell of interfacing with SOAP-based payment gateways, I couldn’t agree more with their decision and am left wondering why more people have not realized that they can do away with all the Rube Goldberg-style machinery imposed by SOAP (worried about job security perhaps? )

David Mertz, in this Charming Python column, makes multimethods sound hopelessly complicated like he always manages to do in his own inimitable way (sorry, David). After coming across the enlightening wikipedia article on multimethods though, I have since discovered that the concept is really quite simple to understand.

In a nutshell, Multimethods are nothing more than overloaded methods, but in a dynamic language context. Recall that in dynamic languages a function doesn’t usually care what type is being passed to it, so for example, the following Python function:

def addtwoitems(a,b):
  return a+b

can be fed strings, integers or any other object. Multimethods bestow more flexibility and control over this aspect of overloading. With them, you get to specify different function bodies depending on what the exact function signature is. So, again in Python using decorators:

@multimethod(int,int)
def addtwoitems(a,b):
  return a+b

@multimethod(str,str)
def addtwoitems(a,b):
  return a+" and "+b

etc…

This is basically nothing more than a cleaner way of expressing code as opposed to doing if-then type-checking clauses within a function. Armed with this introduction, hopefully you can go back to Mertz’s column and figure out the rest of what he is trying to say.