tiphareth: Sound in Linux

(Читать комментарии) - (Добавить комментарий)

pzz
2007-07-13 19:46 (ссылка)

Вообще-то, раскинские идеи довольно далеки от ваших представлений о "диалоге в человеческих терминах". По-моему, из продуктов, которыми мне доводилось пользоваться, идеям Раскина больше всего соответствуют так нелюбимый вами Emacs и оконный менеджер Ion.

Я вообще-то книжку Раскина исключительно по диагонали просматривал. Но я хочу сказать, в Эпле эти идеи по крайней мере есть. И их развитием там сознательно занимаются. В отличии от...

А идеи мои довольно сырые и неоформленные. Иначе, может быть, я бы сидел и занимался их имплементацией, а не языком бы чесал :-) Но то, что они много от чего отличаются, это очевидно. Вообще, мой прогноз (основанный на опыте и интуиции), пользовательский интерфейс нуждается в революции, а не в прилизывании уже понаписанного. Переход должен быть примерно такого же масштаба, как от командной строки RSX/11 и языка управления заданиями OS/360 к командной строке UNIX.

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

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

С точки зрения ad hoc программирования, язык программирования должен существенно совпадать (по крайней мере, быть изоморфным) языку повседневных действий. Т.е., программа это то, что я итак делаю, только сохраненная и готовая к повторному использованию. UNIX shell обладает этим свойством, Перл, Питон, ... - нет.

Ссылку можно было не давать, я знаю, что такое VT100. В детстве я даже помнил его управляющие последовательности — дети легко запоминают всякую дрянь. =)

Но Вы получили удовольствие, посетив этот сайт? Я лично получил.

По существу же — пока я не видел, пожалуй, ни одной фичи, облегчающей именно программирование, для которой был бы так уж нужен графический дисплей

Я, заметьте, пропагандирую программирование как средство решения повседневных задач, а не как профессию, которой должен владеть каждый. Я совсем не утверждаю, что именно в программировании ГУЙ нужен. Хотя в повседневной жизни он, очевидно, нужен многим. Например, чтобы симпатичную бумажку сверстать. Вообще, картинка часто гораздо информативнее колонки цифр.

Я бы предположил, что в полноэкранной программе (гуевой или текстовой, не суть важно) такое вот ad hoc программирование должно начинаться от клавиатурных макросов. Т.е. сделал что-то, понравилось, получил это в виде программы (только все же уже не в терминах нажатых кнопок, а в терминах совершенных действий), обобщил - получилась програмка.

Emacs мне лично кажется очень неудобным. И язык программирования у него, на мой взгляд, достаточно неудобный. Дело не в его функциональной природе, дело в том, что в нем 2 + 2 по-человечески не напишешь.

(Ответить) (Уровень выше) (Ветвь дискуссии)

yushi
2007-07-13 23:12 (ссылка)

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

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

Вообще, мой прогноз (основанный на опыте и интуиции), пользовательский интерфейс нуждается в революции, а не в прилизывании уже понаписанного.

К этому, и к домохозяйкам. В очередной раз повторюсь: упрощать интерфейс имеет смысл ровно до тех пор, пока он не начинает скрывать существенные для пользователя свойства управляемого объекта. Unix shell в этом отношении — практически максимальное возможное упрощение, все более "дружественные" среды на самом деле не самодостаточны или предельно неудобны. Вы сами привели хороший пример с автомобилем — никто не жалуется, что приходится крутить руль и давить на педали вместо того, чтобы сообщить адрес назначения и предоставить машине делать всё остальное.

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

Как альтернатива шелл-скриптам, а также sed'у с awk — очень хорош.

С точки зрения ad hoc программирования, язык программирования должен существенно совпадать (по крайней мере, быть изоморфным) языку повседневных действий. Т.е., программа это то, что я итак делаю, только сохраненная и готовая к повторному использованию.
…
Я бы предположил, что в полноэкранной программе (гуевой или текстовой, не суть важно) такое вот ad hoc программирование должно начинаться от клавиатурных макросов. Т.е. сделал что-то, понравилось, получил это в виде программы (только все же уже не в терминах нажатых кнопок, а в терминах совершенных действий), обобщил - получилась програмка.

Между прочим, и это реализовано в нелюбимом вами Emacs.

Но Вы получили удовольствие, посетив этот сайт? Я лично получил.

Ну, приступ ностальгии испытал, по крайней мере. На самом деле, спасибо.

Emacs мне лично кажется очень неудобным. И язык программирования у него, на мой взгляд, достаточно неудобный. Дело не в его функциональной природе, дело в том, что в нем 2 + 2 по-человечески не напишешь.

Я про Emacs могу сказать примерно то же, что Черчилль про демократию — это отвратительный текстовый редактор, но лучшего не существует.

А вот про Emacs Lisp вы странные вещи говорите. Emacs — это текстовый редактор. У вас часто внутри текстового редактора возникает потребность в сложении чисел? А для обработки текста Lisp предлагает очень естественный синтаксис (не говоря уже об огромном преимуществе единообразной записи всех операций).

Вообще, должен сказать, что как раз по красоте и понятности синтаксиса Lisp, особенно в инкарнации Scheme — один из самых удачных среди распространённых языков программирования. Сравните


#include <iostream>

using namespace std;

int main(int argc, char* argv[]) {
    cout << "Hello. world" << endl;
    return 0;
}


(display "Hello, world!\n")

(я готов привести и более сложные примеры).

(Ответить) (Уровень выше) (Ветвь дискуссии)

pzz
2007-07-13 23:35 (ссылка)

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

Нет. Слишком много не относящихся к делу подробностей. Циклы там, переменные, регулярные выражения. Да за одну идею, что строки можно сравнивать 2-мя разными способами, убивать надо.

К этому, и к домохозяйкам. В очередной раз повторюсь: упрощать интерфейс имеет смысл ровно до тех пор, пока он не начинает скрывать существенные для пользователя свойства управляемого объекта

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

Unix shell в этом отношении — практически максимальное возможное упрощение, все более "дружественные" среды на самом деле не самодостаточны или предельно неудобны

Это потому, что действительно удобную среду еще не придумали. Что не означает, что ее придумать нельзя.

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

Я про Emacs могу сказать примерно то же, что Черчилль про демократию — это отвратительный текстовый редактор, но лучшего не существует

vim?

А вот про Emacs Lisp вы странные вещи говорите. Emacs — это текстовый редактор. У вас часто внутри текстового редактора возникает потребность в сложении чисел? А для обработки текста Lisp предлагает очень естественный синтаксис (не говоря уже об огромном преимуществе единообразной записи всех операций)

Это Вы мне пытаетесь продать Emacs в качестве универсальной среды для жизни. Тогда он не текстовый редактор.

(я готов привести и более сложные примеры)

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

(Ответить) (Уровень выше) (Ветвь дискуссии)

yushi
2007-07-17 04:17 (ссылка)

Нет. Слишком много не относящихся к делу подробностей. Циклы там, переменные, регулярные выражения.

Как раз в Перле (да и в любом разумном скриптовом языке), программист, если его мозг не попорчен сиплюсплюсом, вполне может (и должен!) писать без "технических" переменных, а иногда — без явного объявления и использования каких-то переменных вообще. А вот попытка избавиться от регулярных выражений — это та самая попытка скрыть те детали управляемого объекта, которые и призван представлять интерфейс.

Я хоть раз где-то сказал слово упрощать?

Язык без циклов и регулярных выражений — это именно что недопустимое упрощение.

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

Да. Скорее это будет что-то такое (гляньте клипчик на заглавной странице, не пожалеете). Но это, опять же, скорее "вездесущая командная строка" (словесные приказы, автодополнение etc.), чем что-то радикально отличающееся от unix shell.

vim?

Послушайте, вы что, всерьёз готовы сравнивать vi(m) и Emacs в плане юзабилити? Как можно сравнивать vim, это тяжёлое наследие восьмидесятых, авторы которого не думали над эргономикой вообще, и (до сих пор!) новаторский Emacs? Вы правда не понимаете, чем они отличаются?

Это Вы мне пытаетесь продать Emacs в качестве универсальной среды для жизни.

Вы меня с кем-то путаете. Я говорю, что хорошая программируемая среда неизбежно будет похожа на Emacs. Но вряд ли она при этом будет Emacs'ом — он всё же сделан не для этого. Я не из тех, кто при помощи Emacs даже пиво открывает, для меня это просто текстовый редактор. Пожалуй, лучший из существующих — но не более того.

*Продолжу в следующем комменте*

(Ответить) (Уровень выше) (Ветвь дискуссии)

pzz
2007-07-17 16:23 (ссылка)

Как раз в Перле (да и в любом разумном скриптовом языке), программист, если его мозг не попорчен сиплюсплюсом, вполне может (и должен!) писать без "технических" переменных, а иногда — без явного объявления и использования каких-то переменных вообще. А вот попытка избавиться от регулярных выражений — это та самая попытка скрыть те детали управляемого объекта, которые и призван представлять интерфейс

Вместо регулярных выражений должен быть встроенный парсер в стиле СНОБОЛ 4.

У Перла ужасный синтаксис. Все эти $, @, все эти синтаксические вольности (хочу пишу if справа, а хочу - слева).

Нафиг нафиг.

Да. Скорее это будет что-то такое (гляньте клипчик на заглавной странице, не пожалеете). Но это, опять же, скорее "вездесущая командная строка" (словесные приказы, автодополнение etc.), чем что-то радикально отличающееся от unix shell

Прикольная штучка. И мальчики, которые ее написали, тоже прикольные.

А сама гуйня должна быть конструктором. Т.е., беру и собираю себе аппликацию из готовых компонентов. Например, могу соеденить почтовую программу с word'ом. Или заменить в Ворде текстовый редактор vim'ом.

Конечно, уже собранные и работоспособные аппликации должны прилагаться. Как основа творчества :-)

Послушайте, вы что, всерьёз готовы сравнивать vi(m) и Emacs в плане юзабилити? Как можно сравнивать vim, это тяжёлое наследие восьмидесятых, авторы которого не думали над эргономикой вообще, и (до сих пор!) новаторский Emacs? Вы правда не понимаете, чем они отличаются?

Правда не понимаю.

(Ответить) (Уровень выше) (Ветвь дискуссии)

yushi
2007-07-29 04:22 (ссылка)

Вместо регулярных выражений должен быть встроенный парсер в стиле СНОБОЛ 4.

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

Прикольная штучка. И мальчики, которые ее написали, тоже прикольные.

Ага. Тамошний генеральный директор, как вы, возможно, поняли — сын Раскина. Того самого.

Вы правда не понимаете, чем они отличаются?

Правда не понимаю.

Интерфейс Emacs единообразен внутри себя — зная некоторые принципы, можно догадаться, как вызывается то или иное действие; в vi это не так. Например, одни и те же клавиши с Ctrl вызывают перемещение на символ, а с Alt — на слово.
В Emacs нет необходимости для любой ерунды вываливаться в "командный режим", все действительно часто используемые функции повешены на клавиатурные привязки. А если уж командная строка понадобилась, она вызывается по Alt-X, и не надо снимать руки с основной клавиатуры.
Кстати, Emacs вообще единственный редактор, позволяющий открыть, набрать, отредактировать, сохранить и закрыть текст, вообще не отрывая руки от основного блока клавиатуры. Я печатаю десятью пальцами, вслепую, и в русской, и в латинской раскладке. При этом я очень нетерпеливый человек. К тому же, как большинство русских, выполнять большинство задач (по крайней мере, требующих написания текста, а не кода) я начинаю через день после дедлайна. Поэтому я, как правило, набираю текст так быстро, как только могу. Необходимость тянуться ко клавишам со стрелками, PgUp/PgDn, Esc, а тем более к мышке (хотя последнее уже не про vi) реально отжирает существенное время и очень бесит.
Emacs очень хорошо документирован — в любой момент можно стандартным способом поинтересоваться, что происходит, и получить ответ.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)

http://users.livejournal.com/__gastrit/
2007-07-30 00:34 (ссылка)

«Простите, это частная драка, или каждый может вступить?» (c)

> Необходимость тянуться ко клавишам со стрелками [...] Даже кажущиеся на первый взгляд дикими решения
> (например, рекомендация не использовать кнопки со стрелками для перемещения курсора) в итоге оказываются
> наилучшим способом организации работы.

А что, разве у меня одного в vim'е hjkl работают? :-0

С уважением,
Гастрит

(Ответить) (Уровень выше) (Ветвь дискуссии)

yushi
2007-07-30 00:46 (ссылка)

Каждый, каждый.

А что, разве у меня одного в vim'е hjkl работают? :-0

Работают-то они у всех. Но:

для перехода в командный режим всё равно придётся тянуться к Esc,
сам факт переключения режимов отнимает достаточно много времени,
в отличие от Emacs, клавиатурные привязки не единообразны: переход на символ/на слово, в начало строки/в начало предложения выглядят совершенно по-разному.

(Ответить) (Уровень выше) (Ветвь дискуссии)

http://users.livejournal.com/__gastrit/
2007-07-30 01:57 (ссылка)

> для перехода в командный режим всё равно придётся тянуться к Esc,

Не поспоришь. Хотя лично для меня (впрочем, не могу похвастаться тысячью символов в минуту десятью пальцами слепым методом) это трудности не составляет. Кстати, краем уха слышал, что в Emacs тоже нередко приходится тянуться к Ctrl и Alt — меня верно информировали? :-)

В принципе, сам-то я holy wars люблю :-) Но вот конкретного мордобоя vi vs emacs не понимаю абсолютно. Насколько я могу судить, оба класса редакторов ориентированы не на "чайников" и предполагают необходимость выучивать определённый набор базовых команд, без которых в них делать нечего в принципе. При этом если некто вызубрил vi'шные клавиши на уровне собаки Павлова, то ему заведомо плевать на то, что они выглядят "по-разному" — он их просто знает, и всё тут. Если же некто бегает от всех клавиш, как чёрт от ладана — то он, имхо, будет набирать не в Emacs, а в M$ Word :-) Так что Ваш третий аргумент легко можно отспорить.

Для меня, например, в выборе vim'а основную роль играют следующие чисто субъективные обстоятельства:

1) Основы vi'шных правил приличия мне вбили ещё на четвёртом курсе, а дополнительно осваивать emacs мне элементарно лень.

2) Суммарный объём vim-common+vim-runtime+vim - порядка 15 метров, в то время как один только emacs21-common занимает 37 оных.

Так вот не могли бы Вы объяснить, чем же Emacs (про который я отнюдь не хочу сказать ничего плохого — я его просто не знаю) действительно столь принципиально лучше vim'а, что я (подчёркиваю: не Вы, а именно я) должен на него переползать при всех вышеуказанных данных моего анамнеза и предубеждении против излишне "жирных" программ?

С уважением,
Гастрит

(Ответить) (Уровень выше) (Ветвь дискуссии)

yushi
2007-07-30 15:52 (ссылка)

в Emacs тоже нередко приходится тянуться к Ctrl и Alt — меня верно информировали?

Ага. Но вот лично мне нажимать Ctrl и Alt куда удобнее Esc, например.

Основы vi'шных правил приличия мне вбили ещё на четвёртом курсе, а дополнительно осваивать emacs мне элементарно лень

(не удержусь-таки; в порядке демагогии) Э, если я правильно понимаю — в том же курсе, где используется VAX VMS? Что же вы по тем же причинам не пользуетесь VAX VMS?

Так вот не могли бы Вы объяснить, чем же Emacs (про который я отнюдь не хочу сказать ничего плохого — я его просто не знаю) действительно столь принципиально лучше vim'а, что я (подчёркиваю: не Вы, а именно я) должен на него переползать

Тут мне трудно ответить — я не настолько хорошо знаю vim: сейчас погуглил и понял, что многие вещи, которые я считал эксклюзивной фичей Emacs, в vim тоже реализованы (а уж насколько адекватно — мне смотреть лень). Наверное, расписывать что-то словами здесь не очень осмысленно. Если бы у меня была задача перетащить какого-то пользователя vim под Emacs, я бы скорее показал ему быструю и эффективную работу в Emacs (что-нибудь вроде отладки большого программного проекта или вёрстки в LaTeX большой, разбитой на десятки файлов книжки с кучей формул) и спросил бы, 1)хочет ли он делать такую работу так же быстро и эффективно, 2)способен ли он этого добиться под vim (и ценой каких затрат сил и времени).

(Ответить) (Уровень выше) (Ветвь дискуссии)

http://users.livejournal.com/__gastrit/
2007-07-30 19:38 (ссылка)

> Ага. Но вот лично мне нажимать Ctrl и Alt куда удобнее Esc, например.

Вопрос вкуса. Кроме того, vi не виноват, что с 76-го клавиатура несколько поменялась :-)

> я правильно понимаю — в том же курсе, где используется VAX VMS

Это не демагогия, а дремучее невежество! :-)) VAX'ы были на втором курсе, а vi прилагался в качестве принудительного ассортимента к HP. У

zmey бы проконсультировались, что ли ;-)

Но про VAX я даже отвечу. Не пользуюсь я ими, главным образом, за физическим отсутствием таковых — чего про vim сказать нельзя (он-то у меня есть). Возможно, не стой передо мной сия главная проблема, встала бы другая (недостаточность ресурсов оного VAX'а с точки зрения интересующих меня задач) — и тут опять же vim оказывается в несколько другом положении (ну, не стесняет меня его "неэргономичность").

> Если бы у меня была задача перетащить какого-то
> пользователя vim под Emacs, я бы скорее показал ему
> быструю и эффективную работу в Emacs

Логично. Однако самый большой программный проект, с которым лично мне приходилось иметь дело, едва тянет на 300 килобайт кода, а в плане текста я набираю преимущественно изолированные статьи, а не «Principia Mathematica» (из чего следует, кстати, что всех возможностей того же vim я могу попросту не знать — а иначе сравнение может оказаться не вполне корректным). Впрочем, мне-то в этом плане просто: я ни от чего не зарекаюсь, и если действительно вдруг выяснится, что для каких-то моих целей Emacs принципиально превосходит vim — с лёгкой душой на него переползу. Но вот зачем устраивать вот это (http://www.michael-prokop.at/computer/images/vi-emacs-final.png), при любом раскладе не понимаю :-)

С уважением,
Гастрит

(Ответить) (Уровень выше)

pzz
2007-08-04 01:31 (ссылка)

А в чём принципиальное отличие? По-моему, это регулярные выражения и есть, только с громоздким занудным синтаксисом

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

Интерфейс Emacs единообразен внутри себя — зная некоторые принципы, можно догадаться, как вызывается то или иное действие; в vi это не так. Например, одни и те же клавиши с Ctrl вызывают перемещение на символ, а с Alt — на слово

То же самое в vi. Только комбинируются не действия с клавишами-модификаторами, а, например, motion commands с действиями.

В Emacs нет необходимости для любой ерунды вываливаться в "командный режим", все действительно часто используемые функции повешены на клавиатурные привязки. А если уж командная строка понадобилась, она вызывается по Alt-X, и не надо снимать руки с основной клавиатуры

Это не так уж и неудобно иметь командный режим. Только в vi работают по-другому. Основной режим - командный, а в режим вставки входят время от времени. Наличие режимов четко очерчивает начало/конец команды и хорошо сочетается с повторами и т.п.

Кстати, Emacs вообще единственный редактор, позволяющий открыть, набрать, отредактировать, сохранить и закрыть текст, вообще не отрывая руки от основного блока клавиатуры

У vi все то же самое. Клавиши движения курсора и т.п. продублированы на основном блоке клавиатуры (вернее, они находятся на основном блоке клавиатуры, и продублированы на блоке стрелок).

Emacs очень хорошо документирован

vi тоже :-)

Вот целая поэма про vi, написанная чуваком, который делает свой маленький бизнес на том, что аккуратно воткнул эмулятор vi в качестве редактора в Visual Studio (т.е., он там полностью интегрирован, а не примочка сбоку), а теперь пытается сделать то же самое с Вордом и Оутлуком :-)

(Ответить) (Уровень выше)

yushi
2007-07-17 04:40 (ссылка)

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

Пожалуйста, в чём проблема-то?

HTML с подсветкой синтаксиса:
http://cicuta.ru/uri/personal/software/scheme-sockets/server.scm.html
http://cicuta.ru/uri/personal/software/scheme-sockets/client-1.scm.html
http://cicuta.ru/uri/personal/software/scheme-sockets/client-2.scm.html

Тарболл:
http://cicuta.ru/uri/personal/software/scheme-sockets/scheme-sockets.tar.gz

Надеюсь, я правильно понял, чего вы хотите. Здесь сервер и два (одинаковых) клиента; сервер вешается на два порта, 2027 и 2727, и ждёт соединений. Клиенты подключаются к ним и начинают подавать сообщения через случайные промежутки времени, одновременно ожидая входящих сообщений. Чтение/запись построчные, для наглядности. Если что-то непонятно — спрашивайте.

Пример довольно грубый и не слишком изящный, думаю, многие из присутствующих здесь в комментах (

kouzdra@lj, да и сам Миша) смогли бы предложить более компактные и красивые решения; но даже мой код иллюстрирует ряд преимуществ Лиспа перед тем же C/C++. Да, кстати, спасибо за повод немного попрограммировать на Scheme — после унылого цеплюсплюса на работе это невероятный фан.

Хотя предложенный вами пример, вообще говоря, не вполне корректный — сравнительные достоинства языков программирования обычно всё же оценивают на примерах реализации алгоритмов, а не использования (пусть даже стандартных) библиотек. Можно было ещё предложить мне поработать на Лиспе, например, с OLE-объектом, и, торжествуя, защитать мне слив, да.

(Ответить) (Уровень выше) (Ветвь дискуссии)

pzz
2007-07-17 16:47 (ссылка)

Надеюсь, я правильно понял, чего вы хотите. Здесь сервер и два (одинаковых) клиента; сервер вешается на два порта, 2027 и 2727, и ждёт соединений. Клиенты подключаются к ним и начинают подавать сообщения через случайные промежутки времени, одновременно ожидая входящих сообщений. Чтение/запись построчные, для наглядности. Если что-то непонятно — спрашивайте

Ну я этот код понял, наверное, на 1/3.

Я имел ввиду только сам цикл, который данные между сокетами перекидывает. Т.е., Ваш сервер минус инициализация.

А как это будет выглядеть не на потоках, а на select'е?

А почему LISP, а не ML? У ML синтаксис поизящнее, и статическая типизация наличествует...

Хотя предложенный вами пример, вообще говоря, не вполне корректный — сравнительные достоинства языков программирования обычно всё же оценивают на примерах реализации алгоритмов, а не использования (пусть даже стандартных) библиотек. Можно было ещё предложить мне поработать на Лиспе, например, с OLE-объектом, и, торжествуя, защитать мне слив, да

Не более некорректный, чем Hello, World!.

P.S. Я уезжаю в отпуск на 2 недели, так что отвечать буду довольно нерегулярно...

(Ответить) (Уровень выше) (Ветвь дискуссии)

yushi
2007-07-29 04:38 (ссылка)

Ну я этот код понял, наверное, на 1/3.

Я тут показал этот код Ю.Бронникову (

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

А как это будет выглядеть не на потоках, а на select'е?

Я, признаться, не берусь ни на каком языке написать человечески выглядящий код с select'ами. Все сервера, исходники которых мне доводилось просматривать хотя бы по диагонали, использовали нити либо fork. Можно где-нибудь посмотреть пример аккуратного кода с select'ом на C?

А почему LISP, а не ML? У ML синтаксис поизящнее, и статическая типизация наличествует...

Прежде всего, я ML скорее не знаю; но программы на ML, которые я видел, раздражали как раз отсутствием лисповских скобочек, чётко показывающих, что к чему относится. Что же до статической типизации, то, честно говоря, я не считаю её панацеей, а уж такие параноидальные системы типов, как в ML или Haskell, будучи вполне адекватными в индустрии, в "бытовом" программировании ИМХО скорее мешают.

P.S. Я уезжаю в отпуск на 2 недели, так что отвечать буду довольно нерегулярно...

Я тоже уезжаю в отпуск, так что, видимо, надо признать дискуссию свернувшейся по объективным обстоятельствам…

(Ответить) (Уровень выше) (Ветвь дискуссии)

pzz
2007-08-04 01:43 (ссылка)

Я тут показал этот код Ю.Бронникову ([info]gogabr), и очень быстро выяснилось, что C++ съел-таки мой мозг. Замыканий (из-за которых, видимо, код так плохо и читается — по крайней мере, человека, у которого нет минимального опыта программирования на функциональных языках, они могут напугать) здесь совершенно не нужно, это всё рудименты многолетней возни с объектами

Мешает, скорее, синтаксис непривычный. Идея замыкания, как раз, проста и понятна.

Я, признаться, не берусь ни на каком языке написать человечески выглядящий код с select'ами. Все сервера, исходники которых мне доводилось просматривать хотя бы по диагонали, использовали нити либо fork. Можно где-нибудь посмотреть пример аккуратного кода с select'ом на C?

Посмотрите на libevent. Код там так себе, но подход правильный.

К сожалению, не могу пока показать свою реализацию, т.к. две старые под NDA, а новая (которая когда-нибудь будет доступна под BSD лицензией) еще не доведена до состояния, в котором ее прилично будет опубликовать.

Прежде всего, я ML скорее не знаю; но программы на ML, которые я видел, раздражали как раз отсутствием лисповских скобочек, чётко показывающих, что к чему относится. Что же до статической типизации, то, честно говоря, я не считаю её панацеей, а уж такие параноидальные системы типов, как в ML или Haskell, будучи вполне адекватными в индустрии, в "бытовом" программировании ИМХО скорее мешают

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

(Ответить) (Уровень выше)

(Читать комментарии) -