>то как произвести впечатление на людей, работающих с doc (как я, например)?

catdoc ?

> Если не упоминать OO, который действительно не unix-way как программа, но unix-way по духу (т.е. a) что его разрабатывало community b) что он является заменой ОО - чего не хватает, пишем сами), то как произвести впечатление на людей, работающих с doc (как я, например)?

Ты путаешь UNIX-way и GNU-way, это принципиально разные вещи. Первое это _технология_, второе это _идеология разработки_

Классический UNIX-way или

> Т.е. у тебя система не на C написана?

То что линукс дерьмовая поделка не говорит о том, что есть что-то лучше :)

perl в подобных тестах делает sh на порядки. Вывод: долой shell, да здравствует perl?

В Perl проблемы не с читаемостью, а в неудобстве работы со сложными структурами данных, так как все через ссылки делается, то есть отсутствие структур/записей напрягает. Посмотрим, что будет в Perl 6.

А XML - это Unix-way 2, так как text и хорошо подходит для сложноконфигурируемых программ. На что похож конфиг apache,proftpd?

И если говорить про regexp/pattern, то и про лексические и синтаксические анализаторы можно упомянуть.

>БАШ ТОРМОЗНЕЕ В 4 РАЗА! Долой башизмы-линуксизмы из скриптов!

Ну не стоит так на bash наезжать. Из моего скромного опыта самый навороченый мой скрипт должен был взять оклоло 600 .wav файлов, переделать их в ogg и сделать тэги в соответствии с именим файла/католога. И я бы несказанно удивился, если бы sh сделал эту работу в 4 раза быстрее. Для справки: на моей машине эти 600 трэков пережимались около семи часов.

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

> как быть с XML ? сейчас все даты переводят в иксмээль, и должны быть же такие же аналоги тока для иксмээля

тут http://www.faqs.org/rfcs/rfc3252.html написано:)

То есть, пардон ~160 файлов^ а не 600. И более пяти тысяч лет. Забыл уже всё по старости лет.

2anonymous (*) (25.01.2004 17:52:39):

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

В Perl проблемы и с читаемостью, и в неудобстве работы с функциями,
и в неудобстве работы со структурами данных. :-)

> А где упоминание о PHP. Большая часть инета написана именно на этом языке

наверное там же где и упоминание о HTML, на нем еще большая часть инета написана :)

> В Perl проблемы ... и в неудобстве работы с функциями,

В чем именно неудобства? По сравнению с чем?

Надо полагать передачей параметров только списком и никаким другим образом. А по сравнению с OCaml например.

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

а) Ну тем, кому нужен именно список, это очень удобно.

б) Как еще можно передавать параметры и чем это удобнее?

в) С момента появления в перле ссылок, передача параметров списком проблемой не является.

> А по сравнению с OCaml например.

Гы-гы-гы. В ocaml функция может получить только один параметр.

>i=0 >j=0 >while [ ! "$i" = '1000000' ] >do > while [ ! "$j" = '100' ] > do > j=$(( $j + 1 )) > done > i=$(( $i + 1 )) >done

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

Вот у меня в отделе работает молодой человек, так он поначалу тоже всем достоинства bash приводил... Первый скрипт, который он закоммитил в девелопмент ветку начинался со строки

#!/usr/bin/bash

На что ему вежливо сказали: "хочешь bash, пользуйся, мы все свободные люди. Только портировать его под все платформы, где работает наш софт, будешь сам. В свободное от работы время."

UNIX-way не только в пайпах и "каждая софтина делает свою маленькуя часть, но делает это хорошо", но еще и в стандартах. Если sh стандарт, то и скрипты должны писаться в рассчете на него. А что ты используешь в качестве нтерактивного шелла - это твое личное дело. Почему-то люди, использующие большую часть времени BSD, это понимают. Наверное потому, что у них интерактивный шелл - tcsh.

Башизмы в скриптах - давить.

>Гы-гы-гы. В ocaml функция может получить только один параметр.

Да, только там не параметр, а функцию, так что проблем не возникает.

б) Как еще можно передавать параметры и чем это удобнее?

Для программирования гуйни надо полагать метки(labels) не плохо катят, можно значения по умолчанию задавать и порядок не важен, когда много параметров код будет компактнее.

в) С момента появления в перле ссылок, передача параметров списком проблемой не является.

Так о том и речь, что путь есть, но не самый удобный, требует дополниельной возни с разименовыванием ссылок. Но зато наверное простой в релизации, те же классы реализованы на ссылках c именами, довольно своеобразно :-)

Думаю было бы классно добавить в Perl некоторые фичи, с сохранием совместимости, если возможно. А если уж совместимости не будет, то можно кардинально изменить/улучшить некоторые вещи. Хотя, по-хорошему, новый синтаксис было бы правильно сделать опциональным в виде параметра к интерпретатору.

И не получить, а вернуть. Но в чем удобство по сравнению с perl? Что perl не может получить/вернуть ссылку на функцию? :)

> Для программирования гуйни надо полагать метки(labels) не плохо катят, можно значения по умолчанию задавать и порядок не важен, когда много параметров код будет компактнее.

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

Можно и пример рассмотреть:

01:### perl ############
02:my @a = ();
03:my @b = ();
04:my @c = ();
05:my @d = ();
06:
07:sub test {
08:    my @a = @{shift @_};
09:    my @b = @{shift @_};
10:    my @c = @{shift @_};
11:    my @d = @{shift @_};
12:}
13:
14:test(\@a,\@b,\@c,\@d);
15:######################

01:(*** ocaml **************************)
02:let a = [] in
03:let b = [] in
04:let c = [] in
05:let d = [] in
06:
07:let test a b c d = () in test a b c d
08:(************************************)

Одно и тоже, но во втором случае короче почти в 2 раза.
В Perl по сути два раза передаваемые параметры описываем, вместо
одного. Неужели незаметно? С ссылками на функции все тоже самое,
много лишней письменности :)

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

Пример можно?

http://iis1.cps.unizar.es/Oreilly/perl/cookbook/ch10_08.htm

Классику нужно читать :)

> 07:sub test {
> 08: my @a = @{shift @_};
> 09: my @b = @{shift @_};
> 10: my @c = @{shift @_};
> 11: my @d = @{shift @_};
> 12:}

Ну это несерьёзно.

2Baka-kun Хоть они и стандарты, но меняются. Старый стандарт остается, новый появляется. Правда старый становится никому не нужен, новый его вытеснил - это и есть изменение стандарта. Bash стандарт де-факто в Linux'е. Пока.

> Башизмы в скриптах - давить.

Правильно. Если этого не делать, то bash станет UNIX-стандартом, а оно вам надо? :-)

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

Большая часть софта наваленная в порты FreeBSD была написана авторами изначально под Linux'ом. А в дальнейшем его будет еще больше. Может пора начинать привыкать, а не давить?

Ага. И стили мне туда, пожалуйста, и шрифты. Потому что с меня их требуют.
catdoc...
Им только читать, и то, хреновато местами.

Шел бы тогда куда подальше от написания статьи, раз у тебя линукс - дерьмовая поделка.

Дык напиши
#!/bin/sh

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

P.S. Учитывая растущую долю линукса и то, что у него по умолчанию bash, как думаешь, через сколько он станет стандартом де-факто?

> Правильно. Если этого не делать, то bash станет UNIX-стандартом, а оно вам надо? :-) Слава богу не все так рассуждают, иначе мы бы просто не имели бы того, что есть сейчас ... Может пора начинать привыкать, а не давить?

Вот у меня в системе изначально стоит линк sh->bash, так что все скрипты с #!/usr/bin/sh и #!/usr/bin/bash делают одно и то же. Так что, прописываю везде sh и никаких проблем с привыканием :)

> Во-вторых, помимо emacs и vi(m) есть туева хуча (не менее 400) других текстовых редакторов (в смысле их вовсе не два, как видно некоторым уважаемым win-программистам).

Ja dumau chto sleduet upomjanut' pro FTE ili Jed. Tak kak oni ochen' neplohi dlja novichkov.

> http://iis1.cps.unizar.es/Oreilly/perl/cookbook/ch10_08.htm
> Классику нужно читать :)

Это обычный анонимный хеш, как говорится ещё один способ не делать
именованные параметры, а пользоваться тем, что есть. В любом языке,
можно передавать хеш в функцию и будет тоже самое. Единственная
разница, что в Perl хеш является встроенным типом данных и это ещё
более менее смотрится. Фигня только в том, что если какой-то параметр
не задать, то ошибка появится в процессе выполнения, а не при запуске
приложения.

use strict;
sub abc {
    my %args = (a => 'a', b => 'b', @_);
    sleep 3; print $args{a},$args{c},"\n";
}
abc(a => 2);

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

Сразу видно, что обработки исключений в языке не хватает.

> Это обычный анонимный хеш,

Массив. Процедуре передается массив. Хэшем он становится уже внутри.

> как говорится ещё один способ не делать именованные параметры, а пользоваться тем, что есть.

Это именно именованные параметры. Или нечто внешне от них неотличимое.

> В любом языке, можно передавать хеш в функцию и будет тоже самое. Единственная разница, что в Perl хеш является встроенным типом данных и это ещё более менее смотрится.

Ага! Признаешься.

> Фигня только в том, что если какой-то параметр не задать, то ошибка появится в процессе выполнения, а не при запуске приложения.

Ты пример то смотрел?

> my %args = (a => 'a', b => 'b', @_);

my %args = (a => 'a', b => 'b', c =>'c', @_)

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

Или задать разумные значения по умолчанию.

> Сразу видно, что обработки исключений в языке не хватает.

Ну не знаешь ты perl, тогда зачем ругаешь? Hint: die & eval;

>Ну это несерьёзно. Это не аргумент :) К тому же, если рассмотреть что-то более сложное, чем передачу массивов или хешей, то еще более громоздко получается.

Несерьёзно в том смысле, что человек, действительно знающий perl, так никогда не напишет.

>Сразу видно, что обработки исключений в языке не хватает

try {
<code>
} except {
<exception handling>
}
finally {
<housekeeping code>
}

http://search.cpan.org/~pjordan/Exception-1.4/Exception.pm

> Шел бы тогда куда подальше от написания статьи, раз у тебя линукс - дерьмовая поделка.

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

Сам иди куда-нибудь.. поучись

С таким отношением у тебя и статья получится аналогичная.
Нет и не видел - разные вещи.

Посмотри на qnx, plan9.

А как много OS Вы видели в своей жизни, чтобы делать такие громкие
заявления?

Почитали бы чего-нибудь для начала, например про Reliant Unix :)

jackill (*) (26.01.2004 8:13:51):

>P.S. Учитывая растущую долю линукса и то, что у него по умолчанию bash, как думаешь, через сколько он станет стандартом де-факто?

anonymous (*) (26.01.2004 3:13:20):

>Большая часть софта наваленная в порты FreeBSD была написана авторами изначально под Linux'ом. А в дальнейшем его будет еще больше. Может пора начинать привыкать, а не давить?

Классическая логика виндузоидов (только s/Linux/Windows/). Попытка быть маленькими бИЛЛАМи гЕЙТСами. Только вышли за 2% на десктопе, а уже такие понты! Если руководствовать ЭТОЙ логикой, то "Учитывая растущую долю Виндовса и то, что у него по умолчанию CMD.EXE, как думаешь, через сколько он станет стандартом де-факто?". И ещё "Может пора начинать привыкать, а не давить?"

:-)

Классисческая логика бсд-оида, заходящегося в религиозном экстазе. У самих половина утилит в системе представляет самопальные поделки, и некоторые до сих пор не соотвествуют посиксу, система сделана по принциму "как угодно, но шоб SysV несовместимо", а туда же - упрекать gnu в несоблюдении стандартов. Вот будет завтра (через год) bash стандартизирован, как тогда отмазываться будешь? :)

>Массив. Процедуре передается массив. Хэшем он становится уже внутри.
Согласен.

>Ты пример то смотрел?
Да я о другом, об ошибке программера, и где она всплывет, в случае чего.

>Ага! Признаешься.
Кстати, еще один способ задавать дефолтные значения:
my $a = shift || 'x';

>Ну не знаешь ты perl, тогда зачем ругаешь? Hint: die & eval;
Да я и не ругаю, мне нравится, просто сравниваем.

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

>http://search.cpan.org/~pjordan/Exception-1.4/Exception.pm
вот это уже похоже на исключения, но внешние.

>Несерьёзно в том смысле, что человек, действительно знающий perl, так никогда не напишет.

my @a = @$_[0]; # можно и так
Это обыкновенная передача массива по значению так выглядит, я же 
не сам это придумал. Можно и через ссылки работать, о чем речь.

>Вот будет завтра (через год) bash стандартизирован, как тогда отмазываться будешь? :)

Вот будет bash стандартизирован, буду не отмазываться, а использовать. В чём проблемы? Вообще непонятно, почему вызывает (религиозное?) неприятие призыв писать переносимые, соответствующие стандартам программы (а скрипты это те же программы). Ну понятно, многим хочется быть Гейтсами и не плевать только на те стандарты, которые сам придумал и заставлять других плясать под свою дудку. Только это не совместимо со свободой, о которой многие здешние сектанты орут на каждом углу (впрочем, как доходит до дела, оказывается, что для них это просто слова). К тому же много Гейтсов Земля не прокормит. Его и одного-то слишком много для этой маленькой планеты. :-(

Некорректное сравнение.
cmd.exe не портировано ни под одну unix-подобную систему.
Зато bash мы можем, насколько я помню, понаблюдать даже на windows...

Ощущаешь разницу? ;)

Да ладно тебе, я же шутил.

> Вот у меня в системе изначально стоит линк sh->bash, так что все скрипты с #!/usr/bin/sh и #!/usr/bin/bash делают одно и то же. Так что, прописываю везде sh и никаких проблем с привыканием :)

Как правильно заметил мистер Хайд, писать необходимо #!/bin/sh, чтобы везде работало. Но это только половина дела: не нужно использовать специфических для bash конструкций в скриптах. Т.е. быть последовательным: сказал "sh", скажи и "бэ".

Не путайся. Причем тут переносимость?

Ты говорил про скорость. Да, скорость - г.вно. Для твоих циклов.

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

А вместо
#!/bin/bash все нормальные люди пишут #!/bin/sh, ибо симлинк sh на
bash прокинут по-умолчанию.

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

Я говорил и про скорость и про переносимость. Ладно, скорость в скриптах не очень важна, хотя и за неё надо бороться. А что не даёт иметь в системе sh? Религия? Или за 125K (если sh собран динамически) дистроклепателей жаба давит? Для сравнения бинарник баша весит 550K в динамической сборке.

>А вместо #!/bin/bash все нормальные люди пишут #!/bin/sh, ибо симлинк sh на bash прокинут по-умолчанию. Этого мало! Кроме #!/bin/sh нужно ещё избегать башизмов в тексте скрипта. Тем более, что без них легко обойтись в 99% случаев. А для остального 1% существует perl. Тогда всё везде будет работать.

> Ну не стоит так на bash наезжать. Из моего скромного опыта самый навороченый мой скрипт должен был взять оклоло 600 .wav файлов, переделать их в ogg и сделать тэги в соответствии с именим файла/католога. И я бы несказанно удивился, если бы sh сделал эту работу в 4 раза быстрее. Для справки: на моей машине эти 600 трэков пережимались около семи часов.

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

"арифмометр" мля... все это время ест ogg, а не шелл

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

> "арифмометр" мля... все это время ест ogg, а не шелл

Слушай, у тебя в роду жирафы были?

Ну лично я не люблю, когда у меня что-то дублируется. Достаточно того,
что на случай атомной войны есть ash.
Больше программ - больше вероятность поломки и т.п.
Поэтому все программы, дублирующие друг друга, у меня убиты (кроме браузеров -
показывал бы konqueror страницы попрямее - и mozilla бы выкинул), чего
и тебе желаю.

P.S. Опять же, тут уже вопрос привычки - тот же bash можно собрать где угодно.