Hacker News Reader

Comment by venantius | Hacker News Reader

I'm stealing one of the YouTube comments, because I actually thought it was pretty interesting. I started watching this thinking the interviewer was an idiot, but I think the issue is a little more complicated than it seems at first. Comment from YouTube user "tapo":

So in the 90's Sun Microsystems created Java, which has two components, the programming language and the runtime. The runtime (the Java you install) lets you run things written in Java on any device regardless of OS or CPU architecture. Write once, run anywhere. This was a huge threat to Microsoft. Why write Windows programs when you could write Java programs and they'd run on any computer?

So Microsoft wrote their own Java runtime called the MS JVM, and made it part of Windows, it extended Java to do Windows-only things, meaning there were now "Java" apps that could only run on Windows, destroying the whole point of Java.

This became part of the antitrust trial because it ruined Sun's product. In a separate case, Sun sued Microsoft and won.

View on HN

Absolutely, I am not sure why the other comments are blaming the interviewer as being stubborn or thick. He was being pedantic and rightfully so. It sets a pretty good tone for the questioning, the right tone. He got multiple responses to the same question, which I think is a good thing. There is more opportunity for the questioner to get his desired response.

At the 32 minute mark it comes to a head where Gates is reading a 3 line mail for a while, rocking back and forth. The email written by Gates read: "Do we have a clear plan on what we want Apple to do, to undermine Sun".

Prior to that document being produced in the video, Gates spent a good 10 minutes or so on the arguing the use of the words, "competitive threat" and "undermine" and so forth.

Gates also admitted to speaking directly with Steve Jobs on the phone. This was clearly anti-competitive behaviour.

The next line of questioning then goes into pedantic details about Microsoft's discussions with Apple and the same game continues.

"Gates also admitted to speaking directly with Steve Jobs on the phone. This was clearly anti-competitive behaviour."

There is no law, implied, explicit, or otherwise that suggests CEOs of competing companies can't, or even shouldn't talk with each other.

While there are many areas that are off limits to competitors (setting price levels, dividing markets, reducing supply) - there are lots of valid reasons for competitors to communicate on a regular basis around issues like standards, purchasing agreements, licensing agreements, etc...

I'm sure that Boo-Keun Yoon (CEO of Samsung) and Tim Cook have frequent conversations trying to settle their differences.

The anti-competitive behaviour was the conversations with Apple regarding collusion to undermine Sun. These conversations spanned email, phone calls and meetings all within close proximity. The email was the clearest indication of it as it spelt out the "clear plan" on which Microsoft would proceed.

As per the email, the phone call (which in itself cannot be proved but more matter is shared later on when Microsoft CFO/Treasurer met with Jobs and other documents came to light).

> So Microsoft wrote their own Java runtime called the MS JVM, and made it part of Windows, it extended Java to do Windows-only things, meaning there were now "Java" apps that could only run on Windows, destroying the whole point of Java.

How does this differ from what Google did with Android, effectively leading to "Java apps that can only run on Android"?

It doesn't. Sun, and then Oracle sued Google and lost (on syntax, on API it is still bouncing around):

http://en.wikipedia.org/wiki/Oracle_v._Google

Sun settled with Microsoft before a verdict was reached, so the question of IP and if alternate implementations of a language syntax is allowed wasn't answered then.

In the antitrust suit, all that was answered was that Microsoft used its advantage with its operating system monopoly to push its version of the Java runtime. The effect was that Microsoft were not allowed to bundle their runtime, but had to offer users the choice - they were not found to be violating Sun's IP in implementing a runtime.

Syntax of a programming language not being IP protected is probably a good thing for developers, regardless of what you think of the Microsoft situation. The API being protected is a separate issue, as is the trademark on the name (which applied in the Microsoft case but not in Google's since they didn't use the trademark term in their implementation)

> Syntax of a programming language not being IP protected is probably a good thing for developers, regardless of what you think of the Microsoft situation. The API being protected is a separate issue

But in the case you cited, the API was found to be not protected (which is also the proper ruling in my opinion).

Note that Google considered using C# instead of Java at some point :)

"If Sun doesn't want to work with us, we have two options: 1) Abandon our work and adopt MSFT CLR VM and C# language - or - 2) Do Java anyway and defend our decision, perhaps making enemies along the way"

http://www.fosspatents.com/2011/07/judge-orders-overhaul-of-...

The Mono team ported Android to C#, and got some significant performance wins. http://blog.xamarin.com/android-in-c-sharp/

One wonders how much better the world would be if Google had hired some first employees that preferred expressive languages.

