На чём удобнее писать большие проекты - C++ или Python?

[awua]

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

[serzh-z]

Имхо, без разницы, если писать слабосвязанные модули, держа в уме то, что соседний модуль может быть изменён/переписан/переиспользован другим участником команды.

[Ism]

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

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

Если требуется быстродействие, то С++, если удобство , то Lazarus (pascal), а python вещь довольно специфическая.

И вообще надо выбирать не язык, а набор технологий разработки

[watashiwa_daredeska]

если удобство , то Lazarus, а python вещь довольно специфическая.

/me Судорожно ищет челюсть под столом
Не припомню ни одного проекта на Lazarus, в отличие от Python. Так что, я бы сказал ровно наоборот: Lazarus — маргинальная среда для недобитых Дельфистов, а Python — достаточно популярный скриптовый язык общего назначения.

надо выбирать не язык, а набор технологий разработки

Язык — одна из «технологий разработки», что бы это ни значило :)

Какой язык лучше подходит именно для больших проектов?

Как правило, никакой. В большом проекте, как правило, используются несколько ЯП, на то он и большой.

Еще одна характеристика большого проекта: большая команда разработчиков. Если в этом случае использовать Python, то нужна железная дисциплина: документирование каждой (КАЖДОЙ!) функции, класса, переменной, обязателен TDD и пр. Ибо иначе, в отсутствие компиляции и статической типизации, начнется полный непочиняемый бардак. C++ требует хотя бы типы правильно проставлять и использовать. С непривычки тут тоже можно косяков наделать (в основном, эти косяки доставят немало головной боли на этапе разработки, а не пользователям при использовании ПО), но если не пытаться бороться со статической типизацией, то можно извлечь из нее некоторую пользу.

[Ism]

/me Судорожно ищет челюсть под столом
Не припомню ни одного проекта на Lazarus, в отличие от Python. Так что, я бы сказал ровно наоборот: Lazarus — маргинальная среда для недобитых Дельфистов, а Python — достаточно популярный скриптовый язык общего назначения.

Да , да, я маргинал. Более удобной среды для кроссплатформенной разработки вы не найдете, упор именно на скорость разработки. Lazarus прост как топор и совместим с Delphi

Если вам удобно писать базы данных на python , тетрис в помощь

[NickLion]

Ism, а Вы пишете БД на Lazarus? И что вообще понимать под "писать БД"? Написание СУБД? Или имеется в виду просто работа с БД? В любом случае такие языки как Pascal, Python, C++ не имеют встроенной поддержки работы с БД (это не SQL, xBase, FoxPro). Работа ведётся через библиотеки. Не знаю как для Python, а для Perl есть вполне удобоваримые библиотеки для работы с БД. Впрочем, Python достаточно известный язык, чтобы такие библиотеки там были. Для C++ есть такая библиотека как Qt - замечательный кроссплатформенный фреймворк, в том числе там есть работа с БД. Для разработки - среда QtCreator (для любителей - Eclipse, KDevelop и даже VisualStudio под оффтопик). В чём преимущество Pascal/Lazarus?

[NickLion]

Добавлю по теме: проект пишется на том языке, который лучше подходит для данной задачи и который лучше знают разработчики. Чаще всего на сегодня в больших проектах используются Java, C, C++, PHP. Потом уже всякие C#, Python, Perl.

[Brainsburn]

Если требуется быстродействие, то С++, если удобство , то Lazarus (pascal), а python вещь довольно специфическая.

Спасибо, теперь я знаю, что люди в этом мире бывают разные. Очень разные

Да , да, я маргинал. Более удобной среды для кроссплатформенной разработки вы не найдете, упор именно на скорость разработки. Lazarus прост как топор и совместим с Delphi

Если вам удобно писать базы данных на python , тетрис в помощь

Ничего не понял, какая разница, откуда юзать SQL? Во всех языках необходимые библиотеки есть.

У пайтона есть два плюса, которые мне очень нравятся:
1) Удобочитаемость - хорошо поможет, когда вы будете разбираться в чужом коде или работать с большими проектами (сам с такими не работал, поэтому могу ошибаться);
2) Идеология "для одной задачи - одно решение". Польза тут такая же, как и в первом пункте.

[sash-kan]

обязателен TDD

о! всё хочу вопрос задать, а никак руки не доходят·
вот что-то в голове у меня не укладывается: как применить практику tdd для разработки клиент-серверного взаимодействия? ну, веб-сервиса, допустим…
понятно, как отдельные функции писать с применением этой практики, но совершенно непонятно, как реализовывать само взаимодействие клиента и сервера·

[NickLion]

У пайтона есть два плюса, которые мне очень нравятся:
1) Удобочитаемость - хорошо поможет, когда вы будете разбираться в чужом коде или работать с большими проектами (сам с такими не работал, поэтому могу ошибаться);
2) Идеология "для одной задачи - одно решение". Польза тут такая же, как и в первом пункте.

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

[Ism]

Ничего не понял, какая разница, откуда юзать SQL? Во всех языках необходимые библиотеки есть.

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

[Brainsburn]

У пайтона есть два плюса, которые мне очень нравятся:
1) Удобочитаемость - хорошо поможет, когда вы будете разбираться в чужом коде или работать с большими проектами (сам с такими не работал, поэтому могу ошибаться);
2) Идеология "для одной задачи - одно решение". Польза тут такая же, как и в первом пункте.

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

Я хотел упомянуть о перл, но почему-то не стал. Мог бы поспорить с вами по поводу принудительных отступов, но лень) Вообще, хорошее оружие - то, которое удобно лежит в руке

[NickLion]

Brainsburn, я не спора ради, а к тому, что каждому своё :)

Вообще, хорошее оружие - то, которое удобно лежит в руке

Вот тут полностью согласен.

[nickm]

вот что-то в голове у меня не укладывается: как применить практику tdd для разработки клиент-серверного взаимодействия? ну, веб-сервиса, допустим…

Найти вумных рубистов и помучать. Они на всяких tdd/bdd двинутые

[watashiwa_daredeska]

Более удобной среды для кроссплатформенной разработки вы не найдете, упор именно на скорость разработки. Lazarus прост как топор и совместим с Delphi

Во-первых, обычно, полноценная кроссплатформенная разработка не нужна. Достаточно кроссплатформенного конечного результата. Во-вторых, более удобной среды разработки, чем *nix, я еще не видел. В-третьих, не знаю, как Lazarus, а Delphi проста, пока всё укладывается в «кинуть 3 контрола на формочку и мышкой их связать». Как только появляется задача, которая не совсем решается готовыми контролами и компонентами — начитается brainfucking. В Delphi доходило до WinAPI, который весьма не кроссплатформенный.

Если вам удобно писать базы данных на python

В природе водится несколько pure-python DB engine'ов, начиная от входящего в стандартную библиотеку shelve, до buzhug и ODB, а вот действующего движка на Pascal я что-то не знаю. Относительно же использования внешних DB, аналоги многочисленных O/R Mapper'ов мне в Pascal/Delphi/Lazarus вообще не известны. Это во-первых.
Во-вторых, «базами данных» спектр больших проектов далеко не исчерпывается.

[watashiwa_daredeska]

понятно, как отдельные функции писать с применением этой практики, но совершенно непонятно, как реализовывать само взаимодействие клиента и сервера·

Ну, в настоящих unit test'ах никакого взаимодействия клиента и сервера нет. Тестируется либо серверная часть, либо клиентская, а вместо ответной части делается «заглушка» (mock, fake и пр.). Для этого, естественно, нужно соответствующим образом дизайнить программу. Но даже в этом случае unit test'ы не покрывают 100% кода.
Можно использовать integration test'ы: поднимать почти настоящий, но тестовый сервер и гонять почти настоящих, но тестовых клиентов. Эти тесты, обычно, выполняются существенно дольше, поэтому их гоняют не непосредственно сами разработчики перед коммитом, а какой-нибудь continuous integration server, который автоматически собирает и тестирует всё, что валится в репозиторий, и в случае проблем рассылает матерные письма (в зависимости от разумности: либо всем, либо потенциальным виновникам факапа).

[Ism]

Как только появляется задача, которая не совсем решается готовыми контролами и компонентами — начитается brainfucking. В Delphi доходило до WinAPI, который весьма не кроссплатформенный.

95 процентов работы именно кинуть контролы и мышкой связать. Так что все в порядке

И ничего не мешает использовать ifdef, реализуя делая одну и туже функцию средствами разных платформ

[watashiwa_daredeska]

95 процентов работы именно кинуть контролы и мышкой связать. Так что все в порядке

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

[awua]

Чаще всего на сегодня в больших проектах используются ... PHP.

Это поделие никак не подходит для удобной разработки больших проектов.

[sash-kan]

Можно использовать integration test'ы…

насколько я понимаю, это уже явно не tdd

спасибо за пояснение
я всегда подозревал, что tdd — не панацея

[NickLion]

Чаще всего на сегодня в больших проектах используются ... PHP.

Это поделие никак не подходит для удобной разработки больших проектов.

Это поделие используется для организации Web'а в больших проектах. Каким бы поделием это для Вас ни казалось. Лично я к PHP тоже не шибко положительно отношусь, во многом благодаря толпе быдло-веб-кодеров лабающих на этом языке. Но это ведь просто инструмент. И в руках тех, кто умеет им пользоваться он выполняет свои функции. Python или Perl не выглядят лучше для создания Web-приложения. Java/JSP - имхо, ещё хуже.

[watashiwa_daredeska]

насколько я понимаю, это уже явно не tdd

tdd многогранен :) Да, при собственно написании программа дизайнится так, чтобы можно было приблизиться юниттестами вплотную к взаимодействию с внешним миром. Само взаимодействие юниттестами, естественно, покрыть нельзя — его покрывают integration test'ами.

я всегда подозревал, что tdd — не панацея

Тестирование, как и всё остальное вообще, не панацея. Классическими тестами, например, довольно плохо ловятся ошибки синхронизации в многопоточных программах. Поэтому в крупных проектах всегда используют множество техник, позволяющих уменьшить число ошибок до приемлемого уровня.

[watashiwa_daredeska]

Но это ведь просто инструмент. И в руках тех, кто умеет им пользоваться он выполняет свои функции.

Честно говоря, я не встречал в природе тех, кто по настоящему умеет им пользоваться и делает это добровольно. Те, кто по настоящему умеет пользоваться PHP, умеют пользоваться и другими инструментами, и при наличии выбора обычно не выбирают PHP. Вот такой вот парадокс.

Python или Perl не выглядят лучше для создания Web-приложения. Java/JSP - имхо, ещё хуже.

Веб-приложение, это прежде всего приложение, а уже потом веб. Для написания приложений нужен инструмент, который прежде всего ориентирован на написание приложений, а не движок скриптованных шаблонов. Возможно, Python тяжело использовать для создания действительно больших проектов, но для небольших и даже средних он достаточно хорош. Java/JSP уже лучше для больших масштабов за счет множества ограничений, позволяющих большой команде легче работать совместно, но эти самые ограничения делают Java/JSP очень неудобной для маленьких проектов — слишком велики накладные расходы.
Perl… Это почти как разрабатывать веб-приложения на bash. В принципе, возможно, но выглядит как извращение :)

[awua]

Это поделие используется для организации Web'а в больших проектах.

Я не говорил, что оно не используется. Я говорил, что оно не подходит. Это шаткая конструкция из 4000+ костылей, подпорок и заплаток, названия которых не имеют никакой систематизации и растянуты по длине так, что в среднем на название функции в PHP уходит 13 символов. Нормальной поддержки UTF-8 так и нет, и неизвестно, какова она будет в v6. Писать на PHP читаемый код невероятно сложно. И если речь идёт именно об удобстве для самого разработчика - PHP ну никак не назовётся "удобным для разработки больших проектов". Сильная сторона PHP - функция include, чтобы хэдэры одинаковые в многа страниц вставлять. Больше ничего не нахожу.

http://www.bitstorm.org/edwin/en/php/

[NickLion]

Возможно, Python тяжело использовать для создания действительно больших проектов, но для небольших и даже средних он достаточно хорош.

Не припомню ни одного web-проекта на Python. В остальной сфере - Python вроде популярнее PHP - тот же Sage, к примеру, вполне крупный проект на Python.

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

У этой технологии лучше производительность и шире возможности. Когда это не нужно, то не вижу преимуществ JSP.

Я не говорил, что оно не используется. Я говорил, что оно не подходит.

Не подходил бы - не использовали бы

Писать на PHP читаемый код невероятно сложно. И если речь идёт именно об удобстве для самого разработчика - PHP ну никак не назовётся "удобным для разработки больших проектов".

Я не защищаю PHP как язык - я его не знаю даже. Но суть в том, что этот язык используется и является 4 по популярности (после Java, C, C++). Если бы всё было так уж плохо - не было бы этого. Только инерционностью это не объяснить. Есть что-то в этой технологии положительное.

[awua]

Не подходил бы - не использовали бы

Ошибаетесь. Левость технологии (технологии в широком смысле слова) никак не сокращает её популярности. Самый первый пример, который пришёл в голову - Windows. Левота Окон не замечается за её простотой для обычного пользователя. Именно пользователя, а не IT'шника. То же и с PHP. У него крайне низкий входной барьер. С таким уровнем входного барьера его даже языком программирования сложно назвать. Поэтому он и используется в вебе больше всех остальных языков - его используют непрограммисты.

Я не защищаю PHP как язык - я его не знаю даже.

Тем более, потому что я знаю. Кодил на нём ≈полгода. И теперь мне тошно от него. Я представляю, о чём говорю.

Но суть в том, что этот язык используется и является 4 по популярности (после Java, C, C++). Если бы всё было так уж плохо - не было бы этого.

См. первый пункт сего поста.

Есть что-то в этой технологии положительное.

Простота аля QBasic. Может, даже ещё проще.

[watashiwa_daredeska]

Не припомню ни одного web-проекта на Python.

savannah.nongnu.org — Python+Django. Довольно много сайтов проектов используют MoinMoin или крутятся на Trac'е.

[watashiwa_daredeska]

savannah.nongnu.org

Хм… Саванну еще не перевели на Savane…

[diesel]

Возможно, Python тяжело использовать для создания действительно больших проектов, но для небольших и даже средних он достаточно хорош.

Не припомню ни одного web-проекта на Python. В остальной сфере - Python вроде популярнее PHP - тот же Sage, к примеру, вполне крупный проект на Python.

django - достаточно популярная штука, можно посмотреть на djangosites.org адреса "web проектов". С другой стороны, python в какой-то степени приходит на замену perl, в плане "вспомогательного" языка, для всяких мейнтейнс скриптов, внутренних штук, и тому подобных компонентов, порог вхождения несколько ниже.

Писать на PHP читаемый код невероятно сложно. И если речь идёт именно об удобстве для самого разработчика - PHP ну никак не назовётся "удобным для разработки больших проектов".

Я не защищаю PHP как язык - я его не знаю даже. Но суть в том, что этот язык используется и является 4 по популярности (после Java, C, C++). Если бы всё было так уж плохо - не было бы этого. Только инерционностью это не объяснить. Есть что-то в этой технологии положительное.

программисты на COBOL до сих пор нужны, в научных вычислениях до сих пор используется Fortran, хотя, в то время, когда в ходу был COBOL и Fortran было написано гораздо меньше кода, чем, того что написано на PHP. Да и, собственно, CMS никуда не делись, и они тоже, в большинстве своем PHP - и это все дело надо поддерживать. Можно много говорить о достоинствах и недостатках PHP, но факт остается фактом - на нем уже создано столько, что в один момент это не перестроишь. А поскольку генерация PHP кодера - это дело сравнительно дешевое, то и PHP проекты продолжают генерироваться, ничего удивительного в этом нет.

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

У этой технологии лучше производительность и шире возможности. Когда это не нужно, то не вижу преимуществ JSP.

их и нет. JSP без Java внутри не имеет смысла. и даже если Java внутри, возможны варианты.

[Voral]

Это поделие никак не подходит для удобной разработки больших проектов.

ДА?!!
Пойду застрелюсь и передам всей команде в составе которой я проработал несколько лет над проектом который приносит доход и развивается до сих пор...

В прочем "удобство" - понятние очень индивидуальное