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

Модератор: Модераторы разделов

sciko
Сообщения: 1744
Статус: Ъ-участник
ОС: Debian/Ubuntu/etc

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

Сообщение sciko »

watashiwa_darede... писал(а):
11.01.2012 14:20
Входной порог Java выше на две строки кода.
На три понятия: класс, функция main и функция-член класса. Хорошо, для C/C++ понятие функции можно убрать. Причём надо сразу рассказать и про public, и про static. А это простейший пример. Чем дальше в Java, тем толще партизаны.

watashiwa_darede... писал(а):
11.01.2012 14:20
У PHP практически нет вариантов
А вот и нет. PHP можно и через CGI, и через FastCGI. Только на хостингах это не пользуется популярностью: модуль меньше ресурсов потребляет и быстрее + мелкие ништяки.

watashiwa_darede... писал(а):
11.01.2012 14:20
Для Python тоже создавали модули апача, только неудобно это.
Естественно, неудобно, т.к. при более-менее серьёзной нагрузке GIL вешает модуль намертво. Можно через mod_wsgi, но нужно, чтобы ПО поддерживало WSGI, что уже не так весело.

watashiwa_darede... писал(а):
11.01.2012 14:20
перед которой все равно стоит какой-нибудь фронтенд, вроде nginx
Да, стоИт. Но лишь потому, что Апач вещь которая много умеет, но и много хочет ресурсов. А тот же nginx умеет гораздо меньше (привет от mod_rewrite), но и потребляет так же меньше. Поэтому nginx обрабатывает простые запросы, а Apache -- более сложные. Естественно, это всё очень упрощённо.

watashiwa_darede... писал(а):
11.01.2012 14:20
Тогда все равно откатываются на FastCGI.
В случае nginx у вас нет другого выбора ^_^ Но по производительность nginx+FastCGI примерно равны Apache+mod_php (это если вам ЧПУ не нужны).

watashiwa_darede... писал(а):
11.01.2012 14:20
Можно где-нибудь более достоверную инфу увидеть? А то как-то у меня совсем другие данные.
Достоверную? Боюсь это будет весьма проблематично, т.к. тест всё-равно будет синтетический.
Можно в качестве примера неуёмных апетитов жабы указать, что tomcat -- сразу откушивает 100 Мб памяти в то время как apache всего 10Мб.
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

sciko писал(а):
11.01.2012 14:24
Это нисколько не мешает использовать ассоциативный массив как индексный.
Мешает. Время доступа хреноватенькое, потребление памяти ни в какие ворота не лезет.

