Let's compete with these other languages

[BrannonKing]

In considering C#’s primary competition, I’ve written up some key differences between each language. I feel like we could actively compete with most of these in C#. I feel like a lot of the syntactical sugar enhancements that came with C# 6.0 were failing to address these more critical needs. Feel free to disagree or add to. I realize that there are already many discussions about these in this very venue, but I needed a more over-arching list. Things that we should addressed in C# to compete with: 1. Matlab * Multiple return values. * Faster array access, especially multidimensional array access. * Better math libraries or an enhanced ability to make such. * Make operator overloads supported in interfaces (or transfer them through generics somehow). * More efficient/easier floating point comparisons with partial precision. * Support operators in the generic “where” clause. * More compile-time code optimizations. 2. Java * Covariant return types. * Anonymous classes that implement an interface. * Better 64bit math performance. * Some way to determine/tell that delegate closures are not held, but are only used in immediate execution. * Better scale-out server bus-type process invocation (slowly coming in aspnet land). * Open source the GUI frameworks. 3. C++ * Covariant return types. * Pass value types by reference when possible or make the runtime smart enough to do this. * Allow reference types to be allocated on the stack (in safe code) or make the runtime smart enough to do this. * Allow generic inference in the constructor. * Default values in generic declarations. * Again, we lose on math performance. * Include constraints in the method signature as necessary. 4. F#, Erlang, Rust * Allow more formal mutable/immutable type declaration. * Support a (perhaps-contrary-to-OO) approach of data being separated from code. * Support tail calls. * Support “return void”. * Less verbosity in tuple or array inference. * Perhaps tuples are arrays?

[WolfieWerewolf]

I'm going to chime in here and second everything Brannon wrote and add IronPython functionality to the list, it seems like the DLR is being merged into Roslyn so this shouldn't be a far stretch. In particular:

The ability to import specific namespaces from a referenced assembly without importing the whole thing; I've noticed some workarounds in the Roslyn project using the VS project system to get around this specific issue. Additionally it's nice how IP makes all imported .NET methods Virtual, why not, if we are moving towards Dynamics it would be nice to be able to inherit from anything and override it.

http://ironpython.net/documentation/dotnet/dotnet.html

/W

On 4/5/2015 1:02 PM, Brannon King wrote:

In considering C#’s primary competition, I’ve written up some key differences between each language. I feel like we could actively compete with most of these in C#. I feel like a lot of the syntactical sugar enhancements that came with C# 6.0 were failing to address these more critical needs. Feel free to disagree or add to. I realize that there are already many discussions about these in this very venue, but I needed a more over-arching list. Things that we should addressed in C# to compete with: 1. Matlab

• Multiple return values.
• Faster array access, especially multidimensional array access.
• Better math libraries or an enhanced ability to make such.
• Make operator overloads supported in interfaces (or transfer them through generics somehow).
• More efficient/easier floating point comparisons with partial precision.
• Support operators in the generic “where” clause.
• More compile-time code optimizations. 2. Java
• Covariant return types.
• Anonymous classes that implement an interface.
• Better 64bit math performance.
• Some way to determine/tell that delegate closures are not held, but are only used in immediate execution.
• Better scale-out server bus-type process invocation (slowly coming in aspnet land).
• Open source the GUI frameworks. 3. C++
• Covariant return types.
• Pass value types by reference when possible or make the runtime smart enough to do this.
• Allow reference types to be allocated on the stack (in safe code) or make the runtime smart enough to do this.
• Allow generic inference in the constructor.
• Default values in generic declarations.
• Again, we lose on math performance.
• Include constraints in the method signature as necessary. 4. F#, Erlang, Rust
• Allow more formal mutable/immutable type declaration.
• Support a (perhaps-contrary-to-OO) approach of data being separated from code.
• Support tail calls.
• Support “return void”.
• Less verbosity in tuple or array inference.
• Perhaps tuples are arrays?

— Reply to this email directly or view it on GitHub https://github.com/dotnet/roslyn/issues/1798.

[BrannonKing]