I'm pretty sure that Sun didn't sue Google. They'd discussed it internally and decided to let it slide. Only on being purchased by Oracle did the the lawsuit go ahead.

How does this differ from what Google did with Android, effectively leading to "Java apps that can only run on Android"?

Microsoft was a Java licensee, and Sun claimed the license required them to implement the standardized Java interface. Sun sued over the license and antitrust issues.

Google isn't a Java licensee. Oracle sued over copyright issues.

MS created Visual J++, and Visual J# afterwards. Ultimately C# was born out of these efforts and it's a much better language than Java nowadays (with some exceptions such as better enums in Java). The tooling is superb as well - Visual Studio is a kickass IDE.

Although adding ReSharper to the party doesn't hurt.

C# and .net had Delphi's mastermind, nothing to do with Visual J.

You are mistaken.

   After joining Microsoft, Hejlsberg led the company’s efforts in Visual J++ 

   [...]

   Hejlsberg helped make Visual J++ the most popular 
   and most productive Java IDE in the late '90s.

http://www.microsoft.com/about/technicalrecognition/Anders-H...

Fair point, I always thought he joined in 1998.

One if the major things .NET had in it's favor was MSR to actually figure out generics. MS Corp viewed it as an academic and experimental feature and would never have gotten it implemented on their own. From what I've heard, Delphi's mastermind was not in favor of them, but I don't have a quote for that. Furthermore, looking at C#'s first couple releases, it seems they were aiming for a slightly improved Java. Only after F# did C# reluctantly start to pick up functional features.

To MS's credit, .NET did aim to be a true multi language runtime, back to Project 7. They got feedback from many people to make sure many languages could be accommodated (looks like they've since given up on this goal). Ironically, the JVM, with it's strictly less capable VM, boasts far more languages targeting it's runtime. Probably because Microsoft worked against releasing it for other platforms and is still a bit standoffish.

> One if the major things .NET had in it's favor was MSR to actually figure out generics. MS Corp viewed it as an academic and experimental feature and would never have gotten it implemented on their own. From what I've heard, Delphi's mastermind was not in favor of them, but I don't have a quote for that.

According to Don Syme's blog posts, certain "product team members" said that "generics is for academics only." However, he did not name Anders Hejlsberg as being one of them.

Here's the blog post: http://blogs.msdn.com/b/dsyme/archive/2011/03/15/10141602.as...

Also see: http://blogs.msdn.com/b/dsyme/archive/2012/07/05/more-c-net-...

Also see the story from the other side: http://blogs.msdn.com/b/scottwil/archive/2007/10/24/working-...

I wonder if MSR's implementation of generics in .NET 2.0 was why F# got bundled into Visual Studio as a first-class language. IronPython, IronRuby, etc. never got that type of internal buy-in and got spun-off instead.

Right, I have no actual citation on Anders or other C# team members regarding their position on generics. Just personal conversion. Perhaps it's way off base. Yet, the lack of lambdas, inference, and the reluctant implementation in C# 3 (only the minimum for LINQ) suggests that was not the style they were looking for. Same for the handling of async in C# - instead of a general mechanism, it's another hardcoded intrinsic. More evidence: TypeScript also looks lackluster, despite being a big step up from JS.

I've no real clue why F# was productized, but I'd like to think it was because MS realized it has to stay competitive. F# is probably the most advanced language with that level of tooling, support, libraries, etc. I know F# is the only reason I continue to target the CLR. At the same time, MS's F# support certainly feels like it's just lip service, even while their flagship language lacks basics like a REPL. (I know, Roslyn will cure all.) I've yet to see any marketing suggesting F# would be a better choice for many projects; only esoteric sciencey and maths usages see suggested.

What'd really be forward would be for MS to support Rust or a project like that. (I believe they hired the guy behind BitC but I don't think it was for language design.)

> Only after F# did C# reluctantly start to pick up functional features.

This is not true. C# got functional features thanks to the work of Erik Meijer and his team.

His paper "Confessions of a used programming language salesman" about this work, is very well known in the compiler design community.

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.118....

I was careful not to say F# caused functional features to appear, only the timeline. I also noted all the features they added were purely for LINQ. So it does feel, to an outsider, that C# only obtained its functional features by happenstance. Had someone without Meijer's intent gone for a LINQ feature, maybe a different approach may have been taken. I get the feeling he was like a covert agent, dangling this easy way to get LINQ, to entice other employees into accidentally allowing such powerful features in, or as I believe he says in that paper "well even VB now has monads".

Sorry if I somehow misinterpreted it.

Yeah, LINQ was what got enterprise developers slowly started into the FP world.

