C# replies: "Honey, I don't mind you dallying with some of those sexy other languages. Just make sure you bring some of the learnings back so you and I can enjoy them together <wink>."
I was somewhat shocked to recently realize I've been doing both C# and JavaScript since they were invented, so 15 and 20 years respectively. It's... not as awesome as I first thought.
C# has evolved greatly in 15 years. JavaScript is only just now seeing any useful change.
The C# language designers really do a great job maintaining the perfect balance of language features.
C++ allows way to many things and no normal human could ever hope to understand the entire language.
Java went too far the other way - it was so simple you ended up with a lot of boilerplate code (although this has supposedly gotten better since I last wrote much Java in Java 6).
> it was so simple you ended up with a lot of boilerplate code
Lately I've been seeing C# as having that same affliction (though not nearly to the same extent). It all started with perusing some F# code samples, then following a few tutorials, and now C# is ruined for me forever.
Shorter or less boilterplate isn't necessarily a good thing. C#'s greater explicitness can make it easier to keep track of what's going on comparatively.
Just like with features - explicitness vs conciseness is a tradeoff language designers have to walk. I feel like, in general, the C# team does a great job balancing things.
Now that MS is playing great with Linux, it's hard to justify moving away from C# for common web tasks. My biggest issue was not wanting to deploy Windows servers (for my own projects; my company pays for it without issue).
Credit is due to MS for learning to adapt to demand, not fight it.
For all the shit I give C# (some of my complaints are getting better with everything becoming open source), it's still by far my favorite language. I picked it up when Visual Studio 2008 was relatively new and coming from PHP and C++ (to ASP.Net/C#) was very eye opening and though I had a lot of learning problems because of webforms, the core C# language definitely has me captured.
C# is my "not quick one off" language. When I want a one-off, I use Ruby because it's quick and easy... but when I need more than 1 file and I'll be dealing with lots of classes and complications that come with that, give me C#.
I've tried getting to know Rust, but despite my love for it's core ideas and syntax I just can't get into it for the projects I've had. Most of my projects don't tend to be things where I care about strict memory requirements or ridiculous performance. I mainly just want something that works good enough for my own use.
I also tried Go, but I quickly left that when I found it had no generic support and the community is basically anti-functional constructs, preferring pure procedural stuff instead.
Your reference to 'more than 1 file' resonates with me. One thing C# gets wonderfully right is its approach to spreading code across multiple files. No dogmatic insistence on one class per file like Java; no file-level dependency-graph import/export nonsense; no compile order dependencies; with partial classes I can split code up logically across files if I need to. I can start off and build multiple classes all in one file to get my initial framework and patterns together, then I can refactor those classes out into their own files over time.
I recently switched to Ruby after writing C# for 8 years. There's a lot I miss, the tooling is best in class, and the language is very well thought through. I might go back some day.
Regardless of which language is better the size of the C# talent pool over the F# one would be enough of a reason for project requiring a decently sized team.
Familiar and comfortable syntax with C/C++/Obj-C/Java/Swift/Javascript/Typscript/Scala/etc... It's a procedural language, yet adopts functional elements. And the pool of developers is several orders of magnitude more. Your comment reeks of fanboyism.
> If you're in .NET land I have no idea why you would chose C# over F#.
One of our reasons: The pool of (good) developers who can write C# is already pretty small in our little city. My company has enough trouble finding developers qualified to play with C#. If we switched to F#, our already-slow hiring would grind to a halt.
A functional language is not going to be appropriate for everything, and in F# you have to explicitly do extra work to have mutable state. If you're doing a UI or game C# will probably be a more natural fit. C# probably works better with Intellisense because the types are basically always explicit, whereas you can use type inference in F#. C-style syntax is a lot more comfortable for a lot of people.
This might get downvoted and all but ... I'm not sure how someone who has written C# for 8 years would think this.
I'm not even talking complicated things. Just OO basics like interfaces and abstract classes (with compile time enforcement) are pretty helpful as you evolve a code base.
This is true, but I've seen libraries that lazily use dynamic in their API instead of properly implementing things with generics to accomplish things.
Also, the way the various Microsoft frameworks use strings to specify property and type names drives me insane. It's just like.. "Hey, we have a really nice type and generics system... but here lets hop around that and instead use strings that we hope you never need to refactor, as well as magic method names (ie, RegisterRoutes, Application_Start)". This seems to be getting a little better, but it's still way too prevalent. It's almost like the people responsible for writing C# frameworks had a disagreement over strict typing and decided to just contaminate a ton of APIs to spite the type system.
Oversimplifying things (with a little bias): JavaScript object model is Linq/delegates/reflection (the very best parts of C#) without the hassle.
IMO:
In the lower level architecture it's just more powerful designing functions and data structures to play with each other as you wish (but power is not necessarily a good thing, you can shoot yourself in the foot). You just do it, no need to define all those fancy interfaces, abstract methods, base classes...
In the higher level architecture, sure, you really miss those securities that interfaces and such enforces, JavaScript is amazingly breakable. But, fortunately, JavaScript/Node community modularizes so often (and well), that this is practically not an issue. The modules are well done, tested, there's community input, etc.
without the hassle? I've never experienced the hassle gradient favoring javascript in that regard. Here's one difference. `objects.Sum(x => x.Width)` is C#. Javascript is... `objects.map(function(x) { return x.Width; }).???`
What about returning a dynamic object? You see a method returning "object" (unless it's yours) you immediately starts to feel awkward (should I cast it to something?).
Or what if I want to check if a property exists in a dynamic object? Catch the exception? Use the ExpandoObject? Will this affect performance?
What about local delegates?
And I just won't start with reflection. Have you seem those snippets on SO? Now compare the same with JavaScript.
Don't get me wrong, I've been developing in C# for some good years in a row and I really like the language. C# traditional OO way of doing things kinda gets you by the hand when design your application. JavaScript is more on your shoulders. It's a tradeoff, you have to be more careful but you also have more power.
If you're writing idiomatic c#, using dynamic objects is rarely (never) the right thing to do. The reason dynamic exists is mostly for interop with other languages or environments.
What about local delegates? Func<int, int> localDelegate = x => x + 1;
You don't need to use reflection as often in c# as you would in javascript.
I find more and more uses for C#'s reflection all the time. I have a project that is built almost 100% on it. Tagging things with attributes, reflecting over them, slicing and dicing all of the available data in all kinds of different ways.
I can't imagine trying to do such a thing in JS, which provides so little information about exactly what I'm reflecting over. And it's so clunky. Some things you can typeof, some you have to instanceOf, such that you basically end up doing both all the time.
With JS, I know that I have a bag full of things named something. I have to do my own work from there to find out if they are methods or properties or fields. In C#, I can just ask it to give me all of the properties. Oh, but stick to just the public ones. Or skip any that have an attribute named "Exclude" tagged to them.
Yeah, I have no idea what people are talking about that JS is better for reflection. That's just bonkers.
This is how I feel about Python and Pycharm. .NET feels antiquated to me and the culture of the language (lots of former MBA guys who learned visual basic in excel as a first language) doesn't have the same spirit as Python, Ruby, or Go (or C, C++, or assembly for that matter) but to each his own.
It's mainly what its used for, if you want to make pretty graphs and keep track of materials at your factory maybe you pull out .net if you want to do something interesting you use pretty much anything else. I know tons of people make a living with it, but I don't understand the passion for the language.
It's a programming language that expresses logic. The interesting-ness of the domain is not related. You can solve any kind of interesting or uninteresting problem in any non-trivial language.
I think it very much depends on which companies you look at. There's lots of boring stuff done in .NET, but there's also some amazing stuff. The next few months are pretty exciting - I mean, just watch this: https://www.youtube.com/watch?v=Ip6wrpYFHhE
If you're stuck with a shop that transitioned from VB6 to VB.NET, then yeah, .NET sucks, because VB.NET sucks. C# is without a doubt my favorite language. I could probably live with Java, if I could use IntelliJ, although I would miss LINQ and dealing with the "one class, one file" rigidity again. I used to dabble a fair amount in Python - at the time, I was coming from working mostly in C++ or Java (1.4 or 1.5), so Python 2.5 seemed like a breath of fresh air. But the tooling is just not at the same level as exists for C# these days.
The two biggest pillars of my experience developing C# though are ReSharper and NuGet. Resharper is without a doubt the best couple hundred bucks I've spent on programming tools (if only they didn't always seem to release updates seemingly the day after my year of free point releases expires...). And Nuget is the best thing since sliced bread. I don't think I would ever want to go back to trying to manually manage and install third-party libraries the way I used to have to when I was doing Java and C++ ten years ago.
54 comments
[ 2.8 ms ] story [ 112 ms ] threadTo another 10 years!
C# has evolved greatly in 15 years. JavaScript is only just now seeing any useful change.
C++ allows way to many things and no normal human could ever hope to understand the entire language.
Java went too far the other way - it was so simple you ended up with a lot of boilerplate code (although this has supposedly gotten better since I last wrote much Java in Java 6).
C# gets the mix just right.
Lately I've been seeing C# as having that same affliction (though not nearly to the same extent). It all started with perusing some F# code samples, then following a few tutorials, and now C# is ruined for me forever.
Credit is due to MS for learning to adapt to demand, not fight it.
C# is my "not quick one off" language. When I want a one-off, I use Ruby because it's quick and easy... but when I need more than 1 file and I'll be dealing with lots of classes and complications that come with that, give me C#.
I've tried getting to know Rust, but despite my love for it's core ideas and syntax I just can't get into it for the projects I've had. Most of my projects don't tend to be things where I care about strict memory requirements or ridiculous performance. I mainly just want something that works good enough for my own use.
I also tried Go, but I quickly left that when I found it had no generic support and the community is basically anti-functional constructs, preferring pure procedural stuff instead.
For example, C# async/await is a compiler hack. In F# it was implemented as a library. This shows how powerful F# is and C# is not.
One of our reasons: The pool of (good) developers who can write C# is already pretty small in our little city. My company has enough trouble finding developers qualified to play with C#. If we switched to F#, our already-slow hiring would grind to a halt.
This might get downvoted and all but ... I'm not sure how someone who has written C# for 8 years would think this.
I'm not even talking complicated things. Just OO basics like interfaces and abstract classes (with compile time enforcement) are pretty helpful as you evolve a code base.
Also, the way the various Microsoft frameworks use strings to specify property and type names drives me insane. It's just like.. "Hey, we have a really nice type and generics system... but here lets hop around that and instead use strings that we hope you never need to refactor, as well as magic method names (ie, RegisterRoutes, Application_Start)". This seems to be getting a little better, but it's still way too prevalent. It's almost like the people responsible for writing C# frameworks had a disagreement over strict typing and decided to just contaminate a ton of APIs to spite the type system.
IMO:
In the lower level architecture it's just more powerful designing functions and data structures to play with each other as you wish (but power is not necessarily a good thing, you can shoot yourself in the foot). You just do it, no need to define all those fancy interfaces, abstract methods, base classes...
In the higher level architecture, sure, you really miss those securities that interfaces and such enforces, JavaScript is amazingly breakable. But, fortunately, JavaScript/Node community modularizes so often (and well), that this is practically not an issue. The modules are well done, tested, there's community input, etc.
Or what if I want to check if a property exists in a dynamic object? Catch the exception? Use the ExpandoObject? Will this affect performance?
What about local delegates?
And I just won't start with reflection. Have you seem those snippets on SO? Now compare the same with JavaScript.
Don't get me wrong, I've been developing in C# for some good years in a row and I really like the language. C# traditional OO way of doing things kinda gets you by the hand when design your application. JavaScript is more on your shoulders. It's a tradeoff, you have to be more careful but you also have more power.
What about local delegates? Func<int, int> localDelegate = x => x + 1;
You don't need to use reflection as often in c# as you would in javascript.
I can't imagine trying to do such a thing in JS, which provides so little information about exactly what I'm reflecting over. And it's so clunky. Some things you can typeof, some you have to instanceOf, such that you basically end up doing both all the time.
With JS, I know that I have a bag full of things named something. I have to do my own work from there to find out if they are methods or properties or fields. In C#, I can just ask it to give me all of the properties. Oh, but stick to just the public ones. Or skip any that have an attribute named "Exclude" tagged to them.
Yeah, I have no idea what people are talking about that JS is better for reflection. That's just bonkers.
The two biggest pillars of my experience developing C# though are ReSharper and NuGet. Resharper is without a doubt the best couple hundred bucks I've spent on programming tools (if only they didn't always seem to release updates seemingly the day after my year of free point releases expires...). And Nuget is the best thing since sliced bread. I don't think I would ever want to go back to trying to manually manage and install third-party libraries the way I used to have to when I was doing Java and C++ ten years ago.