Showing posts with label java. Show all posts
Showing posts with label java. Show all posts
February 16, 2013
June 07, 2012
Why People Hate Java
It's an old obsession, that does no good to anyone. But here's my answer on Quora.
June 21, 2011
June 11, 2009
October 31, 2008
Dare Obasanjo on whether the Yasn-as-platform is dead. (channeling Alex Iskold)
Eeek!!! Has one of the major planks of my understanding and prediction of the software industry just turned turtle and sunk?
Well, I still believe in the widgets and YASN-as-Platform model. But some things clearly went wrong in Facebook's case. Is this in relation to their being evil?
Or is it an issue when giving away access to your platform : applications must pay somehow. What does this bode for GAE or Amazon or Faceforce or Microsoft's Azure? Presumably paying apps. earn their keep.
Meanwhile, it turns out that Java never made money for Sun. Which shouldn't surprise anyone. But does raise the question, what was their strategic objective? It's one thing to have had a sound strategy and just been beaten (eg. by Microsoft's C# or the free-software movements swarm of "scripting" languages) but it's very hard to see what on earth they were expecting from Java.
Eeek!!! Has one of the major planks of my understanding and prediction of the software industry just turned turtle and sunk?
Well, I still believe in the widgets and YASN-as-Platform model. But some things clearly went wrong in Facebook's case. Is this in relation to their being evil?
Or is it an issue when giving away access to your platform : applications must pay somehow. What does this bode for GAE or Amazon or Faceforce or Microsoft's Azure? Presumably paying apps. earn their keep.
Meanwhile, it turns out that Java never made money for Sun. Which shouldn't surprise anyone. But does raise the question, what was their strategic objective? It's one thing to have had a sound strategy and just been beaten (eg. by Microsoft's C# or the free-software movements swarm of "scripting" languages) but it's very hard to see what on earth they were expecting from Java.
October 21, 2008
June 02, 2008
Why Open Source Java will Win SaaS Platform Wars
Slightly odd report of a McKinsey article. It says J2EE and .NET are unsuited to providing Platform-as-a-service which are a growth area. And suggests that open-source is likely to win out.
Where the java comes from, I'm not entirely sure.
Slightly odd report of a McKinsey article. It says J2EE and .NET are unsuited to providing Platform-as-a-service which are a growth area. And suggests that open-source is likely to win out.
Where the java comes from, I'm not entirely sure.
January 23, 2008
Windows 7 to be integrated with Microsoft Live!.
What does it mean though?
MS has two problems :
- the desktop OS is almost a commodity. There are few applications that need Windows's specific services (as opposed to equivalents on Mac, Sun, Linux, or Android) It's hard to imagine Windows 7 doing something that other OSs aren't thinking about or couldn't quickly copy. (LINQ for serious applications? Drivers for multitouch Surfaces? Everyone will have something like that. )
- the PC is about to explode into the device swarm.
How does closer integration between Windows and Live! help in that context. It's not a winning move for MS to make their Live! services dependent on Windows 7. Will they exclude XP and Vista users from Live! in 2010? Unlikely.
After that, they can only compete on "seemless experience". But every time Microsoft compete against Apple on anything resembling an "experience", they hardly have the upper hand.
Now, the natural tethered client of an online service is a light-weight virtual machine like Flash, Silverlight or JavaFx. Not a whole operating system - users will want their virtual machines to play well together in a common sandbox, supporting
copying, pasting, dragging and dropping etc.)
There is scope for some individuation and platform warring among standards for these virtual machines. MS may be able to make Silverlight-only services, but they'll certainly have to make Silverlight run on Mac (and at least condone clones running on Linux)
This kind of virtual machine is also a natural for the device swarm : eg. Flash on Chumby, Java VM on mobiles ... Silverlight on XBox?
So while the desktop OS becomes a commodity, this space is going to get hot as the VMs compete for developers' attention. Particularly smaller devices are only likely to come with one of these virtual machines pre-installed. They'll compete on video-handling capability, graphics library, back-end data synchronization, bredth of applicability etc.
In a sense, the Java vision is finally coming into its own ... although whether Java turns out to be the victor is another matter.
What does it mean though?
MS has two problems :
- the desktop OS is almost a commodity. There are few applications that need Windows's specific services (as opposed to equivalents on Mac, Sun, Linux, or Android) It's hard to imagine Windows 7 doing something that other OSs aren't thinking about or couldn't quickly copy. (LINQ for serious applications? Drivers for multitouch Surfaces? Everyone will have something like that. )
- the PC is about to explode into the device swarm.
How does closer integration between Windows and Live! help in that context. It's not a winning move for MS to make their Live! services dependent on Windows 7. Will they exclude XP and Vista users from Live! in 2010? Unlikely.
After that, they can only compete on "seemless experience". But every time Microsoft compete against Apple on anything resembling an "experience", they hardly have the upper hand.
Now, the natural tethered client of an online service is a light-weight virtual machine like Flash, Silverlight or JavaFx. Not a whole operating system - users will want their virtual machines to play well together in a common sandbox, supporting
copying, pasting, dragging and dropping etc.)
There is scope for some individuation and platform warring among standards for these virtual machines. MS may be able to make Silverlight-only services, but they'll certainly have to make Silverlight run on Mac (and at least condone clones running on Linux)
This kind of virtual machine is also a natural for the device swarm : eg. Flash on Chumby, Java VM on mobiles ... Silverlight on XBox?
So while the desktop OS becomes a commodity, this space is going to get hot as the VMs compete for developers' attention. Particularly smaller devices are only likely to come with one of these virtual machines pre-installed. They'll compete on video-handling capability, graphics library, back-end data synchronization, bredth of applicability etc.
In a sense, the Java vision is finally coming into its own ... although whether Java turns out to be the victor is another matter.
November 13, 2007
My word!
This is bloody aggressive.
I'm going to have to start talking about Google's November Blitzkrieg, a sudden, vicious attack on three fronts : against Microsoft, Sun and Facebook (with MySpace rapidly surrendering and getting with the program).
The article makes a convincing case that this is a decisive blow against Sun's mobile platform aspirations. What is likely to happen is that they'll either sue for peace by falling into line with Google, and accepting the effective merger of Java and Dalvik now under Google's leadership and fully open source. Or they'll fight on, but without any real chance of success.
This is bloody aggressive.
I'm going to have to start talking about Google's November Blitzkrieg, a sudden, vicious attack on three fronts : against Microsoft, Sun and Facebook (with MySpace rapidly surrendering and getting with the program).
The article makes a convincing case that this is a decisive blow against Sun's mobile platform aspirations. What is likely to happen is that they'll either sue for peace by falling into line with Google, and accepting the effective merger of Java and Dalvik now under Google's leadership and fully open source. Or they'll fight on, but without any real chance of success.
November 06, 2007
October 31, 2007
Don't get me wrong. I think OpenSocial is a great idea, I want to play with it and support it.
But I want to sell a vision of what I think the real potential of a yasn-as-platform is. Which is giving people and third party developers the ability to build and manipulate their own social graphs.
Until the specs come out, I don't know if OpenSocial will encompass that vision. I think the paradox is that if it fully does, it relegates actual YASN companies to mere implementors of the spec. - effectively commodity hosting providers. (Something similar used to happen when Microsoft defined hardware standards - lots of cheap commodity hardware appeared, which was good for users but not for people trying to innovate new hardware devices.)
Of course, Google may be trying to play the same game with the YASNS.
OTOH, I'd guess the standard won't encompass what I'm thinking of - so in that sense it still leaves plenty of opportunity to individual YASNS to innovate and distinguish themselves. It's just that the application makers will have to handle each differently.
Like Folknology and some others, I'm reminded of Java. I always thought that Sun's "write once, run anywhere" was pretty bogus. Most of what's interesting with software is how it touches the things outside itself. Screens, keyboards, mice, network sockets, sound-cards etc. Operating systems can make managing those more civilized but a programming language can't hide their existence or lack-thereof. (And if you write a program that doesn't need much in the way of peripherals then C is pretty much write once, (compile and) run anywhere too.)
Anyway, what determines the awesomeness of your game's graphics (apart from your talent) is the video-card, screen-size and resolution - not the difficulty of abstracting away the difference between Mac and Windows low-level graphics APIs. That's why Sun kept trying to produce a decent abstraction layer over the Mac / Windows / Gnome GUIs and no-one ever really cared. (The web-browser OTOH provided a genuinely better, as in easier, way to build GUIs and people flocked to it.)
There's something analogous here. What's interesting with social widgets is how they touch the resources of the social network, not how they inject themselves into the user's home-page. But, just as factors such as screen-resolution or number of mouse-buttons was outside the control of the JVM, so the resources of the YASNS, factors such as "community tolerance of hot-potatoes", "willingness to accept strangers as 'friends'" or "ability to distinguish ex-girlfriends from ex-bosses" are likely to be outside the scope of the OpenSocial APIs.
Applications that want to take advantage of the special resources of particular social networks are going to have to get down and deal with the specifics of each. LinkedIn's recommendations from colleagues, or statistics about how many questions have been answered don't necessarily have a counter-part on Ning. But Ning's photo-gallery doesn't exist on LinkedIn. So will OpenSocial try to fake them with library code of its own? Will it demand that everyone who signs up to the spec. guarantees these features as a minimum? Or will it, basically ignore all this for now.
Hence I can imagine the OpenSocial API always running behind the wavefront of real innovations on the yasn-as-platforms. Just as Java has never managed to keep up with Windows and the Mac. Really interesting widgets will be written for a particular platform, to take advantage of its strengths, and only copied over to others as and when the advanced features become available there too. And then, again, long before those advanced features have made it into the common API itself.
Not saying it's bad or not useful. But ...
But I want to sell a vision of what I think the real potential of a yasn-as-platform is. Which is giving people and third party developers the ability to build and manipulate their own social graphs.
Until the specs come out, I don't know if OpenSocial will encompass that vision. I think the paradox is that if it fully does, it relegates actual YASN companies to mere implementors of the spec. - effectively commodity hosting providers. (Something similar used to happen when Microsoft defined hardware standards - lots of cheap commodity hardware appeared, which was good for users but not for people trying to innovate new hardware devices.)
Of course, Google may be trying to play the same game with the YASNS.
OTOH, I'd guess the standard won't encompass what I'm thinking of - so in that sense it still leaves plenty of opportunity to individual YASNS to innovate and distinguish themselves. It's just that the application makers will have to handle each differently.
Like Folknology and some others, I'm reminded of Java. I always thought that Sun's "write once, run anywhere" was pretty bogus. Most of what's interesting with software is how it touches the things outside itself. Screens, keyboards, mice, network sockets, sound-cards etc. Operating systems can make managing those more civilized but a programming language can't hide their existence or lack-thereof. (And if you write a program that doesn't need much in the way of peripherals then C is pretty much write once, (compile and) run anywhere too.)
Anyway, what determines the awesomeness of your game's graphics (apart from your talent) is the video-card, screen-size and resolution - not the difficulty of abstracting away the difference between Mac and Windows low-level graphics APIs. That's why Sun kept trying to produce a decent abstraction layer over the Mac / Windows / Gnome GUIs and no-one ever really cared. (The web-browser OTOH provided a genuinely better, as in easier, way to build GUIs and people flocked to it.)
There's something analogous here. What's interesting with social widgets is how they touch the resources of the social network, not how they inject themselves into the user's home-page. But, just as factors such as screen-resolution or number of mouse-buttons was outside the control of the JVM, so the resources of the YASNS, factors such as "community tolerance of hot-potatoes", "willingness to accept strangers as 'friends'" or "ability to distinguish ex-girlfriends from ex-bosses" are likely to be outside the scope of the OpenSocial APIs.
Applications that want to take advantage of the special resources of particular social networks are going to have to get down and deal with the specifics of each. LinkedIn's recommendations from colleagues, or statistics about how many questions have been answered don't necessarily have a counter-part on Ning. But Ning's photo-gallery doesn't exist on LinkedIn. So will OpenSocial try to fake them with library code of its own? Will it demand that everyone who signs up to the spec. guarantees these features as a minimum? Or will it, basically ignore all this for now.
Hence I can imagine the OpenSocial API always running behind the wavefront of real innovations on the yasn-as-platforms. Just as Java has never managed to keep up with Windows and the Mac. Really interesting widgets will be written for a particular platform, to take advantage of its strengths, and only copied over to others as and when the advanced features become available there too. And then, again, long before those advanced features have made it into the common API itself.
Not saying it's bad or not useful. But ...
Subscribe to:
Posts (Atom)
