Подтвердить что ты не робот

Python vs С#/.NET - каковы основные отличия, которые следует учитывать при использовании одного для разработки большого веб-приложения?

Моя организация в настоящее время предоставляет веб-приложение, основанное прежде всего на базе SQL Server 2005/2008, платформе Java-моделей/контроллеров и на основе ColdFusion. Мы решили перейти на более новую структуру и после внутренних исследований, а мини-проекты сузили выбор до Python и С#/. NET.

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

Пример компромисс/дифференциатор Я ищу:

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

Дополнительная информация, которая может быть полезна:

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

С python мы будем идти по маршруту Django, а с .NET мы будем использовать MVC2. Наши серверы - это серверы Windows, на которых работает IIS.

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


Я прочитал некоторые из других потоков X vs Y, связанных с этими двумя языками, и нашел их очень полезными, но хотел бы поставить Python голова к голове против .Net напрямую. Заранее благодарю за то, что позволил мне использовать ваши впечатления для этого сложного вопроса!

4b9b3361

Ответ 1

". NET" не является языком. Возможно, это Python vs. С# или Python/Django vs С#/ASP.NET(или выбрать любую "веб-страницу", которую вы хотите, есть много разных решений для Python и .NET и выбор Django или MVC2 из bat строго ограничивая более эффективные варианты). В качестве противоположности Python против ".NET": IronPython (Python "в .NET" )

Я бы подумал: комфорт для разработчиков с языком и, если они равны в Python и ".NET", тогда я бы рассмотрел время обработки для разработки и выбрал язык/ "веб-сайт", который минимизировал это (опять-таки, ему нужно не являются предыдущими ограничениями).

Хотя тестирование unit/integration является обязательным для любого [значимого] проекта, я нахожу, что статически типизированный язык (С#/F #) может значительно уменьшить количество "глупых ошибок", относящихся к типам.

Откройте игровое поле: -)

Изменить комментарий:

Затем вы просто сравниваете языки.

В этом случае С# является очень скучным императивным статически типизированным языком с OO на одном уровне/интерфейсом на основе класса (но еще несколько опрятных трюков, чем Java, что является просто безупречным каменным возрастом). Это тот же базовый тип OO, что и у Python, и исключение статического/динамического бита, оба языка сильно типизированы (механики разные, но конечный результат довольно схож по языковому спектру). На самом деле, python имеет MI, но это кажется менее приемлемым в python как использование ключевого слова "lambda", и поскольку динамический ввод python не поддерживает время компиляции для определения контрактов интерфейса/типа (есть, однако, некоторые модули, которые попробуйте предоставить это).

Если вы можете узнать/знать Python, то вы можете узнать/известный С#. Это не сдвиг парадигмы. Некоторые ключевые слова здесь, скобки там, должны сказать, какой тип вы имеете в виду там, другую базовую библиотеку... другую среду (вы должны бороться с некоторыми, чтобы перейти к REPL, но это можно сделать в VS.) Как разработчики любят/учатся/используйте это еще одна история. В то время как я раньше называл С# императивом, приятно видеть добавление некоторых "функциональных" функций, таких как расширения LINQ/IEnumerable и закрытие-без-делегатов, даже если базовый синтаксис С# очень процедурный - еще раз, довольно очень похож на python (для выражений, вложенных функций, разложения операторов/выражений).

В то время как новая "динамика" размывает линию (для нее очень редко используется - примерно во всех тех же местах, которые, возможно, приходилось возвращать к отражению в предыдущих версиях С# - это не true, но дело в том, что это вообще "неправильный путь", за исключением нескольких случаев, когда это просто "лучший/единственный способ" ), "var" - нет. То есть тип переменной "var" известен во время компиляции и не имеет ничего общего с динамической типизацией; это все типовые выводы. Некоторые языки, такие как F #/SML и Haskell, имеют гораздо более мощный вывод типа, устраняя необходимость "всех этих уродливых объявлений типа" (хотя явно аннотирование разрешенных типов или наборов типов может сделать цель более понятной), сохраняя при этом статическую типизацию.

Лично, все остальное в стороне, я бы использовал статически типизированный язык. Я не говорю С# (и я определенно не говорю Java!), Но статически типизированные языки могут нажимать ошибки типа вверху и требуют прямых явных контрактов (это большой, большой выиграй для меня). В то время как вы пропустите некоторые аккуратные динамические трюки, почти всегда есть лучший способ выполнить одно и то же действие на целевом языке - вам просто нужно думать с точки зрения этого языка и использовать отвертку для винта и молотка для Гвоздь. Например. не ожидайте, что код Python будет использоваться с использованием (ab) использования local() или global() в С# as-is.

На "стороне вниз" большинство статически типизированных языков (здесь С#) требуют явного компиляции (но это не так плохо, как это делает довольно сборки), и инструменты, подобные "REPL", не принимаются как первоклассные граждане (это первоклассный гражданин в F #/VS2010). Кроме того, если у вас есть существенная библиотека для Python/С# (и она недоступна на другом языке), это может быть решающим фактором в том, почему выбрать один язык над другим.

Ответ 2

Я написал очень полный ответ на Quora об этом: Как Python сравнивается с С#?

TL; DR

  • Ответ огромен, но (надеюсь) вполне исчерпывающий. Я программировал на С#/.NET в течение почти 10 лет, поэтому я знаю это очень хорошо. И я программирую на Python в Quora в течение ~ 7 месяцев, поэтому надеюсь, что знаю это довольно хорошо.

  • Python является победителем в: простоте обучения, кросс-платформенной разработке, доступности библиотек с открытым исходным кодом

  • С# является победителем в: стандартной библиотеке, языковых возможностях, процессе разработки и инструментах, производительности, скорости эволюции языка.
  • Грубо даже: синтаксис (Python лучше читается, С# имеет более последовательный синтаксис), принятие.

Ответ 3

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

Многозадачность очень важна в любом крупномасштабном проекте;.NET может легко справиться с этим через потоки... а также может воспользоваться преимуществами рабочих процессов в IIS (ASP.NET). CPython не предлагает истинные возможности потоковой передачи из-за GIL... блокировки, которую каждый поток должен получить перед выполнением какого-либо кода, для истинной многозадачности вам нужно использовать несколько процессов.

Когда мы размещаем приложение ASP.NET в IIS на одном рабочем процессе, ASP.NET может по-прежнему использовать потоки для одновременного обслуживания нескольких веб-запросов на разных ядрах, где CPython зависит от нескольких рабочих процессов для обеспечения параллельных вычислений на разных ядрах.

Все это приводит к большому вопросу, как мы будем размещать приложение Python/Django в окнах. Мы все знаем, что процесс forking на окнах намного дороже Linux. Поэтому идеально для размещения приложения Python/Django; Лучшая среда - это Linux, а не окна.

Если вы выберете Python, правильная среда для разработки и размещения Python будет Linux... и если вы похожи на меня, исходя из окон, выбор Python также приведет к новой кривой обучения Linux... хотя и не очень тяжело в эти дни...

Ответ 4

Основная проблема в отрасли - это динамическая природа питона. Потому что у вас есть какая-то безопасность со статическим типизированным языком.

Но теперь у нас есть современные IDE, такие как PyCharm. Они объединяют pylint и pep8 "проверку кода" и "проверку стиля" при вводе кода. Это устраняет самые глупые ошибки. Так что теперь у вас почти такая же безопасность в python.

Другое дело, если вам нужна "статическая проверка типов", делайте это самостоятельно, когда вам это нужно. Это прагматичная природа питона.

GIL - это проблема, но вы можете использовать gevent или ZMQ для создания потоков. Но работа над PyPy STM продолжается.

Python работает практически везде, и у вас есть выбор различных, в основном совместимых, сред выполнения (12 в Википедии) Список интерпретаторов Python в Википедии