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

[ekkl]

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

[NickLion]

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

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

[ekkl]

А как насчет "экзотики" Lua, Go, Scala?
Лично я смотрю в строну Ruby.

[NickLion]

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

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

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

[ekkl]

Я так понял, что Scala для Java, это примерно то же, что и CoffeScript для JavaScript.
JS немного знаю, но почему-то не люблю. Ограничу его использование в браузере.

[NickLion]

Я так понял, что Scala для Java, это примерно то же, что и CoffeScript для JavaScript.

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

[drBatty]

А что будет удобнее для небольших, простых задач?

что за задачи?

[ekkl]

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

[SLEDopit]

перевести из 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 .

[Yaros]

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

[ekkl]

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

[Bizdelnick]

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

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

[ekkl]

Я уже заметил, что разработчики почему-то постоянно меняют синтаксис.Но Rails довольно мощная библиотека, поддержка немаленькая
Относительно Перла. Я слышал, что это довольно запутанный язык. программы напоминают тарелку спагетти..
--
Сам я перла не знаю, Руби начал изучать пару дней назад, когда писал программу. выбор пал почти методом тыка, Роль также сыграло то что в некоторой мере использовал некоторые gems. Тема поэтому и появилась, потому что пока не поздно пересмотреть мой выбор.
Баш не сильно нравится, и возможности, конечно, не ахти,поэтому и нужно что-то более-мене помощнее (и попроще)
ПС. Относительно модулей. В Руби они же тоже есть. Например, использовал Nokogiri для парсинга XML. Сам скрипт около 100 строк.

[Bizdelnick]

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

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

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

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

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

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

Относительно модулей. В Руби они же тоже есть.

Нисколько не сомневаюсь.

[drBatty]

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

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

Сам я перла не знаю, Руби начал изучать пару дней назад

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

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

division by zero

sed там, где достаточно tr

sed лучше, ибо умеет UTF-8. А в остальном согласен.

[eddy]

Пользуюсь скриптами на баше. Если что-то на баше не могу реализовать, пишу на сях.

[ekkl]

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

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

[NickLion]

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

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

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

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

[Bizdelnick]

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

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

[Hephaestus]

А что, например, лучше почитать, чтобы подобного не было?

Изучать программирование.
Не синтаксис конкретного языка, а именно программирование.
Компьютер - дура железная, сам ничего не умеет.
Решение задачи начинается у программиста в голове.
И вот если оно изначально кривое/нерациональное/неверное, то все языки будут одинаково плохи.

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

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

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

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

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

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

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

[Bizdelnick]

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

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

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

a = b/2;

понятно сразу, а вот

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

a = (b >> 1);

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

[Hephaestus]

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

Я рассуждал без привязки к языку.

требует напряжения мозга.

Ну это уж, пардон, специфика профессии. Программист, который не напрягает мозг, ничего сложнее "Hello world" не напишет.
Понять, куда ведёт указатель в C/C++ тоже с первого взгляда нельзя, так что ж теперь, указатели не использовать?

[ekkl]

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

[Bizdelnick]

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

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

[Bizdelnick]

Я рассуждал без привязки к языку.

Так я тоже. Что пример на C - ну уж извините, пришлось взять что-то конкретное для иллюстрации.

Ну это уж, пардон, специфика профессии. Программист, который не напрягает мозг, ничего сложнее "Hello world" не напишет.
Понять, куда ведёт указатель в C/C++ тоже с первого взгляда нельзя, так что ж теперь, указатели не использовать?

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

[NickLion]

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

[Hephaestus]

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

Ну, тут уж, смотря что приоритетно - читаемость кода или эффективность программы.
А вот как добиться второго, не потеряв первое - это и есть то самое искусство, которое отличает программиста от "повара" (это у которого спагетти вместо кода).
Мне кстати, доводилось разбирать чужие "спагетти" - обычно это кончалось тем, что я бросал это нафиг и решал задачу заново - это было быстрее и проще.
А вообще-то разбирать чужой код - довольно неблагодарное занятие.

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

[Bizdelnick]

А вообще-то разбирать чужой код - довольно неблагодарное занятие.

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

Про экономию в несколько миллисекунд не согласен - зависит от задачи.

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

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

Такого я не говорил. Задача программы - экономить время. Если программа будет использоваться на тысячах систем в режиме 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]

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

Я рассуждал без привязки к языку.

Так я тоже. Что пример на C - ну уж извините, пришлось взять что-то конкретное для иллюстрации.

Простой пример (извините, опять на C):

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

Если речь идёт о скрипте, который будет запускаться раз в месяц и работать 2-3 секунды, то затраченное на разработку (и последующую доработку, в том числе и на разбирательство с уже написанным кодом) время куда более критично, чем то, будет скрипт отрабатывать за 3 секунды, или всё-таки за 2.

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

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

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

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

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

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

a можно убрать - получится оптимизация.

А в чём здесь оптимизация, можно узнать?

[drBatty]

А что, например, лучше почитать

Д. Кнут.

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

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

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

Понять, куда ведёт указатель в C/C++ тоже с первого взгляда нельзя, так что ж теперь, указатели не использовать?

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

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

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

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

это не важно. Всё равно это зло. Время тратить нужно на оптимизацию алгоритма.

Поэтому сдвиг всегда намного быстрее.

не всегда. Для FPU/SSE это не так. Т.ч. это забота компилятора, а не программиста.

Был и другой случай, когда я, решая задачу на графах на языке Pascal

вопросов более не имею.