Perl 5.12

> К сожалению, хотелось бы иногда поменьше ширину, но что поделаешь, раз влазят в 26" экран, значит и так хорошо

А вот это жесть! Серьёзно так пишите? Ужос...

> что-то наглухо распределенное с кучей индусов писать надо конечно же не на перле, с этим я согласен на 200%

Я с индусами писал как то на Питоне, тоже было весело :) Индусам вообще динамическая типизация строго противопоказана.

> Это не кое-как. Это принцип: Не занимайться оптимизацией раньше выявления проблемы.

С таким ФГМ лучше вообще не писать на Си. К оптимизации это отношение не имеет, просто дурной тон.

>> Это не кое-как. Это принцип: Не занимайться оптимизацией раньше выявления проблемы.

С таким ФГМ лучше вообще не писать на Си. К оптимизации это отношение не имеет, просто дурной тон.

С таки ФГМ лучше не писать комментарии. К обсуждению это отношение не имеет, просто дурной тон.

> Это не кое-как. Это принцип: Не занимайться оптимизацией раньше выявления проблемы.

Какая оптимизация? Это тухлая отмазка, чисто чтобы положить хер на семантические особенности языка, которым пользуешься.

Если человек хочет воспринимать конструкцию for(i = (...); i < (...); ++i), как устоявшуюся для индексного итерирования, пусть лучше делает отдельную языковую конструкцию(define'ом, ага, гг). Только потом можно будет что-нибудь говорить об оптимизации.

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

>> Это не кое-как. Это принцип: Не занимайться оптимизацией раньше выявления проблемы.

Какая оптимизация? Это тухлая отмазка, чисто чтобы положить хер на семантические особенности языка, которым пользуешься.

Если человек хочет воспринимать конструкцию for(i = (...); i < (...); ++i), как устоявшуюся для индексного итерирования, пусть лучше делает отдельную языковую конструкцию(define'ом, ага, гг). Только потом можно будет что-нибудь говорить об оптимизации.

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

Ну никак не успокоишься. Говорю же тебе для удобства рефакторинга (надеюсь слышал о таком) конструкция удобнее чем вводить переменную. По этому на период разработки необходимо оставить вызов функции.

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

А ты пишешь хню придираясь к оптимизации и забывая основу - рефакторинг.

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

Нет, не пробовал. Эффективность группы, если в ней больше двух человек, падает просто катастрофически. Вдвоём нормально, особенно, если хотя бы у одного есть представление о Best Practices, и он на начальном этапе проконтролирует стиль второго.

А вот это жесть! Серьёзно так пишите? Ужос...

На самом деле, я не занимаюсь форматированием того, что пишу, это делает Eclipse/EPIC через perltidy.

> Ну никак не успокоишься. Говорю же тебе для удобства рефакторинга (надеюсь слышал о таком) конструкция удобнее чем вводить переменную. По этому на период разработки необходимо оставить вызов функции.

Ну, естественно, на период разработки, бывает, много неизвестных. Но если заранее не подумать о трудоёмкости используемых алгоритмов, то можно сильно удивиться именно в продакшене. Когда окажется, что исправить проблему надо было «вчера».

Один из примеров: я использовал std::vector<std::string>, и всё было не плохо, пока пользователь не подсунул файл на 14 мегабайт с миллионом строк. Как думаешь, сколько RSS скушала программа на такой файл? Если я правильно помню, то 130Mb. Так что не всё так просто «для удобства рефакторинга». Сделал класс CompactStringArray, который просто выделял память размером с файл, вписывал \0 вместо переводов строк и индексировал строки в этом блобе. Такой рид-онли массив строк на этот файл кушал «всего» 20Mb.

>> Ну никак не успокоишься. Говорю же тебе для удобства рефакторинга (надеюсь слышал о таком) конструкция удобнее чем вводить переменную. По этому на период разработки необходимо оставить вызов функции.

Ну, естественно, на период разработки, бывает, много неизвестных. Но если заранее не подумать о трудоёмкости используемых алгоритмов, то можно сильно удивиться именно в продакшене. Когда окажется, что исправить проблему надо было «вчера».

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

Но в данном случае этого делать будет не надо. Компилятор сам соптимизирует.

>И? В жаве нет strlen(), можно догадаться, что речь про Си. В С++ str.size() тоже не производит вычислений.

Toll вроде как про java спрашивал, вот я и откоментил про джаву

Интересный авангард, только непонятный: зачем нужна j, когда операция s.length() и так проста?

потому я и написал «но»

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

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

> Ути пути, а вот пионэры от пайтона наверное для индустрии соль небесная, ага )

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

На перле - месиво.

Поскольку перловые ковбои постепенно отмерли и на их место приходят вменяемые люди - перл постоянно выпиливают откуда только можно.

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

После попыток использования calibre, я решил, что питоном ещё очень рано заниматься ;)

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

4.2. даже если постараться — язык не позволит.

> На перле - месиво.

только если код писали пистонисты ;)

> Поскольку перловые ковбои постепенно отмерли

у вас слишком свежая информация. «комсомольская правда» за 3716 год?)

> и на их место приходят вменяемые люди

это которые пишут на с#? ;)

> перл постоянно выпиливают откуда только можно.

а потом жалуются на ЛОРе, почему система не стартует ;)