sciko писал(а):
11.01.2012 14:24
В простейшем варианте префиксы.
Это очень уж простейший вариант с кучей неудобств. Начиная от того, что namespace я могу локально сократить (а в больших проектах бывают длинные многоуровневые имена) и переименовать (import-from, import-as в Python'е, "namespace x = y" в C++) , а префикс — фиг. Это позволяет минимальной кровью подставлять вместо одних реализаций другие, совместимые по интерфейсу. Кроме того, ну ладно еще интерфейсные функции префиксами обзывать, но ведь и нормальной инкапсуляции реализации в PHP нету, а значит все внутренние функции тоже надо с префиксами писать, да еще с полными. Код будет выглядеть — удавиться можно.
Да, в C++ тоже убогонькая модульность, позаимствованная из C, но даже в C есть возможность скрыть реализацию в .c-файлах используя модификатор static и не заботясь о конфликтах имен.

sciko писал(а):
11.01.2012 14:24
Конечно, не передать. Ведь это значит, что функции названы через жопу.
А мне от этого легче, если библиотеки не мои?

sciko писал(а):
11.01.2012 14:24
Особенно снижение трудозатрат видно, когда в типичном проекте на C++ на 1 реальный класс приходиться до 10 виртуальных.
Скажу по секрету: при большой команде на написание кода тратится не так уж много времени. Так что, немножко лишнего кода погоды почти не делает.
И да, а что такое «виртуальный класс»? Виртуальные методы знаю, виртуальное наследование знаю, абстрактные методы и классы знаю, а вот этого не знаю. Может быть, 10 — не так уж много (если имелись в виду классы, сгенерированные автоматически шаблонными вычислениями)? Обычно, используется модель с 2-я классами (абстрактный интерфейс, реализация) и 3-я файлами (интерфейсный .h, внутренний .h и .cpp).

sciko писал(а):
11.01.2012 14:24
Ни для процедурного, ни для функционального стиля они не имеют большого значения.
Имеют, ибо это зависит не от парадигмы написания кода, а от масштабов команды. В большой команде обязательно более чем одному человеку придет в голову назвать разные функции каким-нибудь одним и тем же простым словом. Просто нечасто встречаются настолько большие проекты на процедурных и функциональных языках.

sciko писал(а):
11.01.2012 14:24
Попробуйте одной переменной присвоить сперва целое, а потом строку. Чуствуюте разницу?
Нет. И там, и там присваивается. А в чем подвох?

sciko писал(а):
11.01.2012 14:24
PHP получает строку, сам превращает её в число, а потом обратно.
Ладно фиг с ним, с этим превращением, все-таки из Perl'а позаимствовано, который сделан для людей, а не программистов.

sciko писал(а):
11.01.2012 15:33
Естественно, неудобно, т.к. при более-менее серьёзной нагрузке GIL вешает модуль намертво.
Простите, при чем тут GIL, если нет потоков?
Спасибо сказали:
Ism
Сообщения: 1261
Статус: Никто, по сути быдло

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

Сообщение Ism »

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


Ну Delphi и С++ Builder до сих пор прекрасно существуют. Так никто и не осветил, есть и еще системы быстрой разработки под Linux кроме Лазарус . Нет ? Тогда зачем рассуждать про 90 годы.
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

sciko писал(а):
11.01.2012 15:33
Можно в качестве примера неуёмных апетитов жабы указать, что tomcat -- сразу откушивает 100 Мб памяти в то время как apache всего 10Мб.
Бр-р-р.
1. Как производительность связана с потреблением памяти?
2. При чем тут Tomcat и Apache? Я спрашивал про Java и PHP.

sciko писал(а):
11.01.2012 15:33
Достоверную? Боюсь это будет весьма проблематично, т.к. тест всё-равно будет синтетический.
Пусть синтетический. Где? На shootout.alioth.debian.org PHP сливает по полной программе в несколько раз. И хотя там нет веб-специфичных тестов, однако не думаю, что именно в веб у Java начинаются какие-то особенные проблемы, чтобы производительность просела в разы.

sciko писал(а):
11.01.2012 15:33
это если вам ЧПУ не нужны
Мне нужны и ЧПУ, и множество приложений, изолированных по своим гадюшникам хотя бы элементарными unix permission bits.
Спасибо сказали:
sciko
Сообщения: 1744
Статус: Ъ-участник
ОС: Debian/Ubuntu/etc

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

Сообщение sciko »

watashiwa_darede... писал(а):
11.01.2012 15:41
Это позволяет минимальной кровью подставлять вместо одних реализаций другие, совместимые по интерфейсу.
PHP на это отвечает условными функциями (т.е. при одном условии объявляется одна функция, при другом -- другая). В include в конце-концов можно давать разные переменные.

watashiwa_darede... писал(а):
11.01.2012 15:41
все внутренние функции тоже надо с префиксами писать, да еще с полными.
Переменные-функции / анонимные функции.

watashiwa_darede... писал(а):
11.01.2012 15:41
Скажу по секрету: при большой команде на написание кода тратится не так уж много времени.
Неужели остальное на тестирование?

watashiwa_darede... писал(а):
11.01.2012 15:41
И да, а что такое «виртуальный класс»?
Класс, который может быть переопределён в классах-наследниках так, что конкретная реализация класса будет определяться во время исполнения. И такие классы далеко не всегда абстракные.

watashiwa_darede... писал(а):
11.01.2012 15:41
Может быть, 10 — не так уж много (если имелись в виду классы, сгенерированные автоматически шаблонными вычислениями)?
Да, нет. Это всё пишется ручками.
Я имел ввиду такую ситуацию (натянуто, но думаю понятно):
Надо описать электрон (объект A), который имеет как корпускулярные (объект B), так и волновые свойства (объект С).
Для его описания пишутся следущие классы:
AA (реалиация электрона), AB (абстрактный интерфейс)
BA (реалиация корпускулярный свойств), BB (интерфейс корпускулярный свойств)
CA (реалиация волновых свойств), CB (интерфейс волновых свойств)
Схема наследования думаю понятна.
Естественно, работать мы будем только с классом AA. Все остальные классы -- виртуальные. Как видите даже в простейшем примере 1:5.

watashiwa_darede... писал(а):
11.01.2012 15:41
Просто нечасто встречаются настолько большие проекты на процедурных и функциональных языках.
Путаете причину и следствие. ООП как раз поощеряет создание разных функций с одинаковыми именами. Например, какие варианты для геттера предложите? А для процедурных языков такие функции просто не нужны.

watashiwa_darede... писал(а):
11.01.2012 15:41
Нет. И там, и там присваивается. А в чем подвох?
Подвох в методах: Python они сразу же становятся строковыми. А в PHP они для любой переменной всегда одинаковые.

watashiwa_darede... писал(а):
11.01.2012 15:41
Простите, при чем тут GIL, если нет потоков?
А вы думаете модуль запускает 100500 интерпретаторов? Нет, интерпритатор там 1. За счёт это и выигрыш: нет необходимости грузить в память интерпретатор на каждый запрос. Чтобы не было вопросов FastCGI работает немного по другому.

watashiwa_darede... писал(а):
11.01.2012 15:52
Как производительность связана с потреблением памяти?
При нехватке памяти будет работать запускаться меньше потоков/процессов.

watashiwa_darede... писал(а):
11.01.2012 15:52
На shootout.alioth.debian.org PHP сливает по полной программе в несколько раз.
Вы видели сырцы их тестов? Так даже бешенный нуб не напишет. + Вообще непонятно, что исследуется. Короче на _достоверную_ инфу явно не тянет.
Спасибо сказали:
sciko
Сообщения: 1744
Статус: Ъ-участник
ОС: Debian/Ubuntu/etc

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

Сообщение sciko »

watashiwa_darede... писал(а):
11.01.2012 15:52
При чем тут Tomcat и Apache? Я спрашивал про Java и PHP.
Ни PHP, ни Java сами не будут работать с веб. Им нужен веб-сервер. А Java ещё и контейнер для серверлетов.

watashiwa_darede... писал(а):
11.01.2012 15:52
однако не думаю, что именно в веб у Java начинаются какие-то особенные проблемы, чтобы производительность просела в разы.
Вы сильно ошибаетесь.
Во-первых, для работы с веб одного языка Java знать мало. Надо знать его специфические расширения. И эти расширения будут кушать не только память.
Во-вторых, типичные веб-задачи на Java писать приходится долго, что увеличивает вероятность ошибки. Это вам не PHP Data Objects, тут и SQL инъекцию пропустить как два пальца ... О какой тут оптимизации можно говорить!

watashiwa_darede... писал(а):
11.01.2012 15:52
Мне нужны и ЧПУ, и множество приложений, изолированных по своим гадюшникам хотя бы элементарными unix permission bits.
Значит придётся платить процессором и памятью.



Ism писал(а):
11.01.2012 15:42
Ну Delphi и С++ Builder до сих пор прекрасно существуют
Откройте для себя Glade, например, и прекратите нам мозги ... массировать.
Спасибо сказали:
Ism
Сообщения: 1261
Статус: Никто, по сути быдло

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

Сообщение Ism »

Откройте для себя Glade, например, и прекратите нам мозги ... массировать.


Не смешите,

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

Все можно заменить одной фразой - квалификация , целесообразность
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

sciko писал(а):
11.01.2012 17:49
PHP на это отвечает условными функциями (т.е. при одном условии объявляется одна функция, при другом -- другая). В include в конце-концов можно давать разные переменные.
Для этого модули должны быть не просто совместимыми, а заведомо конфликтующими. Т.е. если у меня есть module1 и module2, в которых есть f() и g(), то по правилам эти функции должны называться как-нибудь вроде module1_f() и module1_g() в module1 и module2_f()/module2_g() в module2. А это уже разные функции, даже если я включу module2 вместо module1. Ну, вот, например, часто используемая идиома в Python:

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

try:
  import cStringIO as StringIO  # Try to import fast implementation if available
except:
  import StringIO  # Fallback to pure Python implementation

mem_file = StringIO.StringIO()  # Here we can seamlessly use either implementation we imported


sciko писал(а):
11.01.2012 17:49
Переменные-функции / анонимные функции.
Так переменным-то тоже надо префиксы приписывать, по-хорошему. А анонимные функции… Вы имеете в виду JavaScript-style?

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

(function() {
  var namespace = 'module';
  var f = function() { ... };
  window[namespace + '_f'] = f;
})();
Только через $GLOBALS вместо window?

sciko писал(а):
11.01.2012 17:49
Неужели остальное на тестирование?
На коммуникацию между разработчиками.

sciko писал(а):
11.01.2012 17:49
Надо описать электрон (объект A), который имеет как корпускулярные (объект B), так и волновые свойства (объект С).
Для его описания пишутся следущие классы:
AA (реалиация электрона), AB (абстрактный интерфейс)
BA (реалиация корпускулярный свойств), BB (интерфейс корпускулярный свойств)
CA (реалиация волновых свойств), CB (интерфейс волновых свойств)
Схема наследования думаю понятна.
Естественно, работать мы будем только с классом AA. Все остальные классы -- виртуальные.
Зачем нам BA и CA? Почему корпускулярные и волновые свойства — объекты? Объект один — электрон, остальное — интерфейсы. Итого: интерфейсы B и C (абстрактные классы), опционально абстрактный «публичный» интерфейс электрона A и реализация AA, которая наследуется от этих 2–3 интерфейсов.

sciko писал(а):
11.01.2012 17:49
Как видите даже в простейшем примере 1:5.
В этом простейшем примере нам не нужны отдельные B и C. Они нужны, когда есть другие частицы, но тогда у нас получается всего-навсего N:(N+2), а то и вовсе N:2, если не вводить специфических абстрактных интерфейсов электрона, протона, нейтрона и т.п., а оставить только общие — волновой и корпускулярный.

sciko писал(а):
11.01.2012 17:49
А для процедурных языков такие функции просто не нужны.
Да банально, даже в стандартной библиотеке C, вполне себе процедурной, есть write(), а есть fwrite() (и прочие близнецы) для разных вариантов работы с файлами. В библиотеке PostgreSQL для работы с BLOB'ами также используется file-like интерфейс со своими префиксами. И это только очевидные общеизвестные вещи. А в большом проекте в заданной предметной области лексикон может быть вполне себе ограничен, поэтому случайные конфликты имен более чем вероятны.
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

sciko писал(а):
11.01.2012 17:49
А вы думаете модуль запускает 100500 интерпретаторов? Нет, интерпритатор там 1.
Нет, по одному интерпретатору на процесс. Именно поэтому mod-php работает только в модели prefork, а в поточной — фиг.

sciko писал(а):
11.01.2012 17:49
За счёт это и выигрыш: нет необходимости грузить в память интерпретатор на каждый запрос.
Не вижу связи. Один worker (worker — процесс, а не поток) в один поток последовательно обрабатывает много запросов, поэтому нет необходимости каждый раз загружать интерпретатор. Worker'ов несколько (задается настройками апача). Потоки-то тут при чем?

sciko писал(а):
11.01.2012 17:49
Чтобы не было вопросов FastCGI работает немного по другому.
Почти также. Схем, по которым можно работать, не так уж и много, и почти все они недоступны PHP :)

