Was just told I will be using C# all summer for an internship. Anyone here use C# regularly...

Was just told I will be using C# all summer for an internship. Anyone here use C# regularly? How did you learn it and what are the benefits/disadvantages of this language? Python/unix brainlet here, feeling unprepared for this.

Attached: learn_c_sharp_mac_osx_thumb800.jpg (800x450, 13K)

C# is pretty nice to use. If you want to use winforms in a cross platform way it won't work well though. It's not hard to learn so don't worry about that, and code written in C# is usually pretty easy to understand.

I use it everyday. You'll pick it up easily. It's fast enough (especially compared to Python). It's usually terse compared to Java. As for disadvantages, it's a Microsoft product and a lot of the existing code out there is written by interns.

C# itself is a nice language but Sup Forums hates it because of its ties with Microsoft.

This is all good to hear. I think I just need to pickup a book on OOP. My general lack of knowledge about interfaces, abstract classes, static/final methods are what make me the most nervous.

static means no instantiation, they're just there and you can use them without making an object first. 99% of the time static is bad, don't use it
final means it can't be overriden later
abstract classes are classes that can't be instantiated because they contain one or more pure virtual/abstract methods, basically methods that aren't implemented so you inherit from them
interfaces are just abstract classes but only contain abstract methods, nothing else

that's pretty much it. then you will probably find out about design patterns and get nervous again then you will realize you will learn them by practice when you notice there's a problem and you find a common solution for it

You spend most of your time thinking about abstractions on top of abstractionson top of abstractions on top of abstractions on top of abstractions... and so on until you're retarded mind explodes. I fucking HATE OOP and all its retarded cluskerfuckery.

Then keep it simple, dummy.

interface is just a contract - empty methods
abstract classes no one really uses any more - tend to use aux classes
static is just for methods on no instance - don't use this
final ignore just use const
don't try to be clever with c# and u be fine

Day rates are awesome obv since businesses use it

Your first lesson should be to play around with properties and learn how they work, both by using auto-implemented properties and custom implementations with logic. Practically everything in the C# ecosystem expects you to use public properties over public fields.

Not trying to argue against any of your advice, but some parts should be clarified further.
>99% of the time static is bad, don't use it
Static methods are good (provided they are purely functional and don't rely on other static fields or properties). Static classes are bad 99% of the time UNLESS they are comprised solely of static methods.
>final means it can't be overriden later
The final keyword doesn't exist in C#. All classes can be inherited unless marked with the sealed keyword. Methods can't be override unless marked with the virtual keyword (and that the virtual keyword is not combined with the sealed keyword). One of the worst language inconsistencies in C#.
>abstract classes are classes that can't be instantiated because they contain one or more pure virtual/abstract methods, basically methods that aren't implemented so you inherit from them.
Abstract classes can't be instantiated but they are not required to "contain one or more pure virtual/abstract methods".
Virtual methods are methods with implementations that can optionally be overridden by inheriting classes, while abstract methods are not implemented and must be overridden by inheriting classes.
>interfaces are just abstract classes but only contain abstract methods, nothing else
Interfaces are not classes, they are interfaces. You can not inherit from multiple classes, but you can implement multiple interfaces. Abstract classes can contain implementations, while interfaces can only contain method signatures and property definitions.

>interface is just a contract - empty methods
Default implementation
>abstract classes no one really uses any more - tend to use aux classes
True. Use interfaces instead.
>static is just for methods on no instance - don't use this
Don't listen to this. Use static if it doesn't have to be used with an instance whenever you can plus it is a bit faster than insance methods.
>final ignore just use const
Final equivalent in C# is sealed for classes and readonly for variables. Don't use const in a library unless you are 1000% sure you won't change the values because users of the library will have to recompile against the new library to get the updated values.
>don't try to be clever with c# and u be fine
Let him try and fail and finally succeed.
Not the other user.
>Static classes are bad 99% of the time UNLESS they are comprised solely of static methods.
Static classes can't have instance members.
I use these for extension methods and helpers.
>interfaces can only contain method signatures and property definitions.
Default implementation.

>Static classes can't have instance members.
Static classes can have static fields and properties, both public and private, as static classes are just singletons under the hood. You shouldn't use them unless you have a really good reason to (constants or readonly values related to reflection are two).
>Default implementation.
C# interfaces can't contain default implementations.

This is all great advice thanks everyone.

Seems the purpose of an interface is for classes to inherit the interface and then implement the methods in the interface? This seems somewhat pointless to me when you can just build two classes, but I see how it would be used.

It doesn't really have any serious disadvantages apart from not supporting SIMD and some other useful CPU instructions
But that doesn't matter in the first few years of programming

The idea behind interfaces is that you could create a class (MyClass) which contains a property (SomeProperty) of type IValueGenerator, which has one method, GenerateValue, which returns a value. You don't have to care at all about exactly how the value is generated, all you need is for it to give you a value.
Now you could create three classes, NegativeValueGenerator (which returns -7), SmallValueGenerator (which returns 2) and LargeValueGenerator (which returns 1000001), all of which implement the interface IValueGenerator.
When instantiating your MyClass, you could use any of the implementations of IValueGenerator you just created for SomeProperty, and your class will still work just fine.

It's hard to see a value in interfaces when first starting out, but they are crucial if/once you start writing tests because they let you "mock" away complex behavior while still ensuring your program still runs. So if you use an interface called IDatabaseRecordReader, you could use an implementation which actually reads data from a DB in production while using a custom implementation which simply always returns a constant string "hello" during testing.

I brought up Default Implementation because C# is supposed to get it some next version (C# 8 probably).
I really like this feature a lot.
>Seems the purpose of an interface is for classes to inherit the interface and then implement the methods in the interface? This seems somewhat pointless to me when you can just build two classes, but I see how it would be used.
Not necessarily implement but rather just 'have' it as instrcuted.
It basically ensures that these classes have these methods and properties.
Proper use cases:
>Collection
Which enables you to add objects of classes that implement these interfaces without having to inherit from an abstract class which sucks if you have to derive from another class.
>APIs
You can return Interfaces to abstract away complex classes and deny improper usage.
E.g, user send config to get an IUseful and the API return either UsefulDildo, UsefulBagina, ..etc and the user doesn't have to deal with an object type mess but rather just use the methods provided by the IUseful interface.

That makes a lot of sense, thanks for explaining it to me. Looks like microsoft also has some solid C# tutorials online.

You only needs tutorials for WPF (hard to grasp at first).
.NET framework has an amazing documentation with lots of examples.

I figured you were talking about 8.0 but considering how slowly the team seems to be moving along I'd guess it'll be at least a year until it is out. I'm looking forward a lot to default interface member implementations alongside ??= ||= &&= assignments. Still kinda meh on nullable reference types since they don't actually solve the underlying problem.

>Still kinda meh on nullable reference types since they don't actually solve the underlying problem.
Yeah not their most bright idea but it is good for now if enforced correctly in APIs though I can't see people using '?' everywhere lol

I'll do some reading before the internship. I most likely will need to build a GUI and this looks relevant to doing so.