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

[taaroa]

getthefacts → http://opennet.ru/opennews/art.shtml?num=32529

[watashiwa_daredeska]

несколько лет над проектом который приносит доход и развивается до сих пор...

Это экономический показатель, а не технический. Тонны дешевых некачественных товаров, созданных полурабским трудом китайских вчерашних крестьян приносят доход уже много лет, и эта индустрия развивается до сих пор.
Можете заглянуть в раздел «Поддержка форума» и почитать много «лестных» отзывов о «замечательном» продукте, на котором крутится этот форум. Причем, продукт развивается уже много лет и приносит доход.

[Voral]

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

Меня раскрыли - я китаец.

Я не скажу, что PHP лучший, но "неудобным" его не считаю. Вполне нормальный язык программирования. Если на нем дофига "недопрограммситов" чегото там накорябало - это не проблема языка. За проблемы с продуктом (с тем же форумом) надо программистов этот самый продукт разрабатывающих бить по рукам, а не на язык программирования хаять. Согласен php на тот проект выбирали не по какимто потолковым качествам куртости, правильности, лучшести языка, а по тому как конкретной команде было конкретное ТЗ реализовать.

[aumit]

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

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

Чукча писатель, а не читатель?
Брукс давно, в своей знаменитой книге, описал важность современных средств разработки.
Сейчас существует куча хороших IDE, для популярных ЯП.

[aumit]

С python/c api можно писать на C++ и Python, беря только то, что нужно.

[watashiwa_daredeska]

Меня раскрыли - я китаец.

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

Если на нем дофига "недопрограммситов" чегото там накорябало - это не проблема языка.

Проблема не в том, что куча недопрограммистов накорябала, а в том, что мало программистов пишет.

[Voral]

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

Как и восприятия за полный серьез любой фразы без смайлика

Проблема не в том, что куча недопрограммистов накорябала, а в том, что мало программистов пишет.

Да дело то не в много/мало. А в том, что если хоть одна команда во всем мире способна на php (как и на любом другом языке) поднять качественный "большой проект". Значит язык пригоден. В любом случае точно сравнить языки возможно только конкретный человек вникнув в оба языка. Если средство разработки выбирается на уровне руководителя проекта, то выбирается еще и по другим параметрам. В том числе и исходя из того какой язык уже знают программеры имеющиеся в наличии. Согласен. Если спец "знает и умеет" пару-тройку языков, то по идее написать еще на одном нет проблем была бы справка под рукой. Но все равно это дополнительное время...

Опять же что такое "большой проект"? Например (из ширпотреба) джумла? Это большой проект? Наверняка в нем есть проблемы, но исчезли бы эти проблемы если оная была бы написана на перле?

[sash-kan]

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

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

видимо, после прочтения какой-то книжки по tdd, у меня в голове сложилось (неверное?) буквальное прочтение термина — test-driven development, т.е., «сначала пишем тест, затем пишем код, который этим тестом и будет проверяться»…

[watashiwa_daredeska]

если хоть одна команда во всем мире способна на php (как и на любом другом языке) поднять качественный "большой проект". Значит язык пригоден.

Не значит. Если команда спецов смогла склепать в гараже автомобиль при помощи молотка, зубила и какой-то матери, то это не значит, что молоток, зубило и какая-то матерь — подходящие инструменты для производства автомобилей.
Кроме того, «подходящесть» меняется со временем. Полвека назад кульман, ватман и готовальня были подходящими инструментами для проектирования сложных изделий, сейчас — нет. Возможно, лет 15 назад PHP и был более-менее оправданным выбором для создания крупных веб-проектов, но сейчас появились более подходящие инструменты, которые позволяют меньшими усилиями достигать более качественного результата.

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

Ага, а вкус еды — сугубо личное дело, поэтому в ресторан надо приходить со своими рецептами и своими продуктами, а то приготовят как для всех.

Если спец "знает и умеет" пару-тройку языков, то по идее написать еще на одном нет проблем была бы справка под рукой. Но все равно это дополнительное время...

Это время может окупиться впоследствии. Как говорится: «лучше день потерять, а потом за пять минут долететь» :)

[Portnov]

sash-kan
Юнит-тесты запускаются на машине разработчика, часто той же кнопкой что и компиляция проекта, иногда тест, не проходящий юнит-тестов, не пускают в vcs. Интеграционные тесты запускаются на отдельной машине (или отдельном наборе машин, где есть возможность обеспечить и взаимодействие по сети, и всё что надо), скажем, раз в сутки, или в неделю. Чтобы покрыть одну половинку сетевого приложения тестами, пишут mock-up второй половинки (заглушку, которая ничего не делает, только предоставляет тот же интерфейс что вторая половина приложения). Так проверяется, что одна половинка работает правильно с идеальным случаем второй половинки. А проверка работы обеих половинок вместе — это уже интеграционный тест.

[Devider]

иногда тест, не проходящий юнит-тестов

Код?

[Portnov]

Devider
Да :)

Впрочем, если некий тест обрушивает другие тесты — это тоже повод задуматься :)

[sciko]

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

Не соглашусь. PHP очень популярен, а текущая ветка 5.3 весьма неплоха и довольно быстра. Поэтому чаще всего для крупных веб-проектов использование PHP даст быстрый качественный результат, но только в качестве одного из используемых языков. Например, на PHP нет движка полнотекстового поиска по БД подходящего для _крупного_ проекта. Впрочем, и на Python тоже.

У всех языков есть свой минус:
PHP -- до сих пор ОО только на половину, а о функциональных штучках приходиться только мечтать.
Python -- GIL и tail-call оптимизация
Perl -- TMTOWTDI в результате чего каждый программист в команде должен знать _все_ возможные варианты! И батарейки в комплект не входят.
C++ -- хитровывернутое недоООП + сносящие мозг неподготовленому template
Java -- полярная лисица со связью с другими ЯП + весьма нетороплива. Слава богу тут барьер вхождения достаточно высок.
Pascal/Delphi -- для некрофилов.

И опять же повторю: серебрянной пули в программировании нет.

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

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

в научных вычислениях до сих пор используется Fortran

На том же C11 или C++11 до сих пор проблемы с комплексными числами. Поэтому научной среде просто неуда податься.

[sash-kan]

watashiwa_darede...
Portnov
спасибо за информацию
буду много думать…

[NickLion]

в научных вычислениях до сих пор используется Fortran

На том же C11 или C++11 до сих пор проблемы с комплексными числами. Поэтому научной среде просто неуда податься.

А какие проблемы? Чем не подходит?

[Фантом]

На том же C11 или C++11 до сих пор проблемы с комплексными числами. Поэтому научной среде просто неуда податься.

Вообще-то в C они уже давно есть, да и собственноручная реализация большой сложности не представляет. В жизнеспобности Фортрана эта причина, если и играет роль, то очень небольшую.

[watashiwa_daredeska]

PHP -- до сих пор ОО только на половину, а о функциональных штучках приходиться только мечтать.

1. В PHP о массивах приходится только мечтать.
2. При всей якобы высокоуровневости, модульность на уровне ассемблера, как у C, даже еще хуже. Это если говорить про include() и require().
3. Глобальное пространство внешних модулей «прекрасно». Никаких тебе import/use и пр. Всё, что «подключено» к интерпретатору — уже в одной большой помойке в глобальном пространстве имен.
4. namespace'ы едва-едва прикрутили, через 15 лет. Вполне согласуется с (2) — по образу и подобию срисовано с низкоуровневого C++.
5. 1 + "1" == 2 — это неподражаемо.

Python -- GIL и tail-call оптимизация

Угу, в PHP нет проблемы с GIL, ибо threads вообще отсутствуют. В Perl потоки реализованы странным образом, на потоки не похожим, ну да ладно.
tail-call optimization отсутствует и в PHP, и в Perl (хотя, в Perl6 обещают), и в Java. В C++ лучше не полагаться на эту оптимизацию, если требуется переносимость, ибо фича нестандартная.
Так что, из минусов у Python по сравнению с PHP и Perl отступы, да и то — субъективно, ибо многим отступы нравятся, и возможно, GIL по сравнению с Perl.

Разработка приложений на PHP для меня — из разряда разработки приложений на bash.

[Aviator]

Если хотите поднять очень большой, сложный проект и не плакать потом кровавыми слезами, когда придётся продукт модернизировать, то смело выбирайте Ada. Абсолютно серьёзно, на собственном опыте.
Кстати о Пых-Пыхе. Чтобы получался вменяемый код, в голове должен быть "цербер со стальной дубинкой", который время от времени будет лупить по всем выступающим частям тела (зачем, думаю пояснять не надо). Иначе проект превращается в абсолютно вырвиглазное нечто. А если еще и документации никакая, то становится очень весело.

[Devider]

смело выбирайте Ada

Параллельно напишите десяток либ, обучите поколение разрабов...

[Aviator]

смело выбирайте Ada

Параллельно напишите десяток либ, обучите поколение разрабов...

Ada - язык для разработки больших систем с повышенными требованиями к надёжности. И либ написано на ней выше крыши, а уж насколько широко он использовался в DARPA и NASA... Есть даже RTEMS.
"Сложные проблемы требуют сложных решений." Ишбиа.

P.S. Правда в коммерческих проектах на Аде мне участвовать не довелось. Писал для себя, по направлению экспертных систем, параллельных вычислений.

[Ism]

Pascal/Delphi -- для некрофилов.

Ну это вы загнули, у него есть своя ниша.
Если так говорите, значит знаете аналогичную замену . Какую ?

[watashiwa_daredeska]

Java -- полярная лисица со связью с другими ЯП

А что, JNI как-то принципиально сложнее SWIG или рукописного биндинга в Python/Perl?

Java … весьма нетороплива.

Странно это слышать/видеть, когда Java перечислена в одной компании с PHP/Python/Perl.

Слава богу тут барьер вхождения достаточно высок.

Ну, разве что по сравнению с PHP :)

[Фантом]

смело выбирайте Ada

Параллельно напишите десяток либ, обучите поколение разрабов...

Библиотеки есть, да и обучить несложно. На самом деле главная проблема при переходе на Аду - научиться писать аккуратно (потому что иначе просто не получится - язык не даст). Но потом это быстро окупится.

[NickLion]

Pascal/Delphi -- для некрофилов.

Ну это вы загнули, у него есть своя ниша.
Если так говорите, значит знаете аналогичную замену . Какую ?

Не вижу никакой особой ниши у Pascal/Delphi. Императивный объектно-ориентированный язык со строгой типизацией. Заменяется C++ тем же. В основном на сегодня приложения на Delphi - те, которые были написаны в суровые 90-е и никто не хочет переписывать.

[sciko]

А какие проблемы? Чем не подходит?

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

1. В PHP о массивах приходится только мечтать.

По-моему вы просто жутко наелись конфет…(с)

2. При всей якобы высокоуровневости, модульность на уровне ассемблера, как у C, даже еще хуже.

Вы так говорите, как будто в этом есть что-то плохое. Да и высокоуровневость не значит обязательную поддержку модульности, ООП или ФП. Для тех целей в которых разрабатывался PHP, модульность банально не нужна.

3. Глобальное пространство внешних модулей «прекрасно».

Сносит башню? Ну что ж, бывает Тогда вам ещё добавочка: в PHP на самом деле долгое время была есть только 1 переменная-массив $GLOBALS. Всё остальное -- её члены.

4. namespace'ы едва-едва прикрутили, через 15 лет.

Вот и я говорю: "на кой?". Но разработчики повелись на ОО моду и теперь пытаются к изначально процедурному языку прикрутить ООП.

5. 1 + "1" == 2 — это неподражаемо.

Вас раздражает динамическая типизация? А утиная в Python -- нет? Крестик или трусы.

Угу, в PHP нет проблемы с GIL, ибо threads вообще отсутствуют.

Здесь разговор о том, что PHP предпочитают запускать как модуль Апача, в то время как Python как CGI. Иначе нужно писать программу на Python сразу с поддержкой WSGI. На веб-хостинге это чувствуется очень сильно.

tail-call optimization отсутствует и в PHP, и в Perl (хотя, в Perl6 обещают), и в Java.

и во многих других языках, где ФП нативно не поддерживается. Но проблема в том, что в Python ФП играет важную роль.

[sciko]

А что, JNI как-то принципиально сложнее SWIG или рукописного биндинга в Python/Perl?

JNI -- это сложность рукописного биндинга + подтекающая память SWIG + почему-то тормоза.

Странно это слышать/видеть, когда Java перечислена в одной компании с PHP/Python/Perl.

По сравнению со свежими версиями PHP, Java как не странно медленнее. Но согласен, что Python самый тормозной из всей этой компании.

Ну, разве что по сравнению с PHP

PHP:

Код: Выделить всё

Hello, world!

Python 2:

Код: Выделить всё

print "Hello, world!"

Perl:

Код: Выделить всё

print "Hello, world!\n";

C:

Код: Выделить всё

#include <stdio.h>

int main(void)
{
    printf("Hello, world\n");
    return 0;
}

C++:

Код: Выделить всё

#include <iostream>

int main()
{
    std::cout << "Hello, world!" << std::endl;
    return 0;
}

Java:

Код: Выделить всё

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, world!");
    }
}

Даже для такой простой программы в Java надо объявлять класс. Вот такой тут порог вхождения.

Ну это вы загнули, у него есть своя ниша.

О_О Поведайте нам про эту нишу!

Если так говорите, значит знаете аналогичную замену . Какую ?

Тот же С/С++ (в зависимости от версии) или тот же Fortran.

[watashiwa_daredeska]

По-моему вы просто жутко наелись конфет…(с)

В русском языке массивом принято обозначать википедия://индексный массив, а не википедия://ассоциативный массив.

[watashiwa_daredeska]

Вы так говорите, как будто в этом есть что-то плохое.

При разработке крупных проектов — да, это «что-то плохое».

Для тех целей в которых разрабатывался PHP, модульность банально не нужна.

Об этом я и говорю. PHP не разрабатывался для создания больших приложений.

Да и высокоуровневость не значит обязательную поддержку модульности, ООП или ФП.

В целом, да, но для крупных проектов модульность must have. ООП, ФП или metaprogramming — по вкусу, но очень желательны, ибо позволяют повышать уровень абстракции и снижать трудозатраты.

Сносит башню?

Как представлю себе Python packages в одном пространстве имен, так да, сносит. Особенно классно читать чужой код: откуда взялась xyz(), и где искать ее определение и документацию — загадка велика есть. А уж как радостно будет, если попадутся две библиотеки с функцией xyz — вообще словами не передать.

Но разработчики повелись на ОО моду

Пространства имен, вообще-то, к ОО не имеют ровно никакого отношения.

Вас раздражает динамическая типизация? А утиная в Python -- нет?

В Python и PHP типизация, по большому счету, одинаковая. Вот только зачем по умолчанию разрешать такие странные конструкции? Хотя, так и быть, можно считать, что "1" в PHP — частный случай множественного наследования от numeric и string, хотя и очень кривой, ибо is_numeric() возвращает 1 для числовой строки, а is_int() — нет. В Java тоже есть подобная хрень, но там всё конвертируется в строку, типа форматированного вывода для бедных — это еще как-то можно понять и принять, и такой вариант был бы гораздо логичнее в PHP, предназначенном для работы, преимущественно, с текстовыми данными.

[watashiwa_daredeska]

Даже для такой простой программы в Java надо объявлять класс.

Отлично! Входной порог Java выше на две строки кода. Не смешно.

По сравнению со свежими версиями PHP, Java как не странно медленнее.

Можно где-нибудь более достоверную инфу увидеть? А то как-то у меня совсем другие данные.

Здесь разговор о том, что PHP предпочитают запускать как модуль Апача, в то время как Python как CGI.

Ну дык… У PHP практически нет вариантов. Для Python тоже создавали модули апача, только неудобно это. При больших масштабах Apache вырождается в примитивную форкалку, которая даже разделение прав по пользователям нормально не умеет, перед которой все равно стоит какой-нибудь фронтенд, вроде nginx. Тогда все равно откатываются на FastCGI.

[sciko]

В русском языке массивом принято обозначать википедия://индексный массив, а не википедия://ассоциативный массив.

Это нисколько не мешает использовать ассоциативный массив как индексный.

В целом, да, но для крупных проектов модульность must have.

Та "модульность" которую вы хотите ни фига не must have. При желании тот же функционал можно реализовать десятками способов. В простейшем варианте префиксы. Но можно и экзотику типа обращения к функциям через переменные.

А уж как радостно будет, если попадутся две библиотеки с функцией xyz — вообще словами не передать.

Конечно, не передать. Ведь это значит, что функции названы через жопу.

ООП, ФП или metaprogramming — по вкусу, но очень желательны, ибо позволяют повышать уровень абстракции и снижать трудозатраты.

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

Пространства имен, вообще-то, к ОО не имеют ровно никакого отношения.

Ещё как имеет. Ни для процедурного, ни для функционального стиля они не имеют большого значения. А вот для ООП с его >9000 вариантами одной функции, но для разных классов...

В Python и PHP типизация, по большому счету, одинаковая.

Попробуйте одной переменной присвоить сперва целое, а потом строку. Чуствуюте разницу?

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

Ни фига не логично: PHP получает строку, сам превращает её в число, а потом обратно. В Java первую часть нужно сделать ручками.