

James Gosling Screwed Us: “Write Once…” is Anti-Customer - cek
http://ceklog.kindel.com/2013/02/21/james-gosling-screwed-us-write-once-is-anti-customer/

======
suyash
Another article with Cathy Title but No Meat. The author of this article
clearly does not understand JVM or what it does and how much it helped in the
whole 'WORA' movement. James Gosling is the real hero, thanks for giving us
JAVA.

\- Java Enthusiast

~~~
cek
OP here. James Gosling is actually a hero to me. I hold him up there with
Dennis Ritchie, Jim Gray, and Anders Hejlsberg. He had a bold, bodacious
technical vision and he moved heaven and earth to make it happen. Great things
have happened as a result. Billions of $ have been made. Many developers
learned to program with a language better than C++ to learn on. Much of his
original thinking has inspired others to do more great and bodacious things.

However, his creation also created a faulty mindset. He encouraged that
mindset. I know he didn't actually coin the term, but I was around and I heard
him speak. He toed the party line. Using his name is relevant to this
discussion because, I believe, it highlights the problem: The "write once"
approach is faulty because it started with an application of technology, not
the customer.

~~~
dman
You dont define this mindset clearly either in your article. Could you
elaborate which mindset Gosling promoted that has set the world back.

~~~
cek
Sorry it is not clear. I tried to express it but obviously didn't do it well
enough. Here's another try:

The best products in the world are those created by organizations that start
with the customer. Everything they do starts with customer needs, pains,
desires. They work backwards from that. Eventually they decide what tools &
technologies to use to deliver greatness to the customer.

Write Once... encourages a mindset that doesn't start with the customer, but
with a technology. Instead of focusing on the features & capabilities that
matter the most to the customer, the focus is on something like HTML5 (or
Java).

The best products result from focusing on really delighting the customer by
doing a few things really, really well. Given mobile platform fragmentation
one axis where this is critical is what platforms to support initially. WORA
(esp HTML5) leads to a mindset where it's important to get the experience
running on many devices simultaneously; the 'focus' is on doing a crappy job
across many things.

I'll repeat what I said in the article here: I don't hate HTML5. I code HTML5
almost every day. The product I launched on Monday makes heavy use of HTML5.
But only because our customer value proposition led us to the need to build a
website, and we had capabilities that needed to be highly interactive. HTML5
is a great technology that addresses this.

The summary: If you must target multiple platforms, focus on the experience;
then try to get code re-use. Don't do it the other way around.

~~~
dman
I agree in some parts with you but I think you would make your points much
more forcefully if you point to exact technical points where Java got the
level of abstraction wrong and where going direct to metal would have been
better.

~~~
shawnb576
Two problems here worth calling out: even when the forms packages worked, they
produced apps that looked like crap. HTML is worse in this regard, you get
poor quality mobile apps (imagine if your app needs an interactive map...JS
maps are terrible in mobile browsers), and you have a bunch of places where
JS/CSS/HTML/XHR differs b/t browsers and it's painful to get them all working.

Second problem, at least initially, I'm sure it's better now, was JVM
implementations in the mid-90s were not super consistent and you'd run into
runtime issues that were difficult to work around.

Are you arguing WORA with Applets worked and moved the industry forward? Flash
pretty much took over this charter but even then getting performance on many
devices out of a Flash runtime was pretty damn hard, so even it fell down on
this.

Much better to have a shared core (if you can) and write customer-centric,
awesome device-native UI experiences.

~~~
dman
I think some abstractions are more enduring than others. At one point everyone
wrote assembler, then C came along and offered a write once and run
everywhere. It so happened that C nailed the performance / expressiveness
efficient frontier and created a world where people arent writing assembler
anymore.

The question I find interesting in this context is - is it possible to write a
rendering pipeline and UI toolkit all the way down in a garbage collected
language that is performant. It appeared that we in industry have taken a step
back and are now content with the bottom layer being all native. I dont know
if its because the Sun UI team didnt have the right people or if the
abstraction of a garbage collected high level language does not scale down to
writing graphics apis.

------
randomracker
It's a vision not fully realized. It's not any more anti-consumer than an
unfinished bridge is anti-motorist.