I've never done any Windows development, so I'm curious as to why C# might be considered superior to Java (especially Java 8).

Is it simply better language features ( typing, generics, etc.?), or does the argument also include .NET and the CLR?

Will Microsoft open up development on unix systems (not mono)? I've interpreted signals from the CEO as an indication this could happen. What about visual studio?

The CLR is more flexible than the JVM, but if you're only using C# you'll usually only notice when doing C interop. With the major exception of structs and generics, which may provide large speed improvements.

C# the language is superior in essentially every way to Java. Far less code = less bugs. F# takes it up another notch, while allowing you to keep interop.

Microsoft has had plenty of opportunity to officially support Mono, but they have not. Their patent promise only extends to Mono as long as you don't run into other issues with Microsoft. If MS wanted, they could, at any time, start really supporting Mono and work to unify runtimes. But anything's possible.

To be fair, F# has its counterparts in the JVM world (like Scala or Clojure). I used the rather niche Kotlin lang on Android, for hobby projects so far, and it's pretty nice, too, even if not fully mature. More similar to Scala, I believe.

I don't think F# is particularly similar to Clojure. No more similar than OCaml or SML are to Lisp (which is not very).

True, it's a different FP flavor. They (F#, Scala, Clojure) are in similar position though in that they're FP-centred alternatives to the main language of the platform (C#, Java)

"Far less code = less bugs" ?

By that measure, APL programs must be the least buggy in existence.

The recent discussion on K suggests that may be the case.

Link?

https://news.ycombinator.com/item?id=8475809

I'm not sure if K generalizes well. It may be that plenty of software has edge cases that must be handled that don't have any elegant representations. I have a hard time believing such little code can actually work that well. But it seems impressive enough that I plan on learning it some and making sure I'm not massively missing out on something because it seems foreign.

From my own experience, less code certainly means less bugs. Even with denser code. Simply having to jump around to find stuff (due to more lines) seems to cause more problems

I've been gravitating towards the stance lately(independently of reading about K and the APL family style) of aiming towards "total-factor symbol reduction" - i.e. a program coded with fewer symbols, and fewer unique symbols, is preferable to one that introduces many new symbols, or uses existing ones inefficiently.

From this perspective, just factoring out imperative code into a named subroutine becomes a pain point because it adds new symbolic content - a new name, things being passed in, things being returned, things that were in scope suddenly falling outside of it. It is no longer an "organization tool" - you can add a level of block scope and a comment for that instead, and navigate the resulting large functions with code folding. And classes - well, classes become something to avoid!

APL style simply moves this concept down to the per-character level of thought and advocates additional care towards certain measures of readability. "It is more likely," says the APL programmer, "that you will see a typo in a 2 character name than in a 10 character name." The language aids in this process by providing tools that drastically condense common operations and encouraging their use as the default.

Read John Carmack's writings on inlining (also discussed here on HN [1]) where inlining refers to keeping one function with all its work done in there, instead of calling out even to things like "myfuncstep1", "myfuncstep2", etc.

I just hit a major bug due to that kind of thing, where stuff wasn't clear due to messy size of the code (customer insisted on C#). If the relevant sections had been sitting on screen, then I most likely would have noticed or never even made it in first place.

I also started working with a new hire, one that isn't an FP proponent, and I'm shocked at the variable names. Even iterating a list of entry objects: I'd naturally write the list as 'es', and the current item 'e'. Versus 'entriesToProcess' and 'current entry'. Or even 'entries' and 'ent'.

People's objections there seem to be that 'entries' is more readable than 'es'. While that may be true in isolation, I'm not sure it matters when working on a codebase above a few hundred lines. The amount if context is likely to be high enough that you're not going to be plucking one line out for changing, and the local context (and typing) should make it apparent it's a plural of e.g. entries, not employees.

1 https://news.ycombinator.com/item?id=8374345

Well, Java caught up somewhat with version 8: with lambdas and Streams to provide LINQ-like functionality - which, however, isn't equally good imho, and not extendable because it's not based on extension methods. And unfortunately I have no access to these goodies anyway, as an Android dev :/

Ah, and then there's still the inferior, type erasure based generics. There is nothing on par with C#'s awesome async-await. There's no yield return semantics (when used properly, you can create very clean and robust code thanks to it). You've got to deal with the infamous checked exceptions (I think it's the consensus these days that this wasn't such a good design choice after all). No single-root type system (so you've got Integers and ints, and the latter aren't objects) etc. And there's more, even little things like var keyword or partial classes that don't exist in Java (like many language features, partial classes can be used for evil, but it's very helpful for dealing with autogenerated code). Operator overloading. Nasty and weird syntax for annotations (in compare to C#'s attributes).

Some of these can be a matter of taste for sure and I'm not interested in language flamewars :) I write both Java and C# for living, just personally I prefer the latter.

It would be real big if Microsoft purchased Xamarin and made it free (or much cheaper). They've really gained momentum in recent time and it feels like they are getting recognition from MS now.

coming back to Java, after some years of programming C# I have the same feeling.

C# feels like Java done right. Many of Java's shortcomings can be masked with a great IDE (making setters and getters) nobrainers - but I prefer C#.

Except for pass-by-value and pass-by-reference. Java's model of always passing a reference value makes the mental model around references so much simpler.

It makes the model simpler, but I found this pretty cumbersome. I wanted to write a method returning two values (Boolean), so I had to return an array of Booleans. Out parameter seem easier for me (and more concise)

I thought scala was java done right ;)

Well - both, kind of :)

Take a look at this presentation: http://www.slideshare.net/omervk/scala-for-c-developers

It draws some parallels between C# and Scala.

Generics in C# don't do type erasure. That's one of the "language nerd" features that's a big win. Most other stuff I can think of is kind of surface level. (Though nice to have: Property syntax, native interop that sucks less, IDisposable, closures, extension methods, linq)

Actually, because Windows development (using Visual Studio) is not only c#

It's also vb.net, f# and so much else. Even node.js is integrated now! In short, it's a very adaptable IDE (with a lot of features also).

But it isn't Windows anymore since Owin.

What's also nice is that they are innovating the platform for integrations with popular (opensource) like features. Eg. The scaffolding of Rails got integrated into Asp.Net MVC in it's own way. NodeJS selfhostable option is adapted into .Net as "Owin". SignalR is their realtime component, you got live IDE features when developing webapps (it uses SignalR in the background)

It's kinda a mix of "all worlds" :)

I'm surprised Microsoft hasn't bought Xamarin yet. Mono being a first-class citizen (with an appropriate license) would do wonders to attract Java and non-MS developers to .Net - myself included.

Yet essentially every Java app's UI sucked, and the ones I see remaining still do. Extending Java to actually make it work for practical applications on Windows seems like a smart and useful thing to do. The whole "application should be consistent across OSes" was a pointless idea, and even today that remains true.

Java also seems nonsensical for Sun. How were they supposed to make money off it? Especially as a hardware company, it seems a bit odd to target all platforms. And in the end, how could Microsoft not buy Sun for a measly $2BN?

The idea that applications should be consistent across OSes is not really pointless, it just happens that for some reason the webbrowser is now one of the major platforms for applications instead of java running in the browser. Also in the 1990s there was not a clear indication that x86 would dominate the whole market and in particular for non customer facing applications there really was no compelling reason why they had to look good or "native", so Java certainly looked like a good idea, as did Smalltalk.

The incentive for Sun probably was in part that they wanted their high end workstations to stay relevant and maybe eventually develop cpu's that accelerated java execution.

Yet on mobile, we go out of our ways to make things look and feel native, even if the web's being used.

The concept of run anywhere, from a code execution standpoint, is fine. That doesn't preclude using platform specific APIs to make the application better. Like using C# but targeting iOS's UI toolkits. Or using signals from a Mono application.

While MS may have certainly intended to fragment Java, the core concept of platform specific APIs isn't inherently a bad thing.

Also note that during this time, MS supported Windows on non-Intel architectures so I'm not sure about the x86 comment.

How were they supposed to make money off it? It was supposed to help them sell servers (by making web programming and enterprise programming easier).

How does having a cross-platform system make their servers or systems preferable?

I'm all for it and see Java as doing quite a bit of good (despite the terribleness of the language and brain-damage it's inflicted on developers, which is a great bit of bad). I just don't get how it helped Sun, and I suppose, history shows it did not.

By increasing the ease of writing stuff that needs servers, the idea was that more servers would sell. Some (not all) of those would be Sun servers. That's a net win for Sun.

>So Microsoft wrote their own Java runtime called the MS JVM, and made it part of Windows, it extended Java to do Windows-only things, meaning there were now "Java" apps that could only run on Windows, destroying the whole point of Java.

The more important question is, was there anything that prevented Sun or anyone else from implementing those in the other OSes? Otherwise it looks like programs are limited to the most basic level everywhere. I do remember the MS JVM was significantly faster than Sun's. So the solution was to slow it down or for Sun to make it's own faster?

It's in Microsoft's interest to make things run faster on it's own OS. For example of a similar issue, see Flash on OS X and Jobs' memo regarding how it sucked and made OS X look bad and refusal to allow it in iOS. How is that a good thing and what MS did bad?

