Live data from Hacker News

Research papers in the .NET source

mattwarren.org

21–30 of 34 posts

Re: Research papers in the .NET source

#21
post #4
post #2

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

Yes, you should check this presentation as well Safe Systems Programming in C# and .NET https://www.infoq.com/presentations/csharp-systems-programmi... It details some of the Midori project lessons learned and how they impact the design of C# 7, .NET Native and future .NET versions.

Yeah that's a great presentation, they did some pretty cool things as part of the Midori project!

Re: Research papers in the .NET source

#22
post #18

Earlier quoted context omitted.

Who do think pays the salaries of those engineers?

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 good engineering. And the evidence is there in plain sight.

Re: Research papers in the .NET source

#23

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…

I'm not sure I believe what you're saying is true. I'm a full time Clojure dev and let me tell you, if I give a damn about performance I avoid a lot of the cool parts of the language.

And it gets even more severe with Scala.

As Ruby should demonstrate, languages succeed because the community wants them. Not because they have specific performance characteristics.

Re: Research papers in the .NET source

#24

Earlier quoted context omitted.

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…

I'm not sure I believe what you're saying is true. I'm a full time Clojure dev and let me tell you, if I give a damn about performance I avoid a lot of the cool parts of the language. And it gets even more severe with Scala. As Ruby should demonstrate, languages succeed because the community wants them. Not because they have specific performance characteristics.

Hi sorry for off topic question. But how do u feel about clojure ? I am a python developer and really interested in clojure. Do u think it's worthwhile learning ?

Re: Research papers in the .NET source

#25
post #20
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.

Well, as I understand it, several of the Midori devs are now working on the Roslyn compiler and/or the CLR. So so of the lessons learnt will make it into the runtime, so at least that's something.

But yeah it would be nice if they could open-source it.

Re: Research papers in the .NET source

#26

Earlier quoted context omitted.

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…

I'm not sure I believe what you're saying is true. I'm a full time Clojure dev and let me tell you, if I give a damn about performance I avoid a lot of the cool parts of the language. And it gets even more severe with Scala. As Ruby should demonstrate, languages succeed because the community wants them. Not because they have specific performance characteristics.

Ditto with Apache Groovy, which started off as a dynamically typed language to complement Java. The original use case for Groovy was to use it when performance doesn't matter (e.g. scripting, testing, glue code) and Java (or some other statically typed language) when it does.

Unfortunately VMware wasted a lot of resources trying to redefine Groovy as a performant language which could replace Java's use case, or even run on Android (believe it or not).

Re: Research papers in the .NET source

#27
post #20
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.

Well, part of it has become .NET Native, C# 7 ref types, struct based tuples, vector spans and influenced the design of WinRT.

So that is something.

Re: Research papers in the .NET source

#28

Earlier quoted context omitted.

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…

I'm not sure I believe what you're saying is true. I'm a full time Clojure dev and let me tell you, if I give a damn about performance I avoid a lot of the cool parts of the language. And it gets even more severe with Scala. As Ruby should demonstrate, languages succeed because the community wants them. Not because they have specific performance characteristics.

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

Re: Research papers in the .NET source

#29

Earlier quoted context omitted.

I'm not sure I believe what you're saying is true. I'm a full time Clojure dev and let me tell you, if I give a damn about performance I avoid a lot of the cool parts of the language. And it gets even more severe with Scala. As Ruby should demonstrate, languages succeed because the community wants them. Not because they have specific performance characteristics.

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.

Re: Research papers in the .NET source

#30

Earlier quoted context omitted.

I'm not sure I believe what you're saying is true. I'm a full time Clojure dev and let me tell you, if I give a damn about performance I avoid a lot of the cool parts of the language. And it gets even more severe with Scala. As Ruby should demonstrate, languages succeed because the community wants them. Not because they have specific performance characteristics.

Hi sorry for off topic question. But how do u feel about clojure ? I am a python developer and really interested in clojure. Do u think it's worthwhile learning ?

Could you define "worthwhile?" Learning lisp is great if you want to be exposed to new functional programming ideas.
Post reply on HN