sciko писал(а):
11.01.2012 17:49
При нехватке памяти будет работать запускаться меньше потоков/процессов.
Ну, в свой 32-ядерный сервер можете воткнуть чуть побольше памяти — не так уж накладно, а мне на моем 2-ядерном серверочке больше 2–4 потоков выполнения не нужно :)

sciko писал(а):
11.01.2012 17:49
Подвох в методах: Python они сразу же становятся строковыми.

Shell

>>> a=1 >>> type(a) <type 'int'> >>> a="1" >>> type(a) <type 'str'> >>> a=2 >>> type(a) <type 'int'>

Уф-ф-ф. Не пугайте меня так. Никакими строковыми они не становятся. Что присвоено, то и лежит. И в PHP, кстати, ровно так же.


sciko писал(а):
11.01.2012 17:49
Вы видели сырцы их тестов? Так даже бешенный нуб не напишет.
Напишите так, чтобы работало быстрее, они вполне принимают код от внешних контрибьюторов. Или приведите более приближенный к обсуждаемой реальности тест: на shootout'е, все-таки больше вычислительные тесты.
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

sciko писал(а):
11.01.2012 18:08
А Java ещё и контейнер для серверлетов.
Ой, ну я Вас умоляю. Сервлеты и контейнеры — это уже необязательные частности. Вполне можно писать web-приложения без всяких там Tomcat'ов и прочих EE. У нас куча таких и замечательно быстро работают. На C++, правда, еще быстрее, в основном за счет управления памятью, но их и писать сложнее.
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