Instead of improving the JVM, Sun decided to make money by suing MS. No wonder that bloated piece of slow crap that looks like crap is dying a slow death and stopped being relevant.

I remember using a popular bittorrent client called Azureus that ran on the JVM. My laptop would get super hot and slow to a crawl. Also remember how J2ME made mobile Java development a complete hell before Windows Mobile and iPhone came on the scene?

http://www.zdnet.com/three-billion-devices-run-java-yeah-but...

>>I do remember the MS JVM was significantly faster than Sun's.

This is not true, actually. JDK1.1 1997 had JIT. MS had basically exposed the Variant and COM, the windows handles and part of WinAPI. Overriding paint(Graphic) on a native AWT component (say java.awt.Button) did nothing either and so on.

>>Instead of improving the JVM, Sun decided to make money by suing MS. No wonder that bloated piece of slow crap that looks like crap is dying a slow death and stopped being relevant.

JDK1.3 with hotspot compiler (May, 2000) had the fastest JIT by far.

From Wikipedia, http://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine

> It was the fastest Windows-based implementation of a Java virtual machine for the first two years after its release.[1] Sun Microsystems, the creator of Java, sued Microsoft in October 1997 for incompletely implementing the Java 1.1 standard.[2]

Which is the fastest JVM after 1997 is essentially a moot point after the lawsuit was filed.

I also like how Apple completely sidestepped such kinds of situations in iOS by disallowing third party SDKs and alternate browser engines. If there can be no Netscape or Java, there is no threat and no need to kill something and potentially get into trouble. Same with Google and Chromebooks.

You don't need a runtime environment on the client side to design a cross platform development toolkit. What happens with iOS is that 3rd party tools compile native iOS packages (kind of like cross compiling to target a platform different from the one you're developing in)

Such as Flash, which Apple did try to kill - remember the old section 3.3.1?

http://daringfireball.net/2010/04/iphone_agreement_bans_flas...

The clause was removed just 5 months later; there were rumors that potential antitrust issues were involved:

http://arstechnica.com/apple/2010/05/apples-compiler-policy-...

History repeats itself.

There's a few different solutions around. I believe one of them (https://trigger.io/) is even YC funded.

Your comment pissed me off a bit.

> The more important question is, was there anything that prevented Sun or anyone else from implementing those in the other OSes?

Yes, they made calls to native microsoft frameworks etc.

> I do remember the MS JVM was significantly faster than Sun's.

Lets dig out the binaries and do a perf test.

> So the solution was to slow it down or for Sun to make it's own faster?

This comment makes no sense. No idea what you mean by it.

> It's in Microsoft's interest to make things run faster on it's own OS.

This isn't about performance

> How is that a good thing and what MS did bad?

Who said it is any different?

> Instead of improving the JVM, Sun decided to make money by suing MS.

Yea they just abandoned the JVM in 2005. Hasn't changed since.

> I remember using a popular bittorrent client called Azureus that ran on the JVM.

Java for front end had requirements that most desktops of the time failed to meet. So what?

>> The more important question is, was there anything that prevented Sun or anyone else from implementing those in the other OSes?

> Yes, they made calls to native microsoft frameworks etc.

Uhm, yes, that's how you run things on another platform. You have to call that platform's APIs. Sun's JVM won't be able to create an AWT window without calling WinAPI's CreateWindow. They have to call the native APIs at some point or another.

And what use are COM components on another OS that doesn't have them?

I think there was a misunderstanding here. I thought it was about normal Java APIs which just happened to use a better abstraction on Windows than what Sun was providing. You were probably referring to MS-specific Java APIs that were corresponding exactly to certain COM objects for functionality that didn't exist on other OSes, I guess.

Yes, those are the things microsoft added. Another point was things they refused to add. Such as JNI & RMI. They used J/Direct for Windows specific system stuff.

The simple facts of the case are that Sun license the Java brand to someone who wants to implement a JVM/API but you have to pass the TCK/JCK testsuite to keep the license. MS would have failed that.

To add a bit: Microsoft added stuff to the standard packages (java and com.sun, if memory serves), but the stuff they added would have been Windows-only. So you write it on Windows, using what looks like standard packages, and then - surprise! - it won't run everywhere, it will only run on Windows. A nasty, hidden form of lockin. And Microsoft was doing this deliberately, trying for the lockin. That's why Sun sued. And, since the contract prohibited exactly what Microsoft did, Sun won.

Exact same policy with OpenGL before DIrect-X came along.

Reply on news.ycombinator.com