И таки вы еще хотите использовать GNOME?

[vitus_wagner]

Мигель де Иказа написал, что OOXML - это замечательный стандарт. Кто его читал, тот понимает чего стоят эти заявления. Кто не читал, возможно, в курсе, что объекм текста стандарта примерно на порядок превосходит объем аналогичного по смыслу стандарта ODT, и при этом ещё разрешает включать в документы бинарные куски, созданные некими сторонними приложениями, формат которых не специфицируется.

И это у нас теперь superb standard.

Впрочем, мне уже после того, как кнопки Ok и Cancel в диалогах GNOME/GTK поменяли местами, а уж тем более после прочтения GNOME HID всё стало ясно.

Comments

[innominabilis.livejournal.com]

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

Так именно что «человеческие», т.е. естественные, языки для этой задачи подходят плохо, причем не из-за ущербности системы, а из-за своих природных особенностей — неоднозначности, избыточности и т.п. Обратите внимание: везде, где требуется четкость и однозначность, используются искусственные языки — например, юридический, научный, командный — фактически, DSLи на базе «человеческого». Причем они очень разные, поскольку предназначены для разных задач. Ровно то же касается и языков программ.

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

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

Аналогично про «GNU сама по себе оболочка» была в эпоху текстовых терминалов на 9600. Для современных работ, когда и концепция потока, и концепция файла уже очень мешают нормально жить, считать консоль достаточной на все случаи жизни — это просто смотреть на мир через замочную скважину, а абсолютно все виды работ выполнять швейцарским армейским ножом.

А при чем тут вообще «консоль»? Суть-то не в том, на каком терминале что-то рисуется, а в том, что программы принимают, обрабатывают и выдают данные, и этими потоками можно управлять — перенаправлять, фильтровать, соединять и т.п. Можно согласиться с Вами по поводу концепции файла, но вот потоки данных никуда не деваются и в принципе не могут деться — это универсальнейшая концепция, охватывающая всю обработку данных вообще.

[nepilsonis.livejournal.com]

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

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

[innominabilis.livejournal.com]

Так с этим я не спорю. Я только за. Недовольство вызывает то, что нынешние тенденции ведут совсем не туда.

Стоило бы обратить внимание на наработки из области ФП. Те же монады со стрелками из Haskell тут очень к месту.