sciko писал(а):
11.01.2012 18:08
Во-вторых, типичные веб-задачи на Java писать приходится долго, что увеличивает вероятность ошибки.
Ну, это может быть. У нас довольно много всего наработано, поэтому я не сильно в курсе, что там с жабой в дикой природе.

sciko писал(а):
11.01.2012 18:08
Во-первых, для работы с веб одного языка Java знать мало. Надо знать его специфические расширения.
Ой да ладно! Что там такого уж специфичного в веб? Обычные нормальные библиотеки, шаблоны и пр. Я первое приложеньице, помнится, за пару деньков состряпал, до этого на Java что-то писал >10 лет назад, да и то, почти на уровне hello-world. Элементарно там всё.

sciko писал(а):
11.01.2012 18:08
Это вам не PHP Data Objects, тут и SQL инъекцию пропустить как два пальца
Хм… А чем PDO принципиально от JDBC или JDO отличаются?
Спасибо сказали:
sciko
Сообщения: 1744
Статус: Ъ-участник
ОС: Debian/Ubuntu/etc

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

Сообщение sciko »

watashiwa_darede... писал(а):
11.01.2012 19:14
Так переменным-то тоже надо префиксы приписывать, по-хорошему.
Зачем?

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

$f = "xyz";
$f(5);//Эквивалентно xyz(5);
$f = "mno";
$f(5);//Эквивалентно mno(5);

А ещё можно массивы, структуры и т.п.

watashiwa_darede... писал(а):
11.01.2012 19:14
А анонимные функции… Вы имеете в виду JavaScript-style?
Нет, я имею ввиду

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

$greet[0] = function($name)
{
    printf("Hello %s\r\n", $name);
};

$greet[0]('World');
$greet[0]('PHP');


watashiwa_darede... писал(а):
11.01.2012 19:14
На коммуникацию между разработчиками.
Предпочитаете работать без тимлида и проектменеджера?

watashiwa_darede... писал(а):
11.01.2012 19:14
Почему корпускулярные и волновые свойства — объекты?
Потому что частица и волна принципиально разные объекты с разными характеристиками? Например, величина "длина волны" бессмыслена для частицы, но основополагающая для волны.

watashiwa_darede... писал(а):
11.01.2012 19:14
опционально абстрактный «публичный» интерфейс электрона A
Не фига не опционально. Цель интерфейса представляться или классом B, или классом C в зависимости от параметров класса A.

Про BA и CA думаю понятно.

watashiwa_darede... писал(а):
11.01.2012 19:14
Да банально, даже в стандартной библиотеке C, вполне себе процедурной, есть write(), а есть fwrite() (и прочие близнецы) для разных вариантов работы с файлами.
С каких пор POSIX C library стала входить в стандартную библиотеку C?

watashiwa_darede... писал(а):
11.01.2012 19:24
Именно поэтому mod-php работает только в модели prefork, а в поточной — фиг.
Бросьте курить эту гадость! mod-php прекрасно работает и в pre-fork, и в worker, и даже в event mpm. И вне зависимости от реализации worker, интерпритатор работает в адресном пространстве сервера. Поэтому если так же реализовать модуль для python, то GIL будет блокировать _все_ процессы/потоки (т.е. фактически общее адресное пространство). Соотвественно есть 3 варианта:
1) worker реализуется как модуль-переходник, но нужно знать формат общения (mod_wsgi)
2) worker запускается как отдельный процесс в ОС и с ним общаются как с обычным приложением, но это очень долго хотя бы потому что ОС каждый раз грузит экземпляр worker в память (CGI)
3) worker представляет из себя демона, но тут требуется опять же протокол общения (FastCGI).

Кстати, PHP не может только 1 из 3 вариантов. Но два оставшихся -- пожалуйста, только они медленнее mod_php.

watashiwa_darede... писал(а):
11.01.2012 19:24
Уф-ф-ф. Не пугайте меня так. Никакими строковыми они не становятся. Что присвоено, то и лежит. И в PHP, кстати, ровно так же.
Задайте i и k, а потом выполните операцию "+" в обоих языках. Почуствуете разницу.

watashiwa_darede... писал(а):
11.01.2012 19:24
Или приведите более приближенный к обсуждаемой реальности тест: на shootout'е, все-таки больше вычислительные тесты.
Чтобы всё честно было то с меня код на PHP, с вас -- на Java. Подойдёт?

watashiwa_darede... писал(а):
11.01.2012 19:30
Сервлеты и контейнеры — это уже необязательные частности.
Тогда многие ништяки java теряются и писать на нём становиться очень долго и неудобно. Например, одно дело rutime-компиляция, а другое дело -- сперва копиляция, а только потом запуск.

>>> Что там такого уж специфичного в веб?

Вы собираетесь писать без, например, jstl? А вы знаете толк в извращениях!

>>> А чем PDO принципиально от JDBC или JDO отличаются?

Тем же чем AbiWord отличается от ODF. Если сравнивать PDO и Hibernate, то Hibernate -- не нативная вещь + только заполняет объекты, а PDO умеет их ещё и создавать. Но это так навскидку (с Hibernate серьёзно не работал).
Спасибо сказали:
NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

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

Сообщение NickLion »

Ism писал(а):
11.01.2012 15:42
Ну Delphi и С++ Builder до сих пор прекрасно существуют. Так никто и не осветил, есть и еще системы быстрой разработки под Linux кроме Лазарус . Нет ? Тогда зачем рассуждать про 90 годы.

RAD? Да вот тот же QtCreator. На формочку накидать контролы не сложнее чем в Delphi. Система Layout'ов. Да и вообще Qt - замечательная штука.
Спасибо сказали:
Ism
Сообщения: 1261
Статус: Никто, по сути быдло

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

Сообщение Ism »

RAD? Да вот тот же QtCreator. На формочку накидать контролы не сложнее чем в Delphi. Система Layout'ов. Да и вообще Qt - замечательная штука.


Согласен, но ему не хватает удобства работы с базами данных, да и область его применения немного другая.
У Delphi и Lazarus есть один плюс, эти системы знает большинство, а что будет если вы передадите проект на QtCreator ?
Сейчас специалистов Qt мало. А Lazarus вообще не требует знания внутренностей.
Спасибо сказали:
sciko
Сообщения: 1744
Статус: Ъ-участник
ОС: Debian/Ubuntu/etc

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

Сообщение sciko »

NickLion писал(а):
12.01.2012 19:54
Да и вообще Qt - замечательная штука.
Только перегруженная. Например, у неё есть свои реализации библиотечных вещей. Я знаю почему, но от этого легче не становиться.
Да и Qt5 обещают вообще какой-то странный. Что будет делать KDE даже не представляю.

Ism писал(а):
13.01.2012 01:58
Согласен, но ему не хватает удобства работы с базами данных
Используйте тогда PHP/Python: там очень удобная работа с БД. И к ним легко привязать GTK3 и Glade.
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

sciko писал(а):
12.01.2012 17:30
watashiwa_darede... писал(а):
11.01.2012 19:14
Так переменным-то тоже надо префиксы приписывать, по-хорошему.
Зачем?

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

$f = "xyz";
$f(5);//Эквивалентно xyz(5);
$f = "mno";
$f(5);//Эквивалентно mno(5);
Затем, что в соседнем модуле тоже окажется переменная $f.

sciko писал(а):
12.01.2012 17:30
я имею ввиду

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

$greet[0] = function($name)
{
    printf("Hello %s\r\n", $name);
};

$greet[0]('World');
$greet[0]('PHP');
Ну, это почти JavaScript-style, только еще и с ужасным нечитабельным результатом. И непонятно, как это упрощает обращение к функциям внутри модуля.

sciko писал(а):
12.01.2012 17:30
watashiwa_darede... писал(а):
11.01.2012 19:14
На коммуникацию между разработчиками.
Предпочитаете работать без тимлида и проектменеджера?
И с тимлидами, и с менеджерами, но это помогает далеко не на 100%.

sciko писал(а):
12.01.2012 17:30
watashiwa_darede... писал(а):
11.01.2012 19:14
опционально абстрактный «публичный» интерфейс электрона A
Не фига не опционально. Цель интерфейса представляться или классом B, или классом C в зависимости от параметров класса A.
Для того, чтобы представляться B или C не нужен еще один промежуточный A, это может делать непосредственно сам AA.

sciko писал(а):
12.01.2012 17:30
watashiwa_darede... писал(а):
11.01.2012 19:14
Почему корпускулярные и волновые свойства — объекты?
Потому что частица и волна принципиально разные объекты с разными характеристиками?
Э-э-э… Так мы далеко уедем. Тему ОО дизайна предлагаю закрыть. В целом, я понял, откуда берутся 10 классов там, где достаточно 3.

sciko писал(а):
12.01.2012 17:30
С каких пор POSIX C library стала входить в стандартную библиотеку C?
Пусть будет "в стандартной библиотеке POSIX", это как-то меняет суть сказанного?
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

sciko писал(а):
12.01.2012 17:30
И вне зависимости от реализации worker, интерпритатор работает в адресном пространстве сервера. Поэтому если так же реализовать модуль для python, то GIL будет блокировать _все_ процессы/потоки (т.е. фактически общее адресное пространство).
Вот уж что-что, а процессы он точно блокировать не будет :) Если имеются в виду thread-safe сборки PHP, то по очень многим сообщениям работают эти thread-safe из рук вон плохо в общем случае. В частных случаях, конечно, можно завести. Возможно, глючат в основном внешние приблуды, которые не потокобезопасны.

sciko писал(а):
12.01.2012 17:30
Задайте i и k, а потом выполните операцию "+" в обоих языках. Почуствуете разницу.
Ну так об этом я и говорю — PHP складывает, а Python выкидывает исключение.

sciko писал(а):
12.01.2012 17:30
Чтобы всё честно было то с меня код на PHP, с вас -- на Java. Подойдёт?
Без проблем. Только задача должна быть не сильно больше shootout'овского размера. Как-то лениво для теста GMail реализовывать :)

sciko писал(а):
12.01.2012 17:30
Тогда многие ништяки java теряются и писать на нём становиться очень долго и неудобно. Например, одно дело rutime-компиляция, а другое дело -- сперва копиляция, а только потом запуск.
А стоят ли эти ништяки затрат ресурсов, как человеческих на изучение, так и процессора/памяти при выполнении? Компиляция/запуск решается элементарным скриптом a la make && ./program. Это, кстати, приходится и в Django проделывать, хоть он и умеет подхватывать изменения на лету.

sciko писал(а):
12.01.2012 17:30
Вы собираетесь писать без, например, jstl? А вы знаете толк в извращениях!
Не только собираюсь, но и писал :)

sciko писал(а):
12.01.2012 17:30
с Hibernate серьёзно не работал
Не буду спорить, ибо ни с PDO, ни с JDO, ни с Hibernate не работал :) У нас вообще не-SQL БД и работаем мы с ними, как правило, без всяких ORM.
Спасибо сказали:
sciko
Сообщения: 1744
Статус: Ъ-участник
ОС: Debian/Ubuntu/etc

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

Сообщение sciko »

watashiwa_darede... писал(а):
13.01.2012 11:50
Затем, что в соседнем модуле тоже окажется переменная $f.
Но она же не глобальная (принцип инкупсуляции -- один из важнейших в процедурном программировании), поэтому мешаться не будет.

watashiwa_darede... писал(а):
13.01.2012 11:50
И с тимлидами, и с менеджерами, но это помогает далеко не на 100%.
Но ведь время на написание кода относится к общему времени не хуже чем 1:3. Иначе это очень плохая организация труда.

watashiwa_darede... писал(а):
13.01.2012 11:50
Для того, чтобы представляться B или C не нужен еще один промежуточный A, это может делать непосредственно сам AA.
Можно. Можно вообще в 1 класс это сделать. Но это уже не ООП будет.

Пожалуй, лучшая иллюстрация избыточности ООП -- это открытый браузер классов. Вот, например, картинка наследования части классов Qt 4 Изображение Реальные классы здесь выделены полужирным.
Спасибо сказали:
sciko
Сообщения: 1744
Статус: Ъ-участник
ОС: Debian/Ubuntu/etc

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

Сообщение sciko »

