Языки програмирования (скриптовые) (Кому что нравится)

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

ekkl
Сообщения: 139
ОС: 3.17.3-300.fc21.x86_64

Языки програмирования (скриптовые)

Сообщение ekkl »

Какие языки кто юзает из скриптовых, и для чего лучше тот или другой?
Например, как я вижу: PHP как язык сценариев не очень, у него другое предназначение.
А что будет удобнее для небольших, простых задач?
dd if=/dev/zero of=/dev/null bs=1M
И пусть весь мир подождет.....
Спасибо сказали:

NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: Языки програмирования (скриптовые)

Сообщение NickLion »

Дело привычки. Я Bash да Perl использую. Кто-то PHP, Python, Ruby.
Bash я обычно использую, если нужно в основном дёргать другие программы (wget, например). Если что-то более серьёзное, то Perl.

PS да, Perl можно использовать для разный вещей. Он силён регулярками, но это не единственное его предназначение. Плюс для него много дополнительных модулей есть.
Спасибо сказали:

ekkl
Сообщения: 139
ОС: 3.17.3-300.fc21.x86_64

Re: Языки програмирования (скриптовые)

Сообщение ekkl »

А как насчет "экзотики" Lua, Go, Scala?
Лично я смотрю в строну Ruby. :rolleyes:
dd if=/dev/zero of=/dev/null bs=1M
И пусть весь мир подождет.....
Спасибо сказали:

NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: Языки програмирования (скриптовые)

Сообщение NickLion »

Go можно использовать как скриптовый (go run), но всё же это компилируемый язык. Scala, ЕМНИП — делает код для JVM, т.е. тоже не скриптовый.

Lua знаю в основном популярен (был во всяком случае) среди игроделов.

Можно ещё и Node.js юзать, если JS знаете.
Спасибо сказали:

ekkl
Сообщения: 139
ОС: 3.17.3-300.fc21.x86_64

Re: Языки програмирования (скриптовые)

Сообщение ekkl »

Я так понял, что Scala для Java, это примерно то же, что и CoffeScript для JavaScript.
JS немного знаю, но почему-то не люблю. Ограничу его использование в браузере.
dd if=/dev/zero of=/dev/null bs=1M
И пусть весь мир подождет.....
Спасибо сказали:

NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: Языки програмирования (скриптовые)

Сообщение NickLion »

ekkl писал(а):
27.12.2014 23:20
Я так понял, что Scala для Java, это примерно то же, что и CoffeScript для JavaScript.

Не совсем, насколько я знаю. Scala не переводится в Java, она компилится в байт-код JVM. Это всё же отличается от CoffeeScript, который транслируется в JavaScript.
Спасибо сказали:

Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current

Re: Языки програмирования (скриптовые)

Сообщение drBatty »

ekkl писал(а):
27.12.2014 22:33
А что будет удобнее для небольших, простых задач?

что за задачи?
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:

ekkl
Сообщения: 139
ОС: 3.17.3-300.fc21.x86_64

Re: Языки програмирования (скриптовые)

Сообщение ekkl »

Напримемер,перевести из odt в tex. Это то, что нужно сейчас. Процентов на 80% уже реализовал на ruby
dd if=/dev/zero of=/dev/null bs=1M
И пусть весь мир подождет.....
Спасибо сказали:

Аватара пользователя
SLEDopit
Модератор
Сообщения: 4784
Статус: фанат консоли (=
ОС: GNU/Debian, RHEL

Re: Языки програмирования (скриптовые)

Сообщение SLEDopit »

ekkl писал(а):
28.12.2014 09:59
перевести из odt в tex
что люди не делают, лишь бы не гуглить.

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

 $ aptitude show libreoffice-writer2latex
Package: libreoffice-writer2latex
State: not installed
Version: 1.0.2-10
Priority: optional
Section: text
Maintainer: Debian LibreOffice Maintainers <debian-openoffice@lists.debian.org>
Architecture: all
Uncompressed Size: 566 k
Depends: default-jre | gcj-jre | java-gcj-compat | openjdk-6-jre | sun-java5-jre | sun-java6-jre | java5-runtime | jre, libreoffice-core (>= 1:2.3.0~oog680m1),
         libreoffice-java-common (>= 1:2.3.0~oog680m1)
Conflicts: libreoffice-common (< 1:3.0.1-10), libreoffice-common (< 1:3.0.1-10), libreoffice-core (< 1:3.0.0~), libreoffice-core (< 1:3.0.0~), ure (< 1.5.1+OOo3.1.1-15),
           ure (< 1.5.1+OOo3.1.1-15)
Enhances: libreoffice-calc, libreoffice-writer
Description: Writer/Calc to LaTeX converter extension for LibreOffice
 Writer2LaTeX is a java utility to convert OpenOffice.org/LibreOffice documents – in particular documents containing formulas – into other formats. It is actually a
 collection of four converters, i.e.:
 1) Writer2LaTeX converts documents into LaTeX 2e format for high quality
    typesetting.
 2) Writer2BibTeX extracts bibliographic data from a document and stores it in
    BibTeX format (works together with Writer2LaTeX).
 3) Writer2xhtml converts documents into XHTML 1.0 or XHTML 1.1+MathML 2.0 with
    CSS2.
 4) Calc2xhtml is a companion to Writer2xhtml that converts Calc documents
    to XHTML 1.0 with CSS2 to display your spreadsheets on the web.

 This package contains the extension providing writer2latex for LibreOffice.
Homepage: http://writer2latex.sourceforge.net

Tags: devel::lang:java, implemented-in::java, role::shared-lib

Ну и потом w2l file.odt .
UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity. © Dennis Ritchie
The more you believe you don't do mistakes, the more bugs are in your code.
Спасибо сказали:

Аватара пользователя
Yaros
Сообщения: 501
ОС: Debian Wheezy / Gentoo

Re: Языки програмирования (скриптовые)

Сообщение Yaros »

Bash, Perl, Lua.
Bash для автоматизации задач, где нужны внешние программы в количестве.
Perl для тех случаев, где более сложные алгоритмы или много регулярок - в нем удобнее.
Lua юзаю для игровых скриптов на lōve2d, хотя слышал, на нем модули nginx популярно писать в узких кругах.
=========
=Мой блог. =
=========
Gentoo-ниасилятар
Спасибо сказали:

ekkl
Сообщения: 139
ОС: 3.17.3-300.fc21.x86_64

Re: Языки програмирования (скриптовые)

Сообщение ekkl »

SLEDopit, люди гуглят. Просто это им не подошло.
Во-первых, люди набирают в Focuswriter, а там немного нет так. Отсутствуют стили, и приходится изобретать свой велосипед.
Например: имя раздела, следующая строка за ___
Каждый файл это отдельная часть,
Сгенерированные файлы подключаются через \input в главный mian.tex
Ну и т.д. И парсер практически готов
dd if=/dev/zero of=/dev/null bs=1M
И пусть весь мир подождет.....
Спасибо сказали:

Аватара пользователя
Bizdelnick
Модератор
Сообщения: 18978
Статус: ✡ иностранный агент
ОС: Debian GNU/Linux

Re: Языки програмирования (скриптовые)

Сообщение Bizdelnick »

ekkl писал(а):
28.12.2014 09:59
Напримемер,перевести из odt в tex. Это то, что нужно сейчас. Процентов на 80% уже реализовал на ruby

Если бы меня ничто из существующего не устроило, я бы делал на Perl. Во-первых, потому что я его знаю, во-вторых, потому что наверняка можно заюзать готовые модули, а не изобретать велосипед. И в-третьих, в отличие от ruby, можно не бояться, что после выхода очередной версии скрипт перестанет работать.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:

ekkl
Сообщения: 139
ОС: 3.17.3-300.fc21.x86_64

Re: Языки програмирования (скриптовые)

Сообщение ekkl »

Я уже заметил, что разработчики почему-то постоянно меняют синтаксис.Но Rails довольно мощная библиотека, поддержка немаленькая
Относительно Перла. Я слышал, что это довольно запутанный язык. программы напоминают тарелку спагетти..
--
Сам я перла не знаю, Руби начал изучать пару дней назад, когда писал программу. выбор пал почти методом тыка, Роль также сыграло то что в некоторой мере использовал некоторые gems. Тема поэтому и появилась, потому что пока не поздно пересмотреть мой выбор.
Баш не сильно нравится, и возможности, конечно, не ахти,поэтому и нужно что-то более-мене помощнее (и попроще)
ПС. Относительно модулей. В Руби они же тоже есть. Например, использовал Nokogiri для парсинга XML. Сам скрипт около 100 строк.
dd if=/dev/zero of=/dev/null bs=1M
И пусть весь мир подождет.....
Спасибо сказали:

