That's not strong typing, though. Is it? You can do Object Oriented things with Common Lisp, but my understanding is that Lisp will just crash at execution time if you pass the wrong kind of reference into a function. You also can't do, as far as I know, one aspect of Object Oriented programming: information hiding. At least, as far as I know. Now I have read that most Lisp gurus would argue that information hiding is overrated and that if you can't trust the people calling your code to use it properly, that's a human resource problem and not a programming language problem.
Dammit, Slashdot scrubbed out all of the overloaded operators in SBT. They include percent, percent-percent, less than less than equals, colon equals, less than colon equals, less than plus equals, and probably others - those are only the ones I've encountered so far. You can write a tremendous amount of build configuration with a very tiny SBT build file, but I think it starts to look like intentionally obfuscated Perl.
I think operator overloading is generally a good thing, it allows things like defining natural syntax for complex numbers or the quaternion group or matrix libraries or whatever. I think languages should allow it, or something roughly similar. But it's easy to overuse the feature, and in my humble opinion the Scala Lift project and SBT do. It's especially a problem because most search engines don't work well with characters outside of alphanumeric. You have to remember to use SymbolHound or something similar to figure out what the hell all the fancy characters mean.
For your part h), see also SBT, the Simple Build Tool for Scala, with operators
Items I think you're missing:
i) REPL for rapid exploration of language features.
j) If the language is compiled, fast compilation times. This to me is a massive reason to prefer Go and D to C++ when you're building something that has to be near C++ for speed but does not need to hook deeply into existing C++ code.
I also disagree on your need for strong static typing. Let's say you have some kind of object with functions doX and doY and some functions that manipulate those objects. Then you interface with a third party library that happens to have objects that also have doX and doY you should be able to use interchangeably with your functions and objects. In the world of Java and C#, you need to make a common interface and recompile the whole set, including the third party library, to get that to work. With Scala, you can work around it by using implicit conversions but it's still an added layer of complexity. In Python, Ruby, Perl, PHP, or Clojure, it just works. Sure you can screw up and have type errors - but you're three days into writing your unit tests when the Java/C#/C++/Scala guy is still defining his damn interfaces.
I see. I wasn't thinking in terms of friends, I was thinking in terms of family members. I have one Steam account and my kids and I take turns playing games using it. We just each have our own save files, and we mostly don't care about achievements.
For the situation you describe, I think your concern is valid.
Sure it will, they just have to play under your account.
The Steambox will have an operating system + Steam, and as far as I know the operating system won't be locked down. So you can install any third party software you want on it.
I don't think that's the advantage of weaker typing at all. I think the advantage is handling common aspects of objects without having to formally verify the type. I'm going to use an example that's been done before - say you're making a video game. You have creatures and soldiers and tanks and stuff that move around on screen. In Java, the cleanest way to implement this in a type-safe way is probably the Strategy Design Pattern. You make an interface "Move". Each way of moving - walk, run, crawl, jump, walk and jump, crawl and jump, swing from fines, fly, float, etc... becomes a separate class that implements the Move interface. All of your objects that represent movable things, solder, dog, cat, Tyrannosaurus Rex, faerie, tank, hovercraft are separate classes, and each class holds a "Move" instance internally which is invoked to control how it moves. You set that Move instance when you create each object or after you create each object, so if you want to add a movement type "Skip" later you don't have to change any existing code, and so you can create a Flying T-Rex if you want, also without changing existing code.
That works, and it's type safe. But it's also more complexity (each class holds a move instance, plus the move interface). In Clojure or Python, or even if Java if you wanted to bypass type-safety, you represent soldiers, dogs, cats, dinosaurs, etc... as untyped Maps (or Hashes, if you prefer the term). The movement types are just objects you bang into the map, and you're off to the races. You're screwed if someone puts a "swing weapon" class in the map using the key you planned for Movement, so you've lost type safety. But the logic of the program is simpler. (If my example sucks, I apologize. I am not a technical writer.)
Did you RTFA? Of course not. The whole point of OpenShift is that you can run the whole thing yourself, and anybody can host it, and if the vendor won't add features you desperately want, you can fork it and add them yourself. So if you don't like what Red Hat does with OpenShift, you can run it yourself, free, on Amazon cloud, Rackspace cloud, Oracle cloud, even Windows Azure or Google Compute, or your own private servers.
OpenShift, CloudFoundry, Tsuru, and other open source top-to-bottom Platform-as-a-Service offerings are the Clouds we should want. Compare this to Windows Azure, Heroku, Cloudbees, EngineYard, Google App Engine, etc... on those, if the vendor does something you dislike, or raises the prices, or has bad uptime, you have to re-architect some or all of your application to work with another Platform-as-a-Service provider and switch, and pray your new overlord is kinder than your old overlord. With a fully open source cloud, you can put the hosting providers into a price war with each other and pick the cheapest one that's sufficiently reliable.
That said, I still dislike trusting my data to a hosted vendor. You have to trust that they themselves are trustworthy and also that they're good enough at security to protect your hosted infrastructure from security threats both from external sources and also from other customers of their service that might act maliciously. That's still a problem - but I suspect that if you weigh it against the costs of managing your own server farm, an OpenShift cloud really is cheaper for most small companies.
I think the ideal is a type system that is flexible enough not to restrict your design and also compiles so quickly that it doesn't slow your development. Again, I'm using examples I've personally encountered - Java and Scala (strong static typing) vs Python and Clojure (runtime typing). In those cases:
1. Java compiles fast, but the type system gets in the way and you end up writing tons of boilerplate/logistical/Design Pattern code to work around it.
2. Scala has an awesome flexible type system, but the compiler is painfully slow and you spend time waiting for compilation to finish.
3. Python and Clojure basically run instantly, but of course you get type errors at runtime. The key thing is, you get most (but not all) of the errors immediately, so you can fix them right away.
Maybe something strong but very flexible type system but with fast compilation works better - maybe Haskell, or D, but I've never used any of them to write more than the simplest toy applications.
Oh, and before anyone says anything: no, this was a complicated enough manipulation between different tables changing their foreign key relationships that it couldn't be done easily with regular expressions and database stored procedures.
Instant reload is priceless when you're building something incrementally. Add this field to the database query. Add that block to the page. Add this validation to the function inputs. Add that reference to a third party library. etc... etc...
And yes, trial and error. But if a strong static type system was inherently superior to trial and error, all Java and C# production code would be bug free, right?
I'm not even that far along, so I'll defer to your experience somewhat.:) I just had to write a one-off program for work to dump a few database tables to disk, link and rejigger the data between them, and put it back into the database. I've done it before in Java, but Clojure let me get the job done in about the same length of time for the work (and I'm really new to Clojure) and just 90 lines.
Sometimes you're trying to use a concept and the type system just gets in the way. Half - or more - of the famous Design Patterns for Java are not necessary in languages like LISP, Python, Ruby, or Perl because you don't need to work around the static type system the same way. A Design Pattern gives you flexibility at the cost of more adding a layer of abstraction, and in the enterprise applications I've seen the abstraction layers are so deep that you can't see what the hell is going on from any single point in the program.
There was a financial company that switched a flagship application with one million lines of Java code to Clojure. Clojure is an offshoot of LISP that runs on the JVM. They reimplemented the complete feature set available in the Java application in less than 100,000 lines of Clojure. I don't care how smart you are, understanding 100,000 lines of a weakly typed programming language has to be less work than understanding a million lines of a strongly typed one - and if you can understand it, you can maintain it better.
Go get Hy. https://pypi.python.org/pypi/hy (Python in a LISP-y syntax. Same libraries, same features, no whitespace worries - but the project is still in alpha.) Why should Java developers have all of the LISP fun with Clojure?
You also have to weigh developer feedback time. I've developed web applications with Java Struts, coding directly to the Java Servlet API, Play Framework 1.x, and Play Framework 2.x (in Java, not Scala), and Python with Twistd. In order of speed of development of correct (i.e. in production without known bugs) code, they are from fastest to slowest: Python with Twistd, Play 1.x, Play Framework 2.x, Java with the Servlet API, Java Struts. Play Framework 1.x and Python give you instant reload. You save your changes, hit F5 in your browser, and see your change immediately. Anything I built without that takes three times as long. Play Framework 2.x doesn't have it, because under the hood Play 2 uses Scala and at least on my machine, best-case-scenario a Scala recompile of modified files after I change some Java file takes 5+ seconds. With Struts and just using the Servlet API, I have to reload the damn application and that's 10 seconds or longer. It seems like a trivial thing, but it's huge.
I'd say hot reload brings Java on par with Python for development, except Python has one extra feature: the REPL. "How does X work?" type.. "Oh, that's how it works", go back to coding. With Java, even in an IDE it's "create a public static void main (String [] args) throws Exception {/* actual code I want to test */ } " and either put Imports at the top or use fully qualified package names. So the equivalent "fast try something out" I do with Python still takes four times as long.
There's a reason that Google and Facebook and Twitter all use C++ and Java behind the scenes. But there's also a reason millions of sites use PHP, Python, Ruby, and Perl up front - because the development speed is so fast that you're into your testing (and unit tests) in a third the time of the Java version. So if your Java build takes three weeks of coding the application and one week of coding the tests, and your scripting language version takes one week of coding the application and two weeks of coding the tests (to offset the weaker type system), you still get to market faster with the scripting language.
Maybe the ideal is something like Perl6 (which has optional typing but does enforce type constraints when they're listed) or Groovy (which you can convert to Java more or less as-is once your rapid development phase is over).
No, Yahoo is trying to buy sexy brands. All the technology in the world won't get you attention if you don't have a recognizable brand. Bing works pretty well, maybe as well as Google Search, but since so many people hate Microsoft they just can't dethrone Google for search. Facebook could have built their own Instagram in a month, Mark Zuckerberg didn't buy it for the technology, he wanted to own the Instagram name.
Yahoo's biggest problem is that everyone considers it old news. Mayer is trying to fix that by getting some recognizable brands into Yahoo.
In the 2009 Star Trek, Nero has an unpredictable time machine. He got sent back in time by accident, he just as easily could have been sent into the future or destroyed. So he had an astronomically small chance to go back to his own time and save his own family. And he was sent back in time hundreds of years, so if his plot to wipe out the Klingons and the Federation succeeded, he would have plenty of time left to give the Romulans all the technology they could ever need to avoid the supernova when it happened.
I think that's better storytelling than most time travel stories. As far as I'm concerned, the list of movies with good time travel plotlines is Back to the Future (part 1) and 2009 Star Trek. I can't think of a single other film that does it well, for the reasons you state.
In general, Google isn't blocking them because those creators haven't been suing Google's Android partners and running Anti-Google publicity campaigns.
In the particular case of Youtube downloaders, I suspect a lot of people at Google don't care if you're downloading content from Youtube. I'm reasonably confident they've only created all of the digital rights management and content use restrictions for Youtube.com because the media companies would sue them otherwise.
Considering Microsoft's lawsuits against Android partners, their Scroogled advertising campaign, their backing of Facebook, and their fielding of Bing against Google Search, I can't blame Google for going to war against them.
Considering Microsoft's history of screwing customers with buggy software and monopolistic business practices (FUD tactics, intentional standards incompatibility with IE6, lying to customers about release dates for upcoming Microsoft software to hurt DR-DOS sales, etc...) I can't blame anyone at Slashdot for hating Microsoft more than they hate Google or any other tech company.
It's a publicly accessible website that anyone with a decent browser can access. So yes, it's part of the open web. Closing it off by not providing an API is a dick move by Google, but it's not like they're detecting particular browsers and then blocking access.
I'm not a fan of Samsung. But Google has consistently demonstrated a far greater commitment to industry standards and especially open source software than Apple or Microsoft. As long as that remains true, I will continue to prefer Google.
Apple does contribute open source code to Webkit and a few other projects, but most of their business runs on proprietary software and their open source contributions are miniscule next to Google's.
Because Microsoft is suing Google's Android partners for patent infringement and running a "Scroogled" anti-Google publicity campaign. This is a case where Google is merely fighting back, not abusing its market position.
I'm not, generally speaking, a Google fanboy. They're in business to make a profit, like any other company. But it just so happens that Google benefits most from an open web and Microsoft benefits most from proprietary software and a closed web. Until that changes, I know which is the lesser of two evils. The second Google has so much dominance on the web that they get more power from being closed than open, they'll be just as evil as Microsoft. But they aren't there yet.
In this particular case, Microsoft isn't asking Google to develop the application, just to give Microsoft access to the APIs so that Microsoft can develop the application. Google is not doing that, even though they've given Apple access to the same APIs. So taken by itself, Microsoft is in the right and Google is in the wrong.
But the rumor is that Google is doing this as a "fuck you" to Microsoft because Microsoft has filed patent lawsuits against most of Google's Android partners and is running the "Scroogled" anti-Google publicity campaign. This is just a way for Google to fight back.
I just checked, and there are at least four each of Honda, Toyota, Ford, and Chevrolet dealerships within 20 miles of my house. So while none of them are next door, they are effectively all competing with dealers with the same manufacturer for customers.
Slashdot Mirror
That's not strong typing, though. Is it? You can do Object Oriented things with Common Lisp, but my understanding is that Lisp will just crash at execution time if you pass the wrong kind of reference into a function. You also can't do, as far as I know, one aspect of Object Oriented programming: information hiding. At least, as far as I know. Now I have read that most Lisp gurus would argue that information hiding is overrated and that if you can't trust the people calling your code to use it properly, that's a human resource problem and not a programming language problem.
Dammit, Slashdot scrubbed out all of the overloaded operators in SBT. They include percent, percent-percent, less than less than equals, colon equals, less than colon equals, less than plus equals, and probably others - those are only the ones I've encountered so far. You can write a tremendous amount of build configuration with a very tiny SBT build file, but I think it starts to look like intentionally obfuscated Perl.
I think operator overloading is generally a good thing, it allows things like defining natural syntax for complex numbers or the quaternion group or matrix libraries or whatever. I think languages should allow it, or something roughly similar. But it's easy to overuse the feature, and in my humble opinion the Scala Lift project and SBT do. It's especially a problem because most search engines don't work well with characters outside of alphanumeric. You have to remember to use SymbolHound or something similar to figure out what the hell all the fancy characters mean.
For your part h), see also SBT, the Simple Build Tool for Scala, with operators
Items I think you're missing:
i) REPL for rapid exploration of language features.
j) If the language is compiled, fast compilation times. This to me is a massive reason to prefer Go and D to C++ when you're building something that has to be near C++ for speed but does not need to hook deeply into existing C++ code.
I also disagree on your need for strong static typing. Let's say you have some kind of object with functions doX and doY and some functions that manipulate those objects. Then you interface with a third party library that happens to have objects that also have doX and doY you should be able to use interchangeably with your functions and objects. In the world of Java and C#, you need to make a common interface and recompile the whole set, including the third party library, to get that to work. With Scala, you can work around it by using implicit conversions but it's still an added layer of complexity. In Python, Ruby, Perl, PHP, or Clojure, it just works. Sure you can screw up and have type errors - but you're three days into writing your unit tests when the Java/C#/C++/Scala guy is still defining his damn interfaces.
I see. I wasn't thinking in terms of friends, I was thinking in terms of family members. I have one Steam account and my kids and I take turns playing games using it. We just each have our own save files, and we mostly don't care about achievements.
For the situation you describe, I think your concern is valid.
Sure it will, they just have to play under your account.
The Steambox will have an operating system + Steam, and as far as I know the operating system won't be locked down. So you can install any third party software you want on it.
I don't think that's the advantage of weaker typing at all. I think the advantage is handling common aspects of objects without having to formally verify the type. I'm going to use an example that's been done before - say you're making a video game. You have creatures and soldiers and tanks and stuff that move around on screen. In Java, the cleanest way to implement this in a type-safe way is probably the Strategy Design Pattern. You make an interface "Move". Each way of moving - walk, run, crawl, jump, walk and jump, crawl and jump, swing from fines, fly, float, etc... becomes a separate class that implements the Move interface. All of your objects that represent movable things, solder, dog, cat, Tyrannosaurus Rex, faerie, tank, hovercraft are separate classes, and each class holds a "Move" instance internally which is invoked to control how it moves. You set that Move instance when you create each object or after you create each object, so if you want to add a movement type "Skip" later you don't have to change any existing code, and so you can create a Flying T-Rex if you want, also without changing existing code.
That works, and it's type safe. But it's also more complexity (each class holds a move instance, plus the move interface). In Clojure or Python, or even if Java if you wanted to bypass type-safety, you represent soldiers, dogs, cats, dinosaurs, etc... as untyped Maps (or Hashes, if you prefer the term). The movement types are just objects you bang into the map, and you're off to the races. You're screwed if someone puts a "swing weapon" class in the map using the key you planned for Movement, so you've lost type safety. But the logic of the program is simpler. (If my example sucks, I apologize. I am not a technical writer.)
Did you RTFA? Of course not. The whole point of OpenShift is that you can run the whole thing yourself, and anybody can host it, and if the vendor won't add features you desperately want, you can fork it and add them yourself. So if you don't like what Red Hat does with OpenShift, you can run it yourself, free, on Amazon cloud, Rackspace cloud, Oracle cloud, even Windows Azure or Google Compute, or your own private servers.
OpenShift, CloudFoundry, Tsuru, and other open source top-to-bottom Platform-as-a-Service offerings are the Clouds we should want. Compare this to Windows Azure, Heroku, Cloudbees, EngineYard, Google App Engine, etc... on those, if the vendor does something you dislike, or raises the prices, or has bad uptime, you have to re-architect some or all of your application to work with another Platform-as-a-Service provider and switch, and pray your new overlord is kinder than your old overlord. With a fully open source cloud, you can put the hosting providers into a price war with each other and pick the cheapest one that's sufficiently reliable.
That said, I still dislike trusting my data to a hosted vendor. You have to trust that they themselves are trustworthy and also that they're good enough at security to protect your hosted infrastructure from security threats both from external sources and also from other customers of their service that might act maliciously. That's still a problem - but I suspect that if you weigh it against the costs of managing your own server farm, an OpenShift cloud really is cheaper for most small companies.
I think the ideal is a type system that is flexible enough not to restrict your design and also compiles so quickly that it doesn't slow your development. Again, I'm using examples I've personally encountered - Java and Scala (strong static typing) vs Python and Clojure (runtime typing). In those cases:
1. Java compiles fast, but the type system gets in the way and you end up writing tons of boilerplate/logistical/Design Pattern code to work around it.
2. Scala has an awesome flexible type system, but the compiler is painfully slow and you spend time waiting for compilation to finish.
3. Python and Clojure basically run instantly, but of course you get type errors at runtime. The key thing is, you get most (but not all) of the errors immediately, so you can fix them right away.
Maybe something strong but very flexible type system but with fast compilation works better - maybe Haskell, or D, but I've never used any of them to write more than the simplest toy applications.
Oh, and before anyone says anything: no, this was a complicated enough manipulation between different tables changing their foreign key relationships that it couldn't be done easily with regular expressions and database stored procedures.
Instant reload is priceless when you're building something incrementally. Add this field to the database query. Add that block to the page. Add this validation to the function inputs. Add that reference to a third party library. etc... etc...
And yes, trial and error. But if a strong static type system was inherently superior to trial and error, all Java and C# production code would be bug free, right?
I'm not even that far along, so I'll defer to your experience somewhat. :) I just had to write a one-off program for work to dump a few database tables to disk, link and rejigger the data between them, and put it back into the database. I've done it before in Java, but Clojure let me get the job done in about the same length of time for the work (and I'm really new to Clojure) and just 90 lines.
Sometimes you're trying to use a concept and the type system just gets in the way. Half - or more - of the famous Design Patterns for Java are not necessary in languages like LISP, Python, Ruby, or Perl because you don't need to work around the static type system the same way. A Design Pattern gives you flexibility at the cost of more adding a layer of abstraction, and in the enterprise applications I've seen the abstraction layers are so deep that you can't see what the hell is going on from any single point in the program.
There was a financial company that switched a flagship application with one million lines of Java code to Clojure. Clojure is an offshoot of LISP that runs on the JVM. They reimplemented the complete feature set available in the Java application in less than 100,000 lines of Clojure. I don't care how smart you are, understanding 100,000 lines of a weakly typed programming language has to be less work than understanding a million lines of a strongly typed one - and if you can understand it, you can maintain it better.
Go get Hy. https://pypi.python.org/pypi/hy (Python in a LISP-y syntax. Same libraries, same features, no whitespace worries - but the project is still in alpha.) Why should Java developers have all of the LISP fun with Clojure?
Sometimes the type system gives more overhead than safety. A wonderful satirical example in Java: https://github.com/Mikkeren/FizzBuzzEnterpriseEdition
/* actual code I want to test */ } " and either put Imports at the top or use fully qualified package names. So the equivalent "fast try something out" I do with Python still takes four times as long.
You also have to weigh developer feedback time. I've developed web applications with Java Struts, coding directly to the Java Servlet API, Play Framework 1.x, and Play Framework 2.x (in Java, not Scala), and Python with Twistd. In order of speed of development of correct (i.e. in production without known bugs) code, they are from fastest to slowest: Python with Twistd, Play 1.x, Play Framework 2.x, Java with the Servlet API, Java Struts. Play Framework 1.x and Python give you instant reload. You save your changes, hit F5 in your browser, and see your change immediately. Anything I built without that takes three times as long. Play Framework 2.x doesn't have it, because under the hood Play 2 uses Scala and at least on my machine, best-case-scenario a Scala recompile of modified files after I change some Java file takes 5+ seconds. With Struts and just using the Servlet API, I have to reload the damn application and that's 10 seconds or longer. It seems like a trivial thing, but it's huge.
I'd say hot reload brings Java on par with Python for development, except Python has one extra feature: the REPL. "How does X work?" type.. "Oh, that's how it works", go back to coding. With Java, even in an IDE it's "create a public static void main (String [] args) throws Exception {
There's a reason that Google and Facebook and Twitter all use C++ and Java behind the scenes. But there's also a reason millions of sites use PHP, Python, Ruby, and Perl up front - because the development speed is so fast that you're into your testing (and unit tests) in a third the time of the Java version. So if your Java build takes three weeks of coding the application and one week of coding the tests, and your scripting language version takes one week of coding the application and two weeks of coding the tests (to offset the weaker type system), you still get to market faster with the scripting language.
Maybe the ideal is something like Perl6 (which has optional typing but does enforce type constraints when they're listed) or Groovy (which you can convert to Java more or less as-is once your rapid development phase is over).
No, Yahoo is trying to buy sexy brands. All the technology in the world won't get you attention if you don't have a recognizable brand. Bing works pretty well, maybe as well as Google Search, but since so many people hate Microsoft they just can't dethrone Google for search. Facebook could have built their own Instagram in a month, Mark Zuckerberg didn't buy it for the technology, he wanted to own the Instagram name.
Yahoo's biggest problem is that everyone considers it old news. Mayer is trying to fix that by getting some recognizable brands into Yahoo.
In the 2009 Star Trek, Nero has an unpredictable time machine. He got sent back in time by accident, he just as easily could have been sent into the future or destroyed. So he had an astronomically small chance to go back to his own time and save his own family. And he was sent back in time hundreds of years, so if his plot to wipe out the Klingons and the Federation succeeded, he would have plenty of time left to give the Romulans all the technology they could ever need to avoid the supernova when it happened.
I think that's better storytelling than most time travel stories. As far as I'm concerned, the list of movies with good time travel plotlines is Back to the Future (part 1) and 2009 Star Trek. I can't think of a single other film that does it well, for the reasons you state.
In general, Google isn't blocking them because those creators haven't been suing Google's Android partners and running Anti-Google publicity campaigns.
In the particular case of Youtube downloaders, I suspect a lot of people at Google don't care if you're downloading content from Youtube. I'm reasonably confident they've only created all of the digital rights management and content use restrictions for Youtube.com because the media companies would sue them otherwise.
Fair point.
Considering Microsoft's lawsuits against Android partners, their Scroogled advertising campaign, their backing of Facebook, and their fielding of Bing against Google Search, I can't blame Google for going to war against them.
Considering Microsoft's history of screwing customers with buggy software and monopolistic business practices (FUD tactics, intentional standards incompatibility with IE6, lying to customers about release dates for upcoming Microsoft software to hurt DR-DOS sales, etc...) I can't blame anyone at Slashdot for hating Microsoft more than they hate Google or any other tech company.
It's a publicly accessible website that anyone with a decent browser can access. So yes, it's part of the open web. Closing it off by not providing an API is a dick move by Google, but it's not like they're detecting particular browsers and then blocking access.
Thanks for the correction.
I'm not a fan of Samsung. But Google has consistently demonstrated a far greater commitment to industry standards and especially open source software than Apple or Microsoft. As long as that remains true, I will continue to prefer Google.
Apple does contribute open source code to Webkit and a few other projects, but most of their business runs on proprietary software and their open source contributions are miniscule next to Google's.
Because Microsoft is suing Google's Android partners for patent infringement and running a "Scroogled" anti-Google publicity campaign. This is a case where Google is merely fighting back, not abusing its market position.
I'm not, generally speaking, a Google fanboy. They're in business to make a profit, like any other company. But it just so happens that Google benefits most from an open web and Microsoft benefits most from proprietary software and a closed web. Until that changes, I know which is the lesser of two evils. The second Google has so much dominance on the web that they get more power from being closed than open, they'll be just as evil as Microsoft. But they aren't there yet.
In this particular case, Microsoft isn't asking Google to develop the application, just to give Microsoft access to the APIs so that Microsoft can develop the application. Google is not doing that, even though they've given Apple access to the same APIs. So taken by itself, Microsoft is in the right and Google is in the wrong.
But the rumor is that Google is doing this as a "fuck you" to Microsoft because Microsoft has filed patent lawsuits against most of Google's Android partners and is running the "Scroogled" anti-Google publicity campaign. This is just a way for Google to fight back.
I just checked, and there are at least four each of Honda, Toyota, Ford, and Chevrolet dealerships within 20 miles of my house. So while none of them are next door, they are effectively all competing with dealers with the same manufacturer for customers.