Зачем в .NET в 2014 г. строгая типизация? Зачем нужно писать Convert.ToInt32(), ToString(), Int32.Parse()?

По поводу преобразования.

Современный препроцессор кода сам определяет, что куда преобразовывать. Если в функцию, принимающую строку, передать число, то он не только видит ошибку, но и видит, что нужно преобразовать именно число и именно в строку.

Почему бы ему самому (точнее, компилятору) не делать это в MSILе, который он дает на выходе? А в коде пусть не будет этих бесконечных Convertов, ToStringов и прочего. Как в VB.NET, но еще лучше (там, если не ошибаюсь, это дело местами все-таки нужно).

По поводу типизации вообще.

C#, VB.NET, C++/CLI используют управляемый код. В чем проблема реализовать динамическую типизацию?

Объявили переменную без типа - она становится самого экономичного в плане ресурсов типа (bool, если не путаю).

Присвоили ей строку - она становится String.

Записали в нее число - она становится Integer/Float/... (смотря какое число).

Записали обратно строку - снова String.

Передали в функцию, которая на входе принимает не строку, а число - попытались преобразовать ее в число - не получилось - выдали необработанное исключение.

Problems?

По идее, это должно еще и экономить ОЗУ для не очень качественных кодов, ведь под каждую переменную будет отведен предельный минимум памяти.

Чтобы не было путаницы с типами для самого программиста, есть венгерское соглашение. Или можно придумать ему достойную и удобную современную замену.

И еще (уже не совсем по теме).

Почему не сделать для контролов, скажем так, "основные свойства", чтобы например вместо pictureBox1.Image можно было написать просто pictureBox1 в соответствующем контексте? Или просто textBox1 вместо textBox1.Text.

Такая практика была распространена в Visual Basic до-.NET-овской эпохи. В VB.NET ее не внедрили или отказались, и очень зря.

Где я неправ?