Аватара пользователя
Bizdelnick
Модератор
Сообщения: 18978
Статус: ✡ иностранный агент
ОС: Debian GNU/Linux

Re: Языки програмирования (скриптовые)

Сообщение Bizdelnick »

ekkl писал(а):
29.12.2014 17:00
Я уже заметил, что разработчики почему-то постоянно меняют синтаксис.Но Rails довольно мощная библиотека, поддержка немаленькая

А причём тут rails? Да и не библиотека это вроде, а фреймворк.

ekkl писал(а):
29.12.2014 17:00
Относительно Перла. Я слышал, что это довольно запутанный язык. программы напоминают тарелку спагетти..

Это зависит не от языка, а исключительно от программиста. Некоторые языки борются с быдлокодом при помощи искусственных ограничений, но не Perl. Жалуются на него две категории юзеров: те, кто действительно столкнулся с криво написанным кодом, и те, кто не осилил Perl в достаточной мере, чтобы читать даже нормально написанный код, причём вторых заметно больше (порог вхождения у него, скажем так, не самый низкий).

ekkl писал(а):
29.12.2014 17:00
Баш не сильно нравится, и возможности, конечно, не ахти,поэтому и нужно что-то более-мене помощнее (и попроще)

Совсем простые вещи я пишу на POSIX shell, его возможностей вполне достаточно, если освоиться с командами. Но про некоторые редко используемые команды часто забывают, в результате чего накручивают что-то адски сложное (например используют awk там, где достаточно cut, sed там, где достаточно tr, городят конвейеры с cat file | ..., забывая, что большинство команд умеет принимать файл в виде аргумента, и т. п.).

ekkl писал(а):
29.12.2014 17:00
Относительно модулей. В Руби они же тоже есть.

Нисколько не сомневаюсь.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:

Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current

Re: Языки програмирования (скриптовые)

Сообщение drBatty »

ekkl писал(а):
29.12.2014 17:00
Относительно Перла. Я слышал, что это довольно запутанный язык. программы напоминают тарелку спагетти..

перл к этому никак не относится, быдлокод можно писать на любом ЯП.
ekkl писал(а):
29.12.2014 17:00
Сам я перла не знаю, Руби начал изучать пару дней назад

на 146% уверен, что "спагетти" напоминает ваш код на ruby.
ekkl писал(а):
29.12.2014 17:00
Баш не сильно нравится, и возможности, конечно, не ахти,поэтому и нужно что-то более-мене помощнее (и попроще)

division by zero
Bizdelnick писал(а):
29.12.2014 17:44
sed там, где достаточно tr

sed лучше, ибо умеет UTF-8. А в остальном согласен.
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:

Аватара пользователя
eddy
Сообщения: 3321
Статус: Красный глаз тролля
ОС: ArchLinux

Re: Языки програмирования (скриптовые)

Сообщение eddy »

Пользуюсь скриптами на баше. Если что-то на баше не могу реализовать, пишу на сях.
RTFM
-------
KOI8-R - патриотичная кодировка Изображение
Спасибо сказали:

ekkl
Сообщения: 139
ОС: 3.17.3-300.fc21.x86_64

Re: Языки програмирования (скриптовые)

Сообщение ekkl »

на 146% уверен, что "спагетти" напоминает ваш код на ruby.

А что, например, лучше почитать, чтобы подобного не было? Как я понял мануалы не дают опыта писать красивый код.
dd if=/dev/zero of=/dev/null bs=1M
И пусть весь мир подождет.....
Спасибо сказали:

NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: Языки програмирования (скриптовые)

Сообщение NickLion »

ekkl писал(а):
30.12.2014 11:56
А что, например, лучше почитать, чтобы подобного не было? Как я понял мануалы не дают опыта писать красивый код.

