Где и когда C # и .NET Framework не могут быть подходящим инструментом?

Question

В своей жизни, не связанной с программированием, я всегда пытаюсь использовать соответствующий инструмент для работы, и я чувствую, что я делаю то же самое в своей жизни в программировании, но я обнаружил, что я выбираю C # и .NET почти для всего. Мне трудно придумать (реалистичные бизнес) потребности, которые не могут быть удовлетворены .NET и C #.

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

Я, в основном, парень на C # и .NET, так как это то, что мне удобнее всего, но я знаю немало C ++, php, VB, PowerShell, пакетных файлов и Java, а также разбираюсь в веб-технологиях (JavaScript, HTML и CSS). Но я непредубежден в этом, мой набор навыков и я ищу случаи, когда C # и .NET не являются подходящим инструментом для работы.

Я выбираю .NET и C #, потому что мне это удобно, но я ищу случаи, когда это не подходит.

Answer 1

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

Тем не менее, есть способы обойти эти проблемы, см. Здесь: http://www.windowsfordevices.com/c/a/Windows-For-Devices-Articles/Adding-Realtime-to-Windows-Embedded/

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

1) Должен работать независимо от того, для чего используется состав компонентов 2) Бизнес-уровню на самом деле все равно, как он работает

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

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

Answer 8

Лондонская фондовая биржа изначально была написана на .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 ++ http://linux.slashdot.org/story/09/10/06/1742203/London-Stock-Exchange-Rejects-NET-For-Open-Source?from=rss

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

[EDIT]

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

Answer 9

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

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