Research papers in the .NET source • Hacker News Board

Re: Research papers in the .NET source

#31

Post by hhggoo » Sat, Jan 07, 2017, 2:56 AM UTC

bad_user wrote: post #22

KirinDave wrote: post #19

Earlier quoted context omitted.

It's more that a lot of the work people admire was done before or close to the acquisition date and therefore probably should be credited to Sun. That said, I'm not sure why things like speculative execution in the JVM context get such play as dark magic when it seems like the JVM and CLR are pretty neck-and-neck in terms of deliverable performance when we get down to the level where we're not affected by larger arch…

Evidence: JRuby, Clojure, Groovy are dynamic languages that have been successful on the JVM and that simply can't have the same performance on the CLR for obvious reasons. Microsoft tried investing in IronPython and IronRuby but failed. Furthermore a language like Scala can have a type-system that diverges from that of Java (e.g. higher kinded types) without taking a hit in performance. It's not dark magic, it's just…

Microsoft didn't fail at IronPython and IronRuby for technical or perf reasons, they owned the projects and essentially withdrew funding, presumably this delayed all the dlr work too dynamic invoke etc.. rosyln changes etc.., it was a disappointement at the time to me 2010? and essentially allowed the JVM to pull ahead in community adoption of other languages. Where MS is now this decision to withdraw from iron* looks insane, but the attitude to open source and community was different then. Time has pasted. Happy clojure developer on JVM today

Re: Research papers in the .NET source

#32

Post by serbrech » Sat, Jan 07, 2017, 7:53 AM UTC

krylon wrote: post #20

NKCSS wrote: post #2

This Midori project looks interesting: http://joeduffyblog.com/2015/11/03/blogging-about-midori/

It sounds absolutely fascinating, but it's a little sad that it did not go beyond the research stage. Like building a flying car and then hiding it in a garage. I understand how difficult it would have been for Microsoft to turn Midori into a product, but still I would like to see what that would have been like.

I don't agree. I think it's one of the strength of a large corp like MS. They are able to separate research and prototyping from product development. You don't turn a research project into a product. You learn from it and incorporate it into your products

Re: Research papers in the .NET source

#33

Post by pjmlp » Sat, Jan 07, 2017, 8:20 AM UTC

KirinDave wrote: post #29

bad_user wrote: post #28

Earlier quoted context omitted.

I don't really understand your reply. Where you replying to my comment?

I'm saying that your idea that the JVM enables performance for dynamic langiagss, and then that's why the languages succeeded is wrong. I also think it's wrong to imply IronPython and IronRuby failed for purely performance reasons.

Actually the JVM support for dynamic languages (invokedynamic) was only added after .NET, thanks to IronPython project, created the DLR first as a side project, then eventually released it as part of .NET 4.0.

I imagine only those of us that work regularly with both platforms get it right, when each got what, and even then it is easy to lose track.

Re: Research papers in the .NET source

#34

Post by krylon » Sat, Jan 07, 2017, 11:29 AM UTC

serbrech wrote: post #32

krylon wrote: post #20

Earlier quoted context omitted.

It sounds absolutely fascinating, but it's a little sad that it did not go beyond the research stage. Like building a flying car and then hiding it in a garage. I understand how difficult it would have been for Microsoft to turn Midori into a product, but still I would like to see what that would have been like.

I don't agree. I think it's one of the strength of a large corp like MS. They are able to separate research and prototyping from product development. You don't turn a research project into a product. You learn from it and incorporate it into your products

I think they could have turned it into a product if they had wanted to.

They had, however, a very, very good reason not to - it probably would not have been backwards compatible with Win32, so the huge amount of third-party software that exists today could not have run on it. And that - whether one likes Windows or not - is a very compelling selling point.

So things they learned building Midori will trickle back into the Windows/.Net world. I agree that that is what a good research department is for.

But still, it would have been nice to take Midori for a test drive and see what it would have been like.