1. Читать (смотреть, разбирать, понимать) чужой код.
2. Практика (писать свой код, переписывать).

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

1-е даёт понимание, что хорошо читается, что плохо. Можно также перечитывать свой код через время и смотреть, что непонятно. И да, имхо, если непонятно без комментариев, то значит плохо.
Спасибо сказали:

Аватара пользователя
Bizdelnick
Модератор
Сообщения: 18978
Статус: ✡ иностранный агент
ОС: Debian GNU/Linux

Re: Языки програмирования (скриптовые)

Сообщение Bizdelnick »

ekkl писал(а):
30.12.2014 11:56
А что, например, лучше почитать, чтобы подобного не было? Как я понял мануалы не дают опыта писать красивый код.

На эту тему есть совершенно отдельная литература. Например, категорически рекомендую: Brian W. Kernighan, Rob Pike. The Practice of Programming. На русский, насколько мне известно, не переводилась, хотя на английском вышло уже больше 20 изданий и, казалось бы, классика-классика.
Upd. Ан нет, на русском выходила 10 лет тому, и с тех пор не переиздавалась. Так что, если с английским проблема, можно поискать по букинистам/библиотекам.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:

Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2

Re: Языки програмирования (скриптовые)

Сообщение Hephaestus »

ekkl писал(а):
30.12.2014 11:56
А что, например, лучше почитать, чтобы подобного не было?
Изучать программирование.
Не синтаксис конкретного языка, а именно программирование.
Компьютер - дура железная, сам ничего не умеет.
Решение задачи начинается у программиста в голове.
И вот если оно изначально кривое/нерациональное/неверное, то все языки будут одинаково плохи.

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

Учитывать систему счисления, в которой работает машина - в нашем случае двоичная СС - для неё можно использовать сдвиги вместо умножения/деления на числа, являющиеся степенью двойки.
Различать "тяжелые" и "легкие" операции.

Не решать задачу "в лоб" - если есть некая сложная формула/логическое выражение, не стоит в коде реализовывать его в явном виде. Лучше посмотреть, есть ли возможности упрощения этого выражения, критические точки, заведомо невозможные значения. И перестроить выражение с учётом этих условий.
А то и разбить его на несколько простых выражений, с учётом специфики.
Формула получится проще и кода будет меньше.

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


ekkl писал(а):
30.12.2014 11:56
Как я понял мануалы не дают опыта писать красивый код.
Разумеется.
Опыт Вам вообще никто не даст. Его надо нарабатывать.
Можно сколько угодно смотреть, как человек водит машину, но шофёром от этого не станешь.
Шофёром станешь не раньше, чем сам сядешь за руль и попробуешь на собственной шкуре.
С программированием то же самое.

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

Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:

Аватара пользователя
Bizdelnick
Модератор
Сообщения: 18978
Статус: ✡ иностранный агент
ОС: Debian GNU/Linux

Re: Языки програмирования (скриптовые)

Сообщение Bizdelnick »

Hephaestus писал(а):
30.12.2014 12:26
Учитывать систему счисления, в которой работает машина - в нашем случае двоичная СС - для неё можно использовать сдвиги вместо умножения/деления на числа, являющиеся степенью двойки.

С точки зрения стиля это может быть не лучшим решением. Что делает

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

a = b/2;
понятно сразу, а вот

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

a = (b >> 1);
требует напряжения мозга. Экономить тут несколько тактов есть смысл разве что в цикле, который повторяется 100500 раз, и в котором нет более ресурсоёмких вычислений.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:

Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2

Re: Языки програмирования (скриптовые)

Сообщение Hephaestus »

Bizdelnick писал(а):
30.12.2014 12:34
С точки зрения стиля это может быть не лучшим решением.
Я рассуждал без привязки к языку.

Bizdelnick писал(а):
30.12.2014 12:34
требует напряжения мозга.
Ну это уж, пардон, специфика профессии. Программист, который не напрягает мозг, ничего сложнее "Hello world" не напишет.
Понять, куда ведёт указатель в C/C++ тоже с первого взгляда нельзя, так что ж теперь, указатели не использовать?
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:

ekkl
Сообщения: 139
ОС: 3.17.3-300.fc21.x86_64

Re: Языки програмирования (скриптовые)

Сообщение ekkl »

Ну со сдвигами и т.п. я знаком, это во всех языках так.
Но, согласитесь, в каждом языке есть свои особенности и изюминки. И стиль программирования должен их учитывать.
dd if=/dev/zero of=/dev/null bs=1M
И пусть весь мир подождет.....
Спасибо сказали:

Аватара пользователя
Bizdelnick
Модератор
Сообщения: 18978
Статус: ✡ иностранный агент
ОС: Debian GNU/Linux

Re: Языки програмирования (скриптовые)

Сообщение Bizdelnick »

ekkl писал(а):
30.12.2014 13:02
согласитесь, в каждом языке есть свои особенности и изюминки. И стиль программирования должен их учитывать.

Хорошая книга по любому языку программирования (camel book в случае Perl, например) рассматривает специфические для него особенности стиля. Но без понимания общих основ от этого толку не особо много.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:

Аватара пользователя
Bizdelnick
Модератор
Сообщения: 18978
Статус: ✡ иностранный агент
ОС: Debian GNU/Linux

Re: Языки програмирования (скриптовые)

Сообщение Bizdelnick »

Hephaestus писал(а):
30.12.2014 13:01
Я рассуждал без привязки к языку.
Так я тоже. Что пример на C - ну уж извините, пришлось взять что-то конкретное для иллюстрации.

Hephaestus писал(а):
30.12.2014 13:01
Ну это уж, пардон, специфика профессии. Программист, который не напрягает мозг, ничего сложнее "Hello world" не напишет.
Понять, куда ведёт указатель в C/C++ тоже с первого взгляда нельзя, так что ж теперь, указатели не использовать?
Мозг напрягать придётся в любом случае, но когда есть возможность его поберечь и чуть больше (в разумных пределах, конечно) напрячь CPU - зачастую именно так и следует делать. Иначе, когда n месяцев спустя потребуется что-то изменить в коде, придётся потратить несколько лишних часов человеческого времени на то, чтобы вспомнить, как же код вообще работает. Притом что благодаря такой "оптимизации" за все эти n месяцев удалось сэкономить только пару миллисекунд машинного времени.
Что касается указателей - да, ими особо злоупотреблять тоже не стоит.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:

NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: Языки програмирования (скриптовые)

Сообщение NickLion »

Что касается C/C++, то все известные мне компиляторы подставляют b>>1 вместо b/2, поэтому никакой экономии не будет. Разве что используется какой-то примитивный компилятор для микроконтроллеров, но это отдельная тема, и да, там читаемость далеко не всегда на первом месте, особенно когда не хватает памяти.
Спасибо сказали:

Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2

Re: Языки програмирования (скриптовые)

Сообщение Hephaestus »

Bizdelnick писал(а):
30.12.2014 13:20
Мозг напрягать придётся в любом случае, но когда есть возможность его поберечь и чуть больше (в разумных пределах, конечно) напрячь CPU - зачастую именно так и следует делать. Иначе, когда n месяцев спустя потребуется что-то изменить в коде, придётся потратить несколько лишних часов человеческого времени на то, чтобы вспомнить, как же код вообще работает. Притом что благодаря такой "оптимизации" за все эти n месяцев удалось сэкономить только пару миллисекунд машинного времени.
Что касается указателей - да, ими особо злоупотреблять тоже не стоит.
Ну, тут уж, смотря что приоритетно - читаемость кода или эффективность программы.
А вот как добиться второго, не потеряв первое - это и есть то самое искусство, которое отличает программиста от "повара" (это у которого спагетти вместо кода).
Мне кстати, доводилось разбирать чужие "спагетти" - обычно это кончалось тем, что я бросал это нафиг и решал задачу заново - это было быстрее и проще.
А вообще-то разбирать чужой код - довольно неблагодарное занятие.

Про экономию в несколько миллисекунд не согласен - зависит от задачи. Разумеется, нужно понимать, где будет реальная экономия, а где нет. NickLion по этому поводу дельное замечание сделал. Я, например, не знал.
А так - в одном месте сэкономили несколько миллисекунд, в другом месте сэкономили, третий кусок подсократили... - глядишь программа заметно шустрее стала.
А если рассуждать с позиций "железо нынче мощное - всё выдержит", тогда оптимизациями можно вообще не заморачиваться. Только вот хорошо ли это будет?
Красивый код - это хорошо. Но красивый код - это не только читаемый код. Это ещё и красота решения, оценить которую может только человек знающий.
Так же как красота математической теории или химической формулы.

Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:

Аватара пользователя
Bizdelnick
Модератор
Сообщения: 18978
Статус: ✡ иностранный агент
ОС: Debian GNU/Linux

Re: Языки програмирования (скриптовые)

Сообщение Bizdelnick »

Hephaestus писал(а):
30.12.2014 14:10
А вообще-то разбирать чужой код - довольно неблагодарное занятие.

Разбирать свой собственный код, написанный год-два назад, не намного проще. Так что читаемость важна, даже если не планируется, что с кодом будет работать кто-нибудь ещё.

Hephaestus писал(а):
30.12.2014 14:10
Про экономию в несколько миллисекунд не согласен - зависит от задачи.

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

Hephaestus писал(а):
30.12.2014 14:10
если рассуждать с позиций "железо нынче мощное - всё выдержит", тогда оптимизациями можно вообще не заморачиваться. Только вот хорошо ли это будет?

Такого я не говорил. Задача программы - экономить время. Если программа будет использоваться на тысячах систем в режиме 24/7, то затратить несколько лишних человекочасов ради большей оптимизации вполне можно. Если речь идёт о скрипте, который будет запускаться раз в месяц и работать 2-3 секунды, то затраченное на разработку (и последующую доработку, в том числе и на разбирательство с уже написанным кодом) время куда более критично, чем то, будет скрипт отрабатывать за 3 секунды, или всё-таки за 2. В большинстве случаев мы имеем дело с какой-то промежуточной ситуацией, и нужно искать разумный компромисс.
Кроме того, оптимизировать всё и вся нет никакого смысла. Всегда есть некое бутылочное горлышко - та часть программы, которая выполняется дольше всего - и в нём действительно за счёт сравнительно небольших изменений можно добиться существенного прироста производительности. Если же речь идёт о какой-то проверке, которая выполняется один раз и занимает считаные микросекунды, как её ни оптимизируй, на время выполнения программы это заметно не повлияет.
Простой пример (извините, опять на C): при объявлении переменной можно инициализировать её, присвоив нулевое значение, даже если в дальнейшем значение должно быть изменено. При этом - о ужас! - будет затрачено несколько процессорных тактов на бесполезную, в общем-то, работу:

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

int a = 0;
int b = get_some_value();
switch (b) {
case 0:
        a = 1;
        do_something(a);
        break;
case 1:
        a = 5;
        do_something_else(a);
        break;
default:
        a = b;
        break;
}
return a;

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

Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2

Re: Языки програмирования (скриптовые)

Сообщение Hephaestus »

Bizdelnick писал(а):
30.12.2014 12:34
С точки зрения стиля это может быть не лучшим решением.
Hephaestus писал(а):
30.12.2014 13:01
Я рассуждал без привязки к языку.
Bizdelnick писал(а):
30.12.2014 13:20
Так я тоже. Что пример на C - ну уж извините, пришлось взять что-то конкретное для иллюстрации.
Bizdelnick писал(а):
30.12.2014 20:40
Простой пример (извините, опять на C):
Простите, а о стиле какого языка (в смысле читаемости) следует говорить, если общий ход рассуждений всё-таки без привязки к языку?
Стили-то везде разные. То, что в одном хуже (с точки зрения стиля) - в другом вполне нормально.

Bizdelnick писал(а):
30.12.2014 20:40
Если речь идёт о скрипте, который будет запускаться раз в месяц и работать 2-3 секунды, то затраченное на разработку (и последующую доработку, в том числе и на разбирательство с уже написанным кодом) время куда более критично, чем то, будет скрипт отрабатывать за 3 секунды, или всё-таки за 2.
Я где-то на форуме рассказывал о своём опыте с системой Гарант. Там была не слишком удачная схема обновления баз.
Так вот поначалу тоже было - не всё ли равно, отработает за 40 минут или за 1 час? Пустяки.
Но когда база разрослась, этот 1 час превратился в 4-5 часов. И разница в 20 минут превратилась в разницу в пару часов.
Так что здесь нельзя заранее сказать, как оно заработает в других условиях, и как окупится затраченное время.

Что касается скрипта, запускаемого раз в месяц, то здесь и оптимизировать-то особо нечего.
В таких случаях, если уж что-то оптимизируется, то экономия составляет гораздо больше, чем 1 секунда, это уж точно.

Bizdelnick писал(а):
30.12.2014 20:40
Если же речь идёт о какой-то проверке, которая выполняется один раз и занимает считаные микросекунды, как её ни оптимизируй, на время выполнения программы это заметно не повлияет.
Я не такую оптимизацию имел в виду, когда говорил об использовании сдвигов вместо умножения/деления.
Дело в том, что умножение/деление относятся к "тяжелым" операциям.
А сдвиг - это не просто умножение/деление на 2. Это может быть умножение/деление на 1073741824, например, что не совсем одно и то же.
Поэтому сдвиг всегда намного быстрее. Если в программе много "тяжелых" вычислений - то таким видом оптимизации пренебрегать не стоит.

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

Что касается проверки условия, вынесенной за пределы цикла, то она хоть и занимает доли секунды, но в моей программе такая оптимизация была ощутимой - программа перестала притормаживать, отзывчивость повысилась.
Был и другой случай, когда я, решая задачу на графах на языке Pascal, решил воспользоваться встроенными средствами языка по работе с множествами. Удобно же.
Но в итоге оказалось, что это решение было неоптимальным - с графом до 7 вершин программа отрабатывала нормально, а от 7 и выше - я не мог дождаться результата. Если бы я это предвидел, я бы не ориентировался на встроенные возможности языка и пошёл бы совсем другим путём.
Поэтому, ещё раз скажу, не всегда сразу видно, где аукнется та или иная оптимизация или отказ от неё.

Bizdelnick писал(а):
30.12.2014 20:40
a можно убрать - получится оптимизация.
А в чём здесь оптимизация, можно узнать?
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:

Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current

Re: Языки програмирования (скриптовые)

Сообщение drBatty »

ekkl писал(а):
30.12.2014 11:56
А что, например, лучше почитать

Д. Кнут.

Hephaestus писал(а):
30.12.2014 12:26
Если есть цикл с предусловием, где происходит сравнение с результатом формулы, то формулу лучше вычислить заранее и сохранить в переменной, а не пихать как есть в проверку.
Не пихать в цикл одноразовые вычисления.
И вообще, не городить цикл, если можно обойтись без него.

Учитывать систему счисления, в которой работает машина - в нашем случае двоичная СС - для неё можно использовать сдвиги вместо умножения/деления на числа, являющиеся степенью двойки.
Различать "тяжелые" и "легкие" операции.

преждевременные оптимизации == зло.
Всё вышеперечисленное умеет компилятор делать.

Hephaestus писал(а):
30.12.2014 13:01
Понять, куда ведёт указатель в C/C++ тоже с первого взгляда нельзя, так что ж теперь, указатели не использовать?

ВНЕЗАПНО: да.

Bizdelnick писал(а):
30.12.2014 20:40
Простой пример (извините, опять на C): при объявлении переменной можно инициализировать её, присвоив нулевое значение, даже если в дальнейшем значение должно быть изменено. При этом - о ужас! - будет затрачено несколько процессорных тактов на бесполезную, в общем-то, работу

НЕ БУДЕТ. Компилятор это выкинет.

Hephaestus писал(а):
31.12.2014 07:56
А сдвиг - это не просто умножение/деление на 2. Это может быть умножение/деление на 1073741824, например, что не совсем одно и то же.

это не важно. Всё равно это зло. Время тратить нужно на оптимизацию алгоритма.
Hephaestus писал(а):
31.12.2014 07:56
Поэтому сдвиг всегда намного быстрее.

не всегда. Для FPU/SSE это не так. Т.ч. это забота компилятора, а не программиста.
Hephaestus писал(а):
31.12.2014 07:56
Был и другой случай, когда я, решая задачу на графах на языке Pascal

вопросов более не имею.
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали: