Wait till you get to work in some complex code bases and you'll understand why jamming all kinds of idioms into one language can become a disaster. It's a tool after all, if you know how to use it properly you don't paint yourself into a corner. However, too much flexibility can lead to many problems in larger teams. Good luck!
I don't know, what's easier to understand? Sorting a list with an IComparer instance that you have to implement in a concrete data type somewhere, or just tossing it a lambda expression? Just because it's new syntax doesn't mean it's automatically more difficult to understand the language.
I got nothing against functional programming, I embrace it. However, im stating again, shoving everything under one umbrella is bound to create a complex monster. Functional programming is actually easier to understand in F# rather than C#, the idioms do translate but clunkily. Do yourseves a favor and spend some time outside C# and you’ll come back illuminated.
Not saying C# is bad, thats what you all seem to understand though.
Yes, its all subjective, I know. But stepping out of the garden is what I’d like people to take out of this. Saying C# is the most beautiful language (like some commenter states) is true only if you haven’t dabbled in many languages. And once you do you feel stupid for having had this conviction in the first place. Ive used C# throughout my career, I don’t diss the language or the ecosystem, but other things are to be considered as well and cargoculting is a thing
Java proves that limiting language features for "simplicity" just pushes the complexity somewhere else and generally much worse.
C++ is usually taken as a language with too many features but really it just has a few very flexible features and people abused those features to do all kinds of metaprogramming. As C++ has been adding more native metaprogramming idioms it has actually been getting simpler to code in.
I appreciated Smalltalk for a while but it is simple only on the surface and once you peel below that it's extremely complicated. Simple syntax doesn't necessarily lead to simple designs.
Lisp's limited syntax allows everyone to create their own "language" and that's arguably worse than the fixed set of statements that exist in other languages. I'd even argue that Lisp is inhuman because it's brutal compared to natural languages.
This is probably why neither language is more than an intellectual curiosity. COBOL, Fortran and BASIC have also all "stood the test of time".
>I appreciated Smalltalk for a while but it is simple only on the surface and once you peel below that it's extremely complicated.
Not really. Definitely not compared to C# or Java. Smalltalk simply has more system-level code accessible to the user.
I've worked with Java environments that tried to replicate the visual programming features of Smalltalk. They were about 10X the size of a modern Smalltalk distribution (Squak or Pharo), had at least 100 times slower startup time and you still needed an external IDE to get anything "serious" done with them.
I agree with your sentiment. But writing good code is also avoiding playing "who knows more language features" between the coder and the reviewer.
I have seen a function which incorporated all new language features of that language version just because the dev could. A simple for loop would have made the same work. The reviewer failed here totally. Readability, Simplicity and consistency in the code base are a thing when reviewing.
Preventing this is a duty of the code reviewer and the team.
There may be a point where the total economic cost of newbie training exceeds the benefits of improving efficiency for the experienced. C++ arguably did that. Another problem is that people will use different languages if the learning curve grows too high.
I understand that it may cause issues to new learners, but overall, what of them do you consider bloat?