referencesource VS coffeescript

But to go deeper to .NET/CLR architecture is important too. Try to understand how it works inside. Use the source, Luke! https://source.dot.net/ https://referencesource.microsoft.com/ This source code vaults is not completed then try JetBrains dotPeek tool to look at any assembly source code.

(https://github.com/Microsoft/referencesource/blob/master/System.ServiceModel/System/ServiceModel/MessageSecurityVersion.cs; scroll down to inner classes)

List is an IList/IReadOnlyList; these interfaces do nothing that couldn't be done right inside the file itself.

https://referencesource.microsoft.com/#mscorlib/system/colle...

https://referencesource.microsoft.com/#mscorlib/system/colle...

Instead we have to go diving through the IList, which implements ICollection, which implements IEnumerable, which implements IEnumerable (again). Just because each interface is composed of another interface, doesn't mean you aren't using inheritance. You are effectively creating a custom inheritance tree through willy-nilly composition.

It is gratuitous to make this chain so deep, when the underlying code is just a handful of lines.

https://referencesource.microsoft.com/#mscorlib/system/colle...

https://referencesource.microsoft.com/#mscorlib/system/colle...

https://referencesource.microsoft.com/#mscorlib/system/colle...

----------------------------------------------------------------------------------------------------------------

The doc-strings are unnecessary. It's self-evident what most of the code does if you read it.

        // Returns an enumerator for this list with the given

The whole .net framework source code is online.

https://github.com/microsoft/referencesource/blob/master/System.Numerics/System/Numerics/Vector2.cs https://github.com/microsoft/referencesource/blob/master/System.Numerics/System/Numerics/Vector2_Intrinsics.cs

.net itself has arbitrary interfaces, ex https://github.com/microsoft/referencesource/blob/master/mscorlib/system/action.cs

Assuming if you are new to C# - start coding! And start reading https://learn.microsoft.com/en-us/dotnet/csharp/tour-of-csha...

If you are not new to C#, start building an application end-to-end/a classic n-tier application, right from using a database, Entity Framework, WebAPI, DTO, AutoMapper, and a front-end (your choice - Angular/React/Vue with TypeScript or better yet - Blazor).

You will not only understand & use dependency injection, reflection, LINQ, multi-threaded programming, generic programming, source-code generation, unit-testing - and much much more in a practical/real-world usage.

Peruse https://referencesource.microsoft.com/ once in a while.

Follow various team members of .NET Framework, C# team and the like on various social-media. https://mobile.twitter.com/i/lists/120961876

I am sure there will be who agree / disagree with the above approach and will provide more viewpoints for you to consider.

Enjoy - and strap yourself for an amazing journey or roller-coaster ride, however you want to call it!

Maybe from the source of FtpWebRequest it is possible to track what the default behaviour is.

The class is just a very limited dictionary, a library will be the same or better.

That said, there are ways to embrace the JS ecosystem without actually using JavaScript. Many popular languages have transpilers that will convert code written in that particular language into something that will run natively in a web browser (in other words, JavaScript). Even TypeScript is a language that gets transpiled into JavaScript, so it's not that outrageous of a concept, it just gets more difficult to do the further you get away from languages that don't already look like JavaScript.

As a front-end web developer, do you still use CoffeeScript or jQuery? Unlikely, as TypeScript, ES/TC39 and Babel (and the retirement of Internet Explorer thanks to @codepo8 and his EDGE team) have helped to transform JavaScript into some kind of a modern programming language.

CoffeeScript

On the other hand, companies choose React because that's where all the developers are. If you want to build something that can be maintained years from now, you better not choose the next hype train that goes straight to nowhere (remember CoffeeScript ?). You want something battle tested that has stood the test of time, where you won't have trouble finding developers to scale once you need to. And nobody ever got fired for choosing React.