Где/Когда делают C# и Платформе.NET не удается быть правильным инструментом?

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

См .: https://stackoverflow.com/questions/141985/why-should-a-net-developer-learn-f

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

• На каких языках, которые вы / ваша команда уже знаете, вы можете работать продуктивно?
• Что доступно в библиотеках (встроенных или доступных из других источников) для этого языка?

Следовательно, ответ на этот вопрос будет зависеть от вас. Например, если бы я лично выполнял задачу быстрой обработки текста, я бы создал ее на Perl, потому что я хорошо знаю Perl и могу эффективно выполнять такие задачи: если бы вы попросили меня сделать это на C #, я бы сказал, что был неподходящим инструментом для меня, потому что на Perl я справлялся быстрее.

Если вы хотите изучить и разнообразить свой набор инструментов программирования - что является хорошей идеей - то вместо того, чтобы спрашивать, где C # является неправильным инструментом, вам нужно спросить, какой язык наиболее подходит для каждое задание и постарайтесь выучить этот язык лучше. В противном случае C # всегда будет для вас лучшим инструментом для любой работы.

C # и .NET - неправильное решение, если вы работаете в гетерогенной среде с множеством платформ. Для всех практических целей .NET - это решение только для Microsoft (да, я знаю о Mono и поддерживаю свое заявление), которое привязывает вас к одному поставщику и аппаратной архитектуре. Если на вашем рабочем месте есть компьютеры Mac и Linux, а также серверы SPARC, блейд-серверы PowerPC и т. Д. И т. Д., То C # /. NET не принесет вам много пользы.

У вас также есть проблема привязки к поставщику. Допустим, вы пишете серверное приложение на C # и .NET. Теперь предположим, что недавний набег на компоненты серверного уровня закончился, и серверный комплект, оснащенный ARM, ударил по рынку, как молния. Если вы используете C # /. NET для своего приложения, вас ждут, пока Microsoft не перенесет их материалы на архитектуры на базе ARM (если вообще когда-то - NT когда-то поддерживала гораздо больше архитектур, чем сейчас: тенденция к сокращению экосферы Windows , не расширяя его). Привязав себя к одной технологии конкретного поставщика, вы лишитесь возможности пережить рыночные сдвиги.

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

Это не всегда плохо, но это означает, что высокоэффективные (хотя и требующие длительного обучения) модели программирования на основе командной строки - а-ля UNIX - становятся менее используемыми, что, на мой взгляд, является позором.

Лондонская фондовая биржа изначально была написана на .NET http://blogs.computerworld.com/london_stock_exchange_suffers_net_crash

Вы можете получить проницательное представление о том, зачем использовать .NET и любые недетерминированные приложения, высвобождающие память (также известные как сборка мусора), действительно делают такие вещи, как системы реального времени, непригодными для .NET, см. следующую ссылку. Юмор - это бонус http://tech.slashdot.org/tech/08/09/08/185238.shtml

И они отказались от .NET и выбрали MilleniumIT, который использует C ++ {{1 }} http://linux.slashdot.org/story/09/10/06/1742203/London-Stock-Exchange-Rejects-NET-For-Open-Source?from=rss

Для чего-нибудь вроде объемные денежные транзакции и жизнь имеют значение (встроенное устройство для двигателя автомобиля), вы не можете позволить, чтобы просто сбор мусора включался случайным образом и непрерывно

[EDIT]

Почему голосование против, есть ли здесь какие-то обвинения Microsoft? Я просто говорю в общих чертах, в которых базовая парадигма .NET была построена (управляемая и сборщик мусора). Возможно, если я просто скажу, что .NET не может использоваться только в автомобильных двигателях и машинах, подключенных к людям (например, кардиостимулятор, диализный аппарат), я бы не получил голоса против

Я бы не стал использовать C# для приложений, которые интенсивно используют ресурсы и нуждаются в близком доступе к аппаратному обеспечению, т.е. для компьютерных игр высокого уровня.

Приложения реального времени (скажем, приложение, отслеживающее температуру на атомной станции, если, конечно, его не запускает Гомер Симпсон) были упомянуты, но не игры.

Игры мирового класса с интенсивным 3D, интенсивным IA лучше всего работают на C++ (по крайней мере, их ядро), потому что вам нужно быть ближе к процедурной парадигме и аппаратному обеспечению, и вам нужно сказать компьютеру, что и как делать, без чего-либо посередине (CLR)

вы задали интересный вопрос.

Я перефразирую это: Почему объектно-ориентированный? А почему .NET? А когда нет?

Я полагаю, что нужно иметь в виду, почему объектно-ориентированный интерфейс так популярен. В современном мире большая часть спроса на программы приходится на бизнес. Вот почему так популярны объектно-ориентированные парадигмы; Часто это самый простой способ превратить бизнес-проблему в программу. Вы в основном смотрите на бизнес, разбиваете, что такое взаимодействующие части (люди, машины, места и т. Д.), И пишете что-то, что имитирует это в коде. Итак, объектно ориентированный объект популярен, потому что он позволяет имитировать многие ситуации в реальном мире.

Я подозреваю, что .NET популярен, потому что кажется таким всеобъемлющим. С ним вы получаете множество компонентов, и все, что вы на самом деле делаете, - имитируете бизнес-задачу, создавая некую соединительную ткань между этими компонентами. Добавьте к этому тот факт, что его уже использует огромное сообщество людей, а сетевой эффект говорит в пользу .NET.

Наконец, когда вы НЕ стали бы использовать .NET?

Если ваша проблема не является бизнес-проблемой, то есть не просто проблемой подключения некоторых готовых компонентов, вам может понадобиться что-то другое.Например, если вы пишете драйвер для нового оборудования, этот драйвер на самом деле является уровнем ниже бизнес-уровня, потому что

1) Он должен работать независимо от того, какой состав компонентов используется для {{ 1}} 2) Бизнес-уровень на самом деле не заботится о том, как он работает

Существует множество проблем программирования, в которых вы бы не использовали объектно-ориентированную модель, но я подозреваю, что объектно-ориентированная модель полезна, потому что она соединяет все части (которые не t OO, как базы данных и драйверы), чтобы создать единое целое.

Недавно я посмотрел презентацию InfoQ, где Нил Форд представляет проект Thoughtworks, который выбрал Ruby on Rails вместо .NET из-за якобы лучшей гибкости Rails и Ruby. Взгляните на их точку зрения по этому вопросу.