You bring up an interesting point. A lot of recent grads at my workplace came out of school knowing Python. I don't fully understand the appeal to the language. My guess is that its licensing and platform availability have given it an edge. Also, it has some great and useful libraries for scientific work. I still feel that this is one of the major weaknesses of the .NET platform. For whatever reason, the academic leadership have not bothered with making .NET libraries for analysis. That begs the question: do we compete with Python or integrate it fully in a way that all the existing Python libraries become first class citizens?

[WolfieWerewolf]

Brannon,

Given that IronPython is a .NET language I wouldn't look at it as "competition" at all but rather a logical integration. IronPython is built on top of the DLR and does some very interesting things that C# doesn't currently do but could be made to. For me the appeal to IronPython is it's dynamic capabilities, I know a lot of c# die-hards beat the "Type Safety" drum but in reality C# isn't really that type safe anymore, especially with the increasing use of XAML. I've compiled lots of broken XAML code that only pukes at at run-time. The biggest distinction I can see, from my limited experience, is that in Python there is no difference between an object and a class; they are one and the same, you can change the object on the fly, which is very useful not only in scientific circles but in Financial Markets as well; derivatives trading is my area of focus and the more dynamic code I can use the more effective and competitive I can be. From what I can see C# is going dynamic anyway so I'm probably advocating something that is already well in the works.

The Interactive Window / REPL concept, in my opinion, is being driven in the wrong direction. At the moment there are REPL's for everything but they are all limited in scope and buried in an external process via remoting (I thought we weren't supposed to use remoting anymore in favour of WCF?) . What happens in the REPL stays in the REPL. Why not integrate the VS project system into the REPL so a developer can write a class in a .cs file, switch to that context in the REPL via the namespace, and instantiate it right inside Visual Studio? With all the Syntax Trees moving into user land it should be possible to compile in-memory micro-assemblies of only what's required for a particular syntax tree to execute. And why stop with C#, a repl could host C#, F#, IronPython, NodeJS, PowerShell all at the same time. Create a class in C#, load in a C python module via IronClad, say NumPy, run some analysis on some data with it, navigate the object hierarchy using a PowerShell Provider, and then dump the output to a grid in a VS ToolWindow or a D3.js graph.... the possibilities are endless, it will just take some thinking outside of the box..... but I sincerely see the language "silos" as a major innovation buster. I was once asked what language I prefer to write in and my answer was simply, "the right one for the job".... Design patterns exist to guide us into well known, proven structures, they don't dictate a particular language... let's use everything.

End of rant.

/W

On 4/5/2015 3:26 PM, Brannon King wrote:

s become first class

[BrannonKing]

I recognize that many programmers work in multiple languages on a given day, but I don't consider that to be ideal. I want each member of my team to have a thorough and deep understanding of the language they are working in, which is easier without having to write code in multiple languages. (Yes, if you can make WPF puke you're doing better than me; it usually fails silently.) I recognize that many programming languages have arisen to fill a space that was difficult to approach from some other language or to explore a new form/idea. I think that's great, but I can also see those ideas being taken and merged into new languages that attempt to be "the best of". I expect to see convergence of languages over time, not divergence.

Also, I feel like your Interactive Window discussion is requesting a more universal and dynamic language for interacting with computers. To put it simply: replace computer software from other vendors with the software I told it to generate. That's a fantastic concept, but it is not at all in line with the present use of C#. That's a whole new world.

[WolfieWerewolf]

Brannon...thanks for the thoughtful response. I appreciate that and agree, for the majority of use cases it's probably best to deep dive one language and do it incredibly well... I suspect my environment is unique so I grab the tool that does the job quickly at the time and move on. My world is iterative and constantly changing...just because I want to write software that I can refractor at runtime doesn't mean everyone else wants or needs that... Hell I don't even consider myself a software developer. Compared to you guys I feel like a complete amateur.. thanks again for taking the time to respond... great answer.

Best Regards

/W

Brannon King notifications@github.com wrote:

I recognize that many programmers work in multiple languages on a given day, but I don't consider that to be ideal. I want each member of my team to have a thorough and deep understanding of the language they are working in, which is easier without having to write code in multiple languages. (Yes, if you can make WPF puke you're doing better than me; it usually fails silently.) I recognize that many programming languages have arisen to fill a space that was difficult to approach from some other language or to explore a new form/idea. I think that's great, but I can also see those ideas being taken and merged into new languages that attempt to be "the best of". I expect to see convergence of languages over time, not divergence.

Also, I feel like your Interactive Window discussion is requesting a more universal and dynamic language for interacting with computers. To put it simply: replace computer software from other vendors with the software I told it to generate. That's a fantastic concept, but it is not at all in line with the present use of C#. That's a whole new world.

---

Reply to this email directly or view it on GitHub: https://github.com/dotnet/roslyn/issues/1798#issuecomment-89855102

[HaloFour]

I think taking this approach is entirely wrong. It's great to look at what other languages do well and to consider how those features would improve on the C# language, but this isn't a competition. We don't want "the one true language" because all languages have intentional differentiation. C# is not a functional language and will never be on par with real functional languages. Nor is it an unmanaged systems language and it will never be on par with real systems languages. If anything I'd prefer to see better integration between languages, and not just those that target the CLR, so that the appropriate tool can be considered for the job.

That said, there are numerous potential enhancements listed above that should be (and generally are) under consideration as proposals, some of which are being championed by the C# team. Some of the other features could not really be done "right" in C# without additional changes made by the CLR team.

[svick]

@HaloFour

If anything I'd prefer to see better integration between languages, and not just those that target the CLR, so that the appropriate tool can be considered for the job.

When it was first announced, I was hoping WinRT could be that. That you could write your library in one language (CLR-based or not) and then easily consume it from another language. But it seems WinRT is pretty much meant only for WIndows Store apps (and even if it wasn't, being COM-based probably ties it pretty strongly to Windows).

I think a similar approach could make sense, but it would require a lot of work.

[MattGertz]

HaloFour's response is very much along the lines with how we've tended to think of language coverage onsite. Although the notion of competition is unavoidable at some level, I personally think of each language as a tool that's probably very good for certain things, pretty good at other things, and perhaps not the right tool for yet other areas -- in much the same way that my workshop at home is filled with various variations of somewhat specialized hardware tools.

Within the past few weeks, I've been doing exercises a number of languages to remind myself of their various strengths -- this has included the ones we own (VB, C#, F#) as well as Python and C++, and even a bit of assembly work which I like to do periodically as it gives me a bit of perspective on what you can really achieve if you've got full power. It turns out that I'm not finding much in the way of surprises, but rather reinforcing my own view that integration between languages is a Good Thing, rather than converging languages. Python, for example, has an elegance in dealing with slices that I really like, which is very useful for understanding string content; pattern matching in F# is very powerful and so very amenable to understanding arbitrary data (I particularly love mixing pattern matching and recursion in F#, which is hugely powerful); VB has a very nice clarity in syntax which I personally think is underappreciated by hardcore coders; C# is very hard to beat for focused imperative coding given its broad applicability; and of course C++ simply provides a lot of raw power. But I wouldn't necessarily converge any of them too much (though VB and C# obviously overlap by design on power, for example). We may "borrow" ideas where it makes sense to do so, of course.

This is not to shut down the conversation by any means, I love these sorts of discussions because they do highlight the issues that we should consider converging on.

[dsaf]

Sounds like making C# more like Scala. I wholeheartedly agree :). F# with a human-friendly syntax is all I want.

[gafter]

@BrannonKing I hope this discussion was useful in refining your ideas. Unfortunately it isn't actionable in this form. If you feel there are items from this wishlist that we should pursue, please open issues with specific proposals.

[WolfieWerewolf]

It's all good my man. I've been developing this idea ever since we discussed it. If you guys aren't in a position to take this forward it smells like opportunity to me :-)

[gafter]

@WolfieWerewolf Well, we're working on multiple return values, covariant return types, and less verbosity with tuples as likely things for C# 7 (thanks for the ideas). Some of the others require more work to turn into a concrete proposal.

[WolfieWerewolf]

I appreciate you keeping in contact. Please let me know how I can help, I'm all about collaborating with you guys. Ever since MS decided to open source this stuff it's been a lot easier to embrace .NET. And I have to say it's the best thing since sliced bread :-)