watashiwa_darede... писал(а):
13.01.2012 12:02
Вот уж что-что, а процессы он точно блокировать не будет
Будет. GIL блокирует не процессы/потоки, а доступ к памяти. Если память общая, то и блокировка будет общая.

watashiwa_darede... писал(а):
13.01.2012 12:02
Ну так об этом я и говорю — PHP складывает, а Python выкидывает исключение.
Что и значит, что у PHP -- динимическая типизация, а у Python -- утиная.

watashiwa_darede... писал(а):
13.01.2012 12:02
Без проблем. Только задача должна быть не сильно больше shootout'овского размера.
Предлагаю простейшую типовую задачку: открытая страничка, страничка с заходом по паролю, несколько страничек с частично закрытым контентом, ввод пароля и регистрация, админка, позволяющая управлять пользователями. В админку может входить только админ. Естественно, страничка должна быть одним шаблоном, а админика -- другим. Более подробно ТЗ дам чуть позже.

Так же жду предложений насчёт нагрузочных скриптов.

ЗЫ.
watashiwa_darede... писал(а):
13.01.2012 12:02
У нас вообще не-SQL БД и работаем мы с ними, как правило, без всяких ORM.
Яндекс/Гугл/Рамблер ?

ЗЫЫ.
watashiwa_darede... писал(а):
13.01.2012 11:50
Пусть будет "в стандартной библиотеке POSIX", это как-то меняет суть сказанного?
Да, нет. Только он подтвержает мою правоту.
Спасибо сказали:
NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

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

Сообщение NickLion »

Ism писал(а):
13.01.2012 01:58
Согласен, но ему не хватает удобства работы с базами данных, да и область его применения немного другая.

В чём выражается удобство работы с БД? Т.е. я искренне не понимаю чего не хватает в QSqlQuery, QSqlRecord, QSql***Model+QTableView для внутренней и GUI работы с БД.

Ism писал(а):
13.01.2012 01:58
У Delphi и Lazarus есть один плюс, эти системы знает большинство

Эм... насчёт большинства Вы наверное загнули. Я не могу скзать, что знаю эти системы. И достаточно много знакомых, кто этими системами в лучшем случае в университете пользовался, да и то не особо подробно.

sciko писал(а):
13.01.2012 11:45
NickLion писал(а):
12.01.2012 19:54
Да и вообще Qt - замечательная штука.
Только перегруженная. Например, у неё есть свои реализации библиотечных вещей. Я знаю почему, но от этого легче не становиться.

Как-то не вижу в этом перегруженности. Шаг был вполне необходимый.

sciko писал(а):
13.01.2012 11:45
Да и Qt5 обещают вообще какой-то странный. Что будет делать KDE даже не представляю.

Просто разделят на большее число модулей и всего-то. Ну, и KDE тоже будет 5 версии :)
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

sciko писал(а):
13.01.2012 12:30
Можно. … Но это уже не ООП будет.
Почему не ООП? Интерфейсы нужны, чтобы описать какой-то общий аспект разных сущностей. В данном случае такими аспектами являются: корпускулярные свойства, волновые свойства — это интерфейсы B и C. Есть ли в нашем случае у электрона какие-то дополнительные аспекты, которые нужно: 1) предоставить пользователям класса 2) являются общими с какой-то другой частицей? Если нет 2-го пункта, то дополнительный интерфейс A избыточен, специфические для непосредственно электрона свойства реализуются непосредственно в AA.
В C++ избыточный интерфейс A может потребоваться для компенсации недостатков модульной системы.

Далее, классы реализации BA и CA избыточны, если не используются повторно или не заложены в предметную область в явном виде. Собственно, B и C в данном случае, заложены в предметную область, а потому не являются «лишними». В некоторых случаях BA и CA можно совместить с B и C — сделать не «чистый» интерфейс, а включить в него и общую часть реализации.

Итого, в идеальном случае у нас N классов реализации частиц и 2 интерфейса без «лишних» классов. «Лишних» же классов в худшем случае N вспомогательных для обхода недостатков модульной системы + 2 вспомогательных класса для переиспользования реализации. Итого, даже в этом простом случае получается не 1:5, а 3:3.
Спасибо сказали:
NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

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

Сообщение NickLion »

sciko писал(а):
13.01.2012 12:30
Пожалуй, лучшая иллюстрация избыточности ООП -- это открытый браузер классов. Вот, например, картинка наследования части классов Qt 4 Изображение Реальные классы здесь выделены полужирным.

1. Что значит "реальные" классы? (неабстрактные не подходит, ибо QObject и QCoreApplication - не абстрактные)
2. И где тут избыточность? Как раз тут борьба с избыточностью - общий код для разных классов выносится в родителя и не дублируется.
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

sciko писал(а):
13.01.2012 12:57
Что и значит, что у PHP -- динимическая типизация, а у Python -- утиная.
1. Утиная — тоже динамическая. Ибо по определению при динамической типизации типы проверяются в runtime, в отличие от статической.
2. Случай со строкой и числом в PHP — сильно частный. Хеш-массив с числом уже сложить не получается, даже если в массиве всего один элемент с числовым значением.
Так что, типизация в PHP и Python совершенно одинаковая, но в PHP есть частный случай в реализации некоторых операций со строковым и числовым аргументом.
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

sciko писал(а):
13.01.2012 12:57
GIL блокирует не процессы/потоки, а доступ к памяти. Если память общая
Память у разных процессов не общая. shm — совершенно отдельная штука, и GIL ее не касается. Далее, при встраивании Python можно завести несколько интерпретаторов и выполнять их в разных потоках вполне независимо, без проблем с GIL. Однако, в этом случае есть проблемы. Насколько я понимаю, это те же проблемы, которые мешают полноценно использовать PHP в threaded MPM.

UPD: поправил ссылку, а то свою с localhost'а по недосмотру влепил :)
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

sciko писал(а):
13.01.2012 12:57
Предлагаю простейшую типовую задачку: открытая страничка, страничка с заходом по паролю, несколько страничек с частично закрытым контентом, ввод пароля и регистрация, админка, позволяющая управлять пользователями. В админку может входить только админ. Естественно, страничка должна быть одним шаблоном, а админика -- другим.
А что, собственно, тестируем-то? Зачем все эти пароли, регистрации, админы при тестировании производительности?

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

Также хотелось бы увидеть условия по применению стороннего инструментария. В частности, шаблонных движков: обязательно|опционально|запрещено|пишем оба варианта: с и без.
Спасибо сказали:
Аватара пользователя
Portnov
Модератор
Сообщения: 1786
Статус: Матёрый линуксоид
ОС: Debian testing/unstable

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

Сообщение Portnov »

Про типизацию: динамическая типизация бывает сильная и слабая. В Python сильная, в PHP — слабая.
Работа: Ubuntu 9.10
Дом: Debian testing/unstable и на всякий случай winxp в virtualbox.
Для разнообразия: моя домашняя страница -http://iportnov.ru
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

sciko писал(а):
13.01.2012 12:30
Но ведь время на написание кода относится к общему времени не хуже чем 1:3. Иначе это очень плохая организация труда.
Смотря как мерять. Я мог бы достичь и 1:~0, написав всё самостоятельно и потратив месяц. Однако, выгоднее потратить 15 рабочих часов на выяснение, что есть уже готового, чтение документации и 1 час на написание нескольких строк, итого: 1:16 если считать только меня + еще время других разработчиков, которые документировали свой код. Плюс, когда субпроектов и народу сильно много, нужно устраивать сейшены время от времени, чтобы разработчики были слегка в курсе того, что уже есть, к кому обращаться, если что, и т.п.

Portnov писал(а):
13.01.2012 14:26
В Python сильная, в PHP — слабая.
Она в обоих сильная. Но в PHP есть частный случай. Аналогию этого частного случая я могу и в Python реализовать, это не сделает типизацию слабой.
Спасибо сказали:
Аватара пользователя
diesel
Бывший модератор
Сообщения: 5989
ОС: OS X, openSuSE, ROSA, Debian

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

Сообщение diesel »

sciko писал(а):
13.01.2012 12:30
watashiwa_darede... писал(а):
13.01.2012 11:50
Для того, чтобы представляться B или C не нужен еще один промежуточный A, это может делать непосредственно сам AA.
Можно. Можно вообще в 1 класс это сделать. Но это уже не ООП будет.

c тех пор как у Вас появляется класс представляющий электрон, и вы можете "наплодить" электронов - это ООП. Все остальное - это рефакторинг для улучшения структуры, читаемости, поиск возможности плодить новые частицы минимумом кода итп итд. Создали А, который представляет собой электрон, походили/подумали, поняли что хотим чтобы волновые и корпускулярные свойства были выделены в отдельное производство(непонятно зачем, ну да ладно), создали B и C, а в A просто вынесли дергание того и другого(в этом случае "A предствляется B или C" - несколько дико, в любом случае). Походили, еще подумали, решили что А слишком зависит от реализации B и C, пусть лучше зависит от того "что мы ожидаем", выделили BA и CA, итп. С тех пор как у вас появилось (B, C) -> A можно подумать о том что в принципе: меняем B и С, и получаем другую частицу, c ((B-> BA), (C->CA))-> A - получится чище, а дальше можно еще пару тройку классов плодить, для большей чистоты эксперимента, но это уже другая история.
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

diesel писал(а):
13.01.2012 14:48
а дальше можно еще пару тройку классов плодить
Насколько я понимаю, именно это «плодить» и не нравится sciko. Мне, кстати, тоже не нравится. Модель Go мне нравится гораздо больше — меньше ненужного хлама в интерфейсах библиотек и больше гибкости при использовании.
Спасибо сказали:
Ism
Сообщения: 1261
Статус: Никто, по сути быдло

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

Сообщение Ism »

Смотрю я на поток постов, эта тема вполне тянет на занесение в FAQ :)
Такого подробного разбора языков программирования я еще не видел.
Спасибо сказали: