Консоль vs GUI (Кто богаче по возможностям?)
Самые основные - взаимодействие человека и программы.
Можно перечислить множество задач, для которых требуется координатное устройство ввода, как часто они возникают у пользователя и каковы возможности этого пользователя быстро решать такие задачи _своими_силами_?
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Эти "основные" задачи часто оказываются разовыми.
А вот грамотная реализация межпрограммного взаимодействия,
которое допускает вмешательство человека, может оказаться
полезным существенно более одного раза.
Более кратко: командная строка рулит.
А вот грамотная реализация межпрограммного взаимодействия,
которое допускает вмешательство человека, может оказаться
полезным существенно более одного раза.
Более кратко: командная строка рулит.
поясни термин: координатное устройство ввода..
> Можно перечислить множество задач, для которых требуется координатное устройство ввода,
Можно я попробую?
Работа с невербальной информацией: графика, звук, видео.
Там, где объект хорошо представлять протяжённым в пространстве-времени.
Можно я попробую?
Работа с невербальной информацией: графика, звук, видео.
Там, где объект хорошо представлять протяжённым в пространстве-времени.
> Работа с невербальной информацией: графика, звук, видео.
только пока нет необходимости это делать в batch-mode
только пока нет необходимости это делать в batch-mode
естественно
но в batch-mode ты ничего сделать не сможешь, не научившись представлять объекты
в пространстве-времени
другое дело, что это в некоторых случаях и без софта можно научиться,
с помощью бумаги-ручки, или только в воображении
но в batch-mode ты ничего сделать не сможешь, не научившись представлять объекты
в пространстве-времени
другое дело, что это в некоторых случаях и без софта можно научиться,
с помощью бумаги-ручки, или только в воображении
И как пользователь может самостоятельно программировать такие задачи?
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
вот например, нужно было преобразовать вывод, полученный с помощью
tex -> dvips -> gs -sDEVICE=pcxmono в виндах с фотошопом
(не спрашивайте зачем, так вышло)
так сначала на примере одной странички сделал преобразование руками, а потом всё остальное - макросом
tex -> dvips -> gs -sDEVICE=pcxmono в виндах с фотошопом
(не спрашивайте зачем, так вышло)
так сначала на примере одной странички сделал преобразование руками, а потом всё остальное - макросом
1. Командная строка, правильно реализованная в графическом виде - много круче, чем таже самая строка реализованная в текстовом виде.
Возьмем банальное дополнение имени файла по табу: в текстовой консоли - это делается с извратами, в графике - это тривиальныйвыпадающий список.
2. Отображение данных обычно подразумевает под собой: таблицы, диаграммы, иконки и т.д.
> перечислить множество задач, для которых требуется координатное устройство ввода
Выбор из заранее заданного множества данных.
Задача стандартная и везде встречающая. Даже классическая nix-овая командная строка не смогла без этого обойтись.
Возьмем банальное дополнение имени файла по табу: в текстовой консоли - это делается с извратами, в графике - это тривиальныйвыпадающий список.
2. Отображение данных обычно подразумевает под собой: таблицы, диаграммы, иконки и т.д.
> перечислить множество задач, для которых требуется координатное устройство ввода
Выбор из заранее заданного множества данных.
Задача стандартная и везде встречающая. Даже классическая nix-овая командная строка не смогла без этого обойтись.
Графическая командная строка - всегда богаче, чем текстовая командная строка.
ps
Взять хотя бы ту же генерацию скрипта на основе "мышинных" действий.
Такая возможность намного быстрее всяких man-ов помогает разобраться и написать какие-либо скрипты.
ps
Взять хотя бы ту же генерацию скрипта на основе "мышинных" действий.
Такая возможность намного быстрее всяких man-ов помогает разобраться и написать какие-либо скрипты.
Ты забываешь про последнее, но самое главное условие:
где то место, в котором пользователь может проявить себя как программист?
Все упомянутые вещи сделаны до того, и вряд ли кто будет там менять что-либо _без_особой_надобности_.
А раз так, то и смысла в очередной свалке всего подряд нет.
---
...Я работаю антинаучным аферистом...
где то место, в котором пользователь может проявить себя как программист?
Все упомянутые вещи сделаны до того, и вряд ли кто будет там менять что-либо _без_особой_надобности_.
А раз так, то и смысла в очередной свалке всего подряд нет.
---
...Я работаю антинаучным аферистом...
> Командная строка, правильно реализованная в графическом виде - много круче,
> чем таже самая строка реализованная в текстовом виде.
гы-гы
лол
В текстовой командной строке я потом напишу скрипт,
который будет делать это же самое вместо меня и займусь
более сложными вещами. Метасистемный переход. Прогресс.
Все дела.
А с гуём придётся или каждый раз ебаться заново, делая
одно и то же по много раз или писать этот гуй заново.
> чем таже самая строка реализованная в текстовом виде.
гы-гы
лол
В текстовой командной строке я потом напишу скрипт,
который будет делать это же самое вместо меня и займусь
более сложными вещами. Метасистемный переход. Прогресс.
Все дела.
А с гуём придётся или каждый раз ебаться заново, делая
одно и то же по много раз или писать этот гуй заново.
> Эти "основные" задачи часто оказываются разовыми.
У админа - они может быть и разовые. Все-таки админ - это обслуга компьютера .
А у остальных людей: бухгалтеров, художников, писателей, клерков и т.д. - это именно основной режим работы.
У админа - они может быть и разовые. Все-таки админ - это обслуга компьютера .
А у остальных людей: бухгалтеров, художников, писателей, клерков и т.д. - это именно основной режим работы.
> А с гуём придётся или каждый раз ебаться заново, делая
одно и то же по много раз или писать этот гуй заново.
Обоснование такого вывода будет?
одно и то же по много раз или писать этот гуй заново.
Обоснование такого вывода будет?
> Выбор из заранее заданного множества данных.
Превербальный способ общения.
Основывая интерфейс на этой операции, добровольно отказываешься от преимуществ,
полученных человечеством от изобретения языка и письменности.
Да, именно так -
unix way: пользователь говорит компьютеру, что тот должен сделать
microsoft way: пользователь выбирает из списка разрешённых действий
Бля, щас буду бить.
Объясните бля через форум или того хуже по телефону челу, как сеть в виндах настроить.
Хрен обойдёшься без скриншотов, да и те часто бесполезны, так как в немного другой
версии контролы по окошкам по другому расставят - и всё.
А почему? Потому что вместо естественного вербального представления используют
образы и жесты (ткнуть мышой в вариант из списка - это жест,
примерно как первобытный человек был вынужден объясняцца с соплеменниками: "Ы!")
Да, конечно, правильно совмещать - но кто это бля умеет?
Вот и плодятся неюзабельные гуи.
А вот, вспомнил исключение: старый AutoCAD (под DOS, новых не видел).
Очень впечатлило в своё время.
Превербальный способ общения.
Основывая интерфейс на этой операции, добровольно отказываешься от преимуществ,
полученных человечеством от изобретения языка и письменности.
Да, именно так -
unix way: пользователь говорит компьютеру, что тот должен сделать
microsoft way: пользователь выбирает из списка разрешённых действий
Бля, щас буду бить.
Объясните бля через форум или того хуже по телефону челу, как сеть в виндах настроить.
Хрен обойдёшься без скриншотов, да и те часто бесполезны, так как в немного другой
версии контролы по окошкам по другому расставят - и всё.
А почему? Потому что вместо естественного вербального представления используют
образы и жесты (ткнуть мышой в вариант из списка - это жест,
примерно как первобытный человек был вынужден объясняцца с соплеменниками: "Ы!")
Да, конечно, правильно совмещать - но кто это бля умеет?
Вот и плодятся неюзабельные гуи.
А вот, вспомнил исключение: старый AutoCAD (под DOS, новых не видел).
Очень впечатлило в своё время.
> Взять хотя бы ту же генерацию скрипта на основе "мышинных" действий.
Ну ка, сгенерируй мне скрипт, чтобы хотя бы ну по форуму ходить автоматически, просматривая
новые сообщения, в нужном порядке (сначала любимые разделы, потом, если время остаётся, остальное).
Или опять же, настроить сеть в виндах на нескольких машинах, поставив каждой своё имя и свой IP (ну хорошо,
IP поставит DHCP, но ты включи его сначала своим сгенерированным скриптом)
Ну ка, сгенерируй мне скрипт, чтобы хотя бы ну по форуму ходить автоматически, просматривая
новые сообщения, в нужном порядке (сначала любимые разделы, потом, если время остаётся, остальное).
Или опять же, настроить сеть в виндах на нескольких машинах, поставив каждой своё имя и свой IP (ну хорошо,
IP поставит DHCP, но ты включи его сначала своим сгенерированным скриптом)
> А у остальных людей: бухгалтеров, художников, писателей,
> клерков и т.д. - это именно основной режим работы.
Ну да. Там где комп -- автоматизированное рабочее место специально
обученной обезьянки так и есть. Только им всё равно приходится
много раз одно и тоже делать, а вот автоматизировать - хуй.
> клерков и т.д. - это именно основной режим работы.
Ну да. Там где комп -- автоматизированное рабочее место специально
обученной обезьянки так и есть. Только им всё равно приходится
много раз одно и тоже делать, а вот автоматизировать - хуй.
> Да, именно так -
> unix way: пользователь говорит компьютеру, что тот должен сделать
> microsoft way: пользователь выбирает из списка разрешённых действий
Акцентируешься на "плохой" идиоме.
Мне больше нравится следующая идиома:
Пользователь говорит, что надо сделать, а компьютер ему в этом подсказывает (но не навязывает).
Замечу, что эта идиома берет хорошие черты, как от unit way-а, так и от microsoft way-а.
Да, в "умных" (а не всяких офисах) microsoft-овских программах применяется, как раз эта идиома.
> unix way: пользователь говорит компьютеру, что тот должен сделать
> microsoft way: пользователь выбирает из списка разрешённых действий
Акцентируешься на "плохой" идиоме.
Мне больше нравится следующая идиома:
Пользователь говорит, что надо сделать, а компьютер ему в этом подсказывает (но не навязывает).
Замечу, что эта идиома берет хорошие черты, как от unit way-а, так и от microsoft way-а.
Да, в "умных" (а не всяких офисах) microsoft-овских программах применяется, как раз эта идиома.
> Акцентируешься на "плохой" идиоме.
Ты поскипал то место, где я говорю об исключениях, которые да, имеют место быть.
Но попробуй найди такие исключения среди (возвращаясь к сабжу) говнобиблиотек -
творений говнокодеров, собранных на помойке.
Ты поскипал то место, где я говорю об исключениях, которые да, имеют место быть.
Но попробуй найди такие исключения среди (возвращаясь к сабжу) говнобиблиотек -
творений говнокодеров, собранных на помойке.
> Ну ка, сгенерируй мне скрипт, чтобы хотя бы ну по форуму ходить автоматически, просматривая
> новые сообщения, в нужном порядке (сначала любимые разделы, потом, если время остаётся, остальное).
И в чем проблема? Как в локальном, так и в глобальном плане
> Или опять же, настроить сеть в виндах на нескольких машинах, поставив каждой своё имя и свой IP (ну хорошо,
IP поставит DHCP, но ты включи его сначала своим сгенерированным скриптом)
Такая программа пишется довольно быстро, но ее не купят
> новые сообщения, в нужном порядке (сначала любимые разделы, потом, если время остаётся, остальное).
И в чем проблема? Как в локальном, так и в глобальном плане
> Или опять же, настроить сеть в виндах на нескольких машинах, поставив каждой своё имя и свой IP (ну хорошо,
IP поставит DHCP, но ты включи его сначала своим сгенерированным скриптом)
Такая программа пишется довольно быстро, но ее не купят
Я мог себе представить себе художника, который 5 раз одно и то же действие сделал руками, на шестой почесал репу, записал, подредактировал скрипт, остальные такие же действия сделав через скрипт.
Но я не могу себе представить себе художника, который читает man-ы, пишет с нуля скрипты в notepade-е и т.д.
Но я не могу себе представить себе художника, который читает man-ы, пишет с нуля скрипты в notepade-е и т.д.
> > Ну ка, сгенерируй мне скрипт, чтобы хотя бы ну по форуму ходить автоматически, просматривая
> > новые сообщения, в нужном порядке (сначала любимые разделы, потом, если время остаётся, остальное).
> И в чем проблема? Как в локальном, так и в глобальном плане
Вот есть форум.
Есть IE.
Есть комп, с подключенной педалью.
Хочу читать форум, нажимая на педаль, так как руки заняты пивом.
Работать руками допускается только чтобы захуйарить криатифф.
Чем ты будешь генерировать скрипт на основе мышиных кликов
для этой задачи?
Это нужно писать программу, абстрагируясь от координат элементов управления,
и работая с их именами - вербальным представлением - гуй отдыхает.
Признай уже, что погорячился насчёт генерирования
> > новые сообщения, в нужном порядке (сначала любимые разделы, потом, если время остаётся, остальное).
> И в чем проблема? Как в локальном, так и в глобальном плане
Вот есть форум.
Есть IE.
Есть комп, с подключенной педалью.
Хочу читать форум, нажимая на педаль, так как руки заняты пивом.
Работать руками допускается только чтобы захуйарить криатифф.
Чем ты будешь генерировать скрипт на основе мышиных кликов
для этой задачи?
Это нужно писать программу, абстрагируясь от координат элементов управления,
и работая с их именами - вербальным представлением - гуй отдыхает.
Признай уже, что погорячился насчёт генерирования
> Но я не могу себе представить себе художника, который читает man-ы,
> пишет с нуля скрипты в notepade-е и т.д.
А этого и не требуется.
Речь о том, что у него есть возможность написать нужный скрипт,
когда он поймёт, что именно ему нужно получить.
А потом уже генерировать скрипты, подобные этому,
когда придёт новый уровень понимания полученных возможностей.
Итд
> пишет с нуля скрипты в notepade-е и т.д.
А этого и не требуется.
Речь о том, что у него есть возможность написать нужный скрипт,
когда он поймёт, что именно ему нужно получить.
А потом уже генерировать скрипты, подобные этому,
когда придёт новый уровень понимания полученных возможностей.
Итд
На помойках, вообще, мало хороших программ, как консольных, так и gui-шных.
Соглашусь с тобой, что хороших Gui-шных особенно мало, потому что сделать хороший gui - это уже думать надо.
А консоль в каком-то виде может поддержать и студент-первокур.
Соглашусь с тобой, что хороших Gui-шных особенно мало, потому что сделать хороший gui - это уже думать надо.
А консоль в каком-то виде может поддержать и студент-первокур.
> Вот есть форум.
> Есть IE.
> Есть комп, с подключенной педалью.
> Хочу читать форум, нажимая на педаль, так как руки заняты пивом.
> Работать руками допускается только чтобы захуйарить криатифф.
> Чем ты будешь генерировать скрипт на основе мышиных кликов для этой задачи?
В таком постановке задача плохо решаема, так как html не несет в себе высокоуровневой семантики.
Но вот если бы у нас вместе с html-ем шла бы семантика - что вот это форум, это сообщение, это тред и т.д., то задача бы решалась довольно легко.
ps
Если эту семантику добавить ручками (например, сказать, что такой-то адрес - это такое-то понятие то задача решается даже в вышеприведенной постановке.
> Есть IE.
> Есть комп, с подключенной педалью.
> Хочу читать форум, нажимая на педаль, так как руки заняты пивом.
> Работать руками допускается только чтобы захуйарить криатифф.
> Чем ты будешь генерировать скрипт на основе мышиных кликов для этой задачи?
В таком постановке задача плохо решаема, так как html не несет в себе высокоуровневой семантики.
Но вот если бы у нас вместе с html-ем шла бы семантика - что вот это форум, это сообщение, это тред и т.д., то задача бы решалась довольно легко.
ps
Если эту семантику добавить ручками (например, сказать, что такой-то адрес - это такое-то понятие то задача решается даже в вышеприведенной постановке.
> > Или опять же, настроить сеть в виндах на нескольких машинах, поставив каждой своё имя и свой IP (ну хорошо,
> IP поставит DHCP, но ты включи его сначала своим сгенерированным скриптом)
> Такая программа пишется довольно быстро, но ее не купят
Опять же, гуй никак не поможет её написать, и уж точно не сгенерирует.
Вот и получаем - шаг в сторону - и приходится обкладываться доками, и придумывать интерфейс с нуля.
А программы, работающие с текстовым представлением, можно и заюзать.
Кстати, ты обратил внимание ещё на одну особенность microsoft way:
некому писать программы, которые не купят - слишком сложно.
> IP поставит DHCP, но ты включи его сначала своим сгенерированным скриптом)
> Такая программа пишется довольно быстро, но ее не купят
Опять же, гуй никак не поможет её написать, и уж точно не сгенерирует.
Вот и получаем - шаг в сторону - и приходится обкладываться доками, и придумывать интерфейс с нуля.
А программы, работающие с текстовым представлением, можно и заюзать.
Кстати, ты обратил внимание ещё на одну особенность microsoft way:
некому писать программы, которые не купят - слишком сложно.
> то задача решается даже в вышеприведенной постановке.
как?
как?
есть такое соображение, что математика + физика самая простая наука косвенное доказательство огромный в ней успех ( остальные науки тут полностью отдыхают ) и причина этому видится в невозможности это толком формализовать, науки занимаются описательством, нельзя все формализовать и для всего написать скрипт чтобы он рисовал и скульптурные автопортеты лепил, нельзя ! Гуи это шаг в сторону от формализации к реальному миру. ( консоль - математика-физика, гуи неформализуемая часть )...
там где можно формализовать гуи проиграет, это не вопрос, только формализовать все нельзя !
там где можно формализовать гуи проиграет, это не вопрос, только формализовать все нельзя !
> А этого и не требуется.
Требуется, иначе возникает большой барьер между ручными действиями и автоматическими действими.
Если между ручными и автоматическими действиями нет взаимосвязи, то получается, что человек может уметь выполнять какое-либо действие в ручную, но при этом не сможет его описать в скрипте, так и наоборот, имея перед глазами автоматический скрипт - человек не сможет научиться это делать руками.
Как раз генерация скрипта по действиям, и проигрывание скриптов - убирает данный барьер, можно прозрачно переходить от одних действий к другим, т. е. , например, for написать на скрипте, а само действие ввести в ручную.
Требуется, иначе возникает большой барьер между ручными действиями и автоматическими действими.
Если между ручными и автоматическими действиями нет взаимосвязи, то получается, что человек может уметь выполнять какое-либо действие в ручную, но при этом не сможет его описать в скрипте, так и наоборот, имея перед глазами автоматический скрипт - человек не сможет научиться это делать руками.
Как раз генерация скрипта по действиям, и проигрывание скриптов - убирает данный барьер, можно прозрачно переходить от одних действий к другим, т. е. , например, for написать на скрипте, а само действие ввести в ручную.
Во, ты всё правильно говоришь.
Но не приводишь примеров.
А почему?
Да потому что их нет.
А почему?
Потому что таких GUI не существует.
Потому что сделать такое неимецца сложно.
В правильном CLI - действительно понижается барьер между ручными и автоматическими действиями.
Действительно, вызываешь предыдущую команду, добавляешь for - и - о чудо! - команда,
работающая с одним, например файлом, оказывается умеет и целую кучу их обработать сама.
Сделать то же самое с GUI - одни разговоры слышны - реализаций нет.
Но не приводишь примеров.
А почему?
Да потому что их нет.
А почему?
Потому что таких GUI не существует.
Потому что сделать такое неимецца сложно.
В правильном CLI - действительно понижается барьер между ручными и автоматическими действиями.
Действительно, вызываешь предыдущую команду, добавляешь for - и - о чудо! - команда,
работающая с одним, например файлом, оказывается умеет и целую кучу их обработать сама.
Сделать то же самое с GUI - одни разговоры слышны - реализаций нет.
> как?
Сначала заводим понятия: форум, тред, сообщение и т.д.
Далее натягиваем на html семантику: связываем кнопочки, странички и т.д. с вышеприведенными понятиями.
Например: эта кнопочка - переходит в такой-то тред.
Далее сажаем пользователя за Ie, отлавливаем мышь, получаем скрипт вида:
открыть форум, зайти в раздел common, открыть непрочитанные сообщения в первом треде, во втором и т.д. выйти, зайти в раздел flood, открыть непрочитанные сообщения и т.д.
Далее мы этот скрипт можем уже редактировать, добавлять for-ы и т.д.
При наличии мощного анализатора можно в автоматизированном виде сворачивать последовательности однотипных действий в циклы.
Сначала заводим понятия: форум, тред, сообщение и т.д.
Далее натягиваем на html семантику: связываем кнопочки, странички и т.д. с вышеприведенными понятиями.
Например: эта кнопочка - переходит в такой-то тред.
Далее сажаем пользователя за Ie, отлавливаем мышь, получаем скрипт вида:
открыть форум, зайти в раздел common, открыть непрочитанные сообщения в первом треде, во втором и т.д. выйти, зайти в раздел flood, открыть непрочитанные сообщения и т.д.
Далее мы этот скрипт можем уже редактировать, добавлять for-ы и т.д.
При наличии мощного анализатора можно в автоматизированном виде сворачивать последовательности однотипных действий в циклы.
СРВ --- вообще другая область деятельности.
Тебе тот же вопрос: и что можно сделать в граф. инт.?
Напоминаю: обсуждается вопрос местного собрания исходников.
---
...Я работаю антинаучным аферистом...
Тебе тот же вопрос: и что можно сделать в граф. инт.?
Напоминаю: обсуждается вопрос местного собрания исходников.
---
...Я работаю антинаучным аферистом...
> Сначала заводим понятия: форум, тред, сообщение и т.д.
От она, вербализация.
А теперь, забыл разработчик добавить интересное мне понятие (не потрудился например выделить
автора сообщения в отдельную сущность и всё, сосать - или переписывать код.
> Далее сажаем пользователя за Ie, отлавливаем мышь, получаем скрипт вида:
> открыть форум, зайти в раздел common, открыть непрочитанные сообщения в первом треде, во втором и т.д. выйти, зайти в раздел flood, открыть непрочитанные сообщения и
> т.д.
А я хочу в первую очередь читать сообщения от , а в получившемся скрипте нет упоминания авторов
открываемых сообщений.
А если разработчик не поленился и ввёл все понятия, то в скрипте их много получится, и глаза разбегутся.
> При наличии мощного анализатора можно в автоматизированном
> виде сворачивать последовательности однотипных действий в циклы.
Эта замена естественного интеллекта искусственным, который ещё не создан.
И теперь: где же примеры программ, позволяющих такое?
От она, вербализация.
А теперь, забыл разработчик добавить интересное мне понятие (не потрудился например выделить
автора сообщения в отдельную сущность и всё, сосать - или переписывать код.
> Далее сажаем пользователя за Ie, отлавливаем мышь, получаем скрипт вида:
> открыть форум, зайти в раздел common, открыть непрочитанные сообщения в первом треде, во втором и т.д. выйти, зайти в раздел flood, открыть непрочитанные сообщения и
> т.д.
А я хочу в первую очередь читать сообщения от , а в получившемся скрипте нет упоминания авторов
открываемых сообщений.
А если разработчик не поленился и ввёл все понятия, то в скрипте их много получится, и глаза разбегутся.
> При наличии мощного анализатора можно в автоматизированном
> виде сворачивать последовательности однотипных действий в циклы.
Эта замена естественного интеллекта искусственным, который ещё не создан.
И теперь: где же примеры программ, позволяющих такое?
Примеры:
Ms Office
Visual Studio
всякие макро записывалки (http://www.snapfiles.com/get/macroexpress.html
Visual Opc Validator (http://opctest.com/
в некоторой степени Microsoft Sql
зы
Основная масса программ, с которыми я работаю - такую фичу поддерживает.
Ms Office
Visual Studio
всякие макро записывалки (http://www.snapfiles.com/get/macroexpress.html
Visual Opc Validator (http://opctest.com/
в некоторой степени Microsoft Sql
зы
Основная масса программ, с которыми я работаю - такую фичу поддерживает.
Обычно, если gui-шная программа поддерживает скрипты, то предоставляется сервис и по записи такого скрипта.
> А теперь, забыл разработчик добавить интересное мне понятие (не потрудился например выделить
автора сообщения в отдельную сущность и всё, сосать - или переписывать код.
Есть два варианта:
1. Написать в службу поддержки
2. Добавить такое понятие самому
автора сообщения в отдельную сущность и всё, сосать - или переписывать код.
Есть два варианта:
1. Написать в службу поддержки
2. Добавить такое понятие самому
> Ms Office
очень интересно
вот выделил я мышой кусок текста
и что в записываемый макрос попадёт?
маза чтобы от получившейся записи была польза, нужно тыкать
не куда попало, а помогать программе - старательно искать слова среди картинок
ходить по меню не стрелками, а хоткеями - а то ведь, там нынче каждый раз всё в другом порядке
тот самый неестественный интеллект, который ты превозносишь (помогает нах выбирать из большого списка -
поубивал бы)
выбор из списка - не очень хорошая в этом плане операция, особенно
если каждый раз список содержит разное - обобщать только вручную
итак видим, что программа вроде одна и та же, и к тому же таки да, gui
но! стиль работы разный совершенно должен быть,
и в стиле, ориентированном на возможность автоматизации, от gui ничего не остаётся
очень интересно
вот выделил я мышой кусок текста
и что в записываемый макрос попадёт?
маза чтобы от получившейся записи была польза, нужно тыкать
не куда попало, а помогать программе - старательно искать слова среди картинок
ходить по меню не стрелками, а хоткеями - а то ведь, там нынче каждый раз всё в другом порядке
тот самый неестественный интеллект, который ты превозносишь (помогает нах выбирать из большого списка -
поубивал бы)
выбор из списка - не очень хорошая в этом плане операция, особенно
если каждый раз список содержит разное - обобщать только вручную
итак видим, что программа вроде одна и та же, и к тому же таки да, gui
но! стиль работы разный совершенно должен быть,
и в стиле, ориентированном на возможность автоматизации, от gui ничего не остаётся
> 2. Добавить такое понятие самому
И вот тут-то разницу между ручными операциями и автоматизацией ощущаешь по полной программе
И вот тут-то разницу между ручными операциями и автоматизацией ощущаешь по полной программе
Никто не обещал, что будет легко.
Но хотя бы такая генерялка макросов лучше, чем ручная писанина макросов с нуля.
По подобию всегда делать проще.
ps
Вот смотри, у нас есть консольная строка и есть, gui, возможности которого полностью дублируются из скрипта.
Внимание, вопрос: чем первое лучше, чем второе?
Чем лучше второе, я могу сказать - облегчается начальное освоение продукта.
pps
Уже на сегодняшний день видно, что из консольной строки выжали максимум.
Интересно, за последние 20-30 лет что-нибудь нового сделали?
В Gui-шних интерфейсах работы еще непочатый край, взять те же XUI, XAML-ы и т.д.
Но хотя бы такая генерялка макросов лучше, чем ручная писанина макросов с нуля.
По подобию всегда делать проще.
ps
Вот смотри, у нас есть консольная строка и есть, gui, возможности которого полностью дублируются из скрипта.
Внимание, вопрос: чем первое лучше, чем второе?
Чем лучше второе, я могу сказать - облегчается начальное освоение продукта.
pps
Уже на сегодняшний день видно, что из консольной строки выжали максимум.
Интересно, за последние 20-30 лет что-нибудь нового сделали?
В Gui-шних интерфейсах работы еще непочатый край, взять те же XUI, XAML-ы и т.д.
> Никто не обещал, что будет легко.
> Вот смотри, у нас есть консольная строка и есть, gui,
> возможности которого полностью дублируются из скрипта.
> Внимание, вопрос: чем первое лучше, чем второе?
> Чем лучше второе, я могу сказать - облегчается начальное освоение продукта.
Последнее ещё не установлено.
Есть примеры обратного. (Я присылал, вроде, ссылку на статью в OSNews.)
При использовании граф. инт. рассеивается внимание,
действуют неочевидные аналогии.
Так что даже начальное освоение не настолько уж облегчается, как это кажется.
Для ком. строки: внимание всегда сконцентрировано, действуют прямые аналогии с действительным миром.
При этом автоматизация проводится значительно проще.
> Уже на сегодняшний день видно, что из консольной строки выжали максимум.
Это тоже ещё неясно.
> Интересно, за последние 20-30 лет что-нибудь нового сделали?
Роб Пайк на это даёт ответ, но связывает это с победой Уникса.
Про то, что существует и не-Уникс, обычно забывают.
> В Gui-шних интерфейсах работы еще непочатый край,
> взять те же XUI, XAML-ы и т.д.
Тоже есть, что делать.
---
...Я работаю антинаучным аферистом...
> Вот смотри, у нас есть консольная строка и есть, gui,
> возможности которого полностью дублируются из скрипта.
> Внимание, вопрос: чем первое лучше, чем второе?
> Чем лучше второе, я могу сказать - облегчается начальное освоение продукта.
Последнее ещё не установлено.
Есть примеры обратного. (Я присылал, вроде, ссылку на статью в OSNews.)
При использовании граф. инт. рассеивается внимание,
действуют неочевидные аналогии.
Так что даже начальное освоение не настолько уж облегчается, как это кажется.
Для ком. строки: внимание всегда сконцентрировано, действуют прямые аналогии с действительным миром.
При этом автоматизация проводится значительно проще.
> Уже на сегодняшний день видно, что из консольной строки выжали максимум.
Это тоже ещё неясно.
> Интересно, за последние 20-30 лет что-нибудь нового сделали?
Роб Пайк на это даёт ответ, но связывает это с победой Уникса.
Про то, что существует и не-Уникс, обычно забывают.
> В Gui-шних интерфейсах работы еще непочатый край,
> взять те же XUI, XAML-ы и т.д.
Тоже есть, что делать.
---
...Я работаю антинаучным аферистом...
> Или опять же, настроить сеть в виндах на нескольких машинах, поставив каждой своё имя и свой IP (ну хорошо,
IP поставит DHCP, но ты включи его сначала своим сгенерированным скриптом)
Такая программа пишется довольно быстро, но ее не купят
довольно легко сделать на JavaScript + объекты MMC. Конечно, простой виндовый юзер это не осилит.
> довольно легко сделать на JavaScript + объекты MMC. Конечно, простой виндовый юзер это не осилит.
Это уже интересно.
Если настраивать скриптом довольно легко, то может выложить эти скрипты на сайте настроек,
вместо скриншотов?
И в "Рекомендациях" выложить скрипт, собирающий настройки, и приводящий их к вербальному
представлению, пригодному, чтобы запостить на форум (это с учётом того, что многие не знают,
как вызвать командную строку, и как потом оттуда скопировать результат на форум)?
Будет работать такое?
Это уже интересно.
Если настраивать скриптом довольно легко, то может выложить эти скрипты на сайте настроек,
вместо скриншотов?
И в "Рекомендациях" выложить скрипт, собирающий настройки, и приводящий их к вербальному
представлению, пригодному, чтобы запостить на форум (это с учётом того, что многие не знают,
как вызвать командную строку, и как потом оттуда скопировать результат на форум)?
Будет работать такое?
> Но хотя бы такая генерялка макросов лучше, чем ручная писанина макросов с нуля.
> По подобию всегда делать проще.
Смотри, что получается.
Пользователь работает с текстовой информацией (мультимедиа не учитываем, как я сразу написал).
Ему важна семантика.
И мыслит он об этом, соответственно, понятиями.
А в GUI - понятия заменяются на, грубо говоря, координаты.
Генерялка макросов преобразует координаты опять в понятия.
Это как общаться с человеком жестами и междометиями, вместо использования языка,
при этом оба собеседника умеют говорить, но не хотят.
Двойное преобразование искажает смысл, так как вербализацию проводит компьютер,
а он умеет это сильно хуже человека.
Чтобы справиться с этим, человеку приходится моделировать внутри своей головы
поведение компьютера, чтобы после автоматической вербализации получить те понятия,
которые ему нужны, хотя они уже есть у него в голове, и можно было бы сразу их написать.
В случае CLI такая генерилка не нужна, просто берешь команды из истории.
> Вот смотри, у нас есть консольная строка и есть, gui, возможности которого полностью дублируются из скрипта.
В таком случае, имеем фактически два продукта.
Дублирование требует постоянных усилий разработчиков по синхронизации возможностей.
Другое дело - когда GUI фактически генерируется автоматически, примерно как customize в emacs.
> Внимание, вопрос: чем первое лучше, чем второе?
> Чем лучше второе, я могу сказать - облегчается начальное освоение продукта.
Объясняю.
Имеем два интерфейса вместо одного, и если требуется автоматизация деятельности,
то придётся изучать их оба.
GUI при этом может затруднять жизнь - из-за неестественного интеллекта - двойного преобразования.
Пример: конфигурационный файл vs. семейство диалоговых окон для настройки.
Файл может содержать комментарии - чтоб ты не забыл, зачем ты настроил именно так,
и чтобы другие могли понять это в случае необходимости.
В файле можно искать по ключевым словам, вместо бегания по менюшкам и напрягания глаз.
Файл можно сгенерировать, если писать руками надоело.
Можно запостить его на форум, послать почтой, продиктовать по телефону - текст - великая вещь.
Язык и письменность не зря придумали.
В случае GUI про него в таких случаях приходится забывать и изучать текстовое представление.
> Чем лучше второе, я могу сказать - облегчается начальное освоение продукта.
Довольно часто это лишь иллюзия облегчения.
Исключение - если задача очень хорошо формализована, тогда пользователю
действительно нужно только то, что даёт GUI.
Какие нибудь кассовые аппараты, пульт управления танком и т.п.
Дублирование работы (создание двух интерфейсов) - требует ресурсов.
Возникает соблазн подзабить на один из них.
Если программа пишется для продажи - смотрят на красоту гуя, добавляют
летающих розовых слонов и т.п.
Решение о покупке, как правило, принимается до изучения способов работы с текстовым представлением,
поэтому часто оно неудобно.
Пример: хранение настроек в registry.
Комментарии вставлять некуда, имена ключей неинформативны (так что поиск не поможет) -
разработчик не предполагал никаких способов работы, помимо GUI.
Если программа пишется для использования - можно забить на GUI,
начальное освоение неактуально.
> Уже на сегодняшний день видно, что из консольной строки выжали максимум.
> Интересно, за последние 20-30 лет что-нибудь нового сделали?
Уже на сегодняшний день видно, что возможности языка исчерпаны.
За последние 1000 лет ничего существенно нового не написали.
> По подобию всегда делать проще.
Смотри, что получается.
Пользователь работает с текстовой информацией (мультимедиа не учитываем, как я сразу написал).
Ему важна семантика.
И мыслит он об этом, соответственно, понятиями.
А в GUI - понятия заменяются на, грубо говоря, координаты.
Генерялка макросов преобразует координаты опять в понятия.
Это как общаться с человеком жестами и междометиями, вместо использования языка,
при этом оба собеседника умеют говорить, но не хотят.
Двойное преобразование искажает смысл, так как вербализацию проводит компьютер,
а он умеет это сильно хуже человека.
Чтобы справиться с этим, человеку приходится моделировать внутри своей головы
поведение компьютера, чтобы после автоматической вербализации получить те понятия,
которые ему нужны, хотя они уже есть у него в голове, и можно было бы сразу их написать.
В случае CLI такая генерилка не нужна, просто берешь команды из истории.
> Вот смотри, у нас есть консольная строка и есть, gui, возможности которого полностью дублируются из скрипта.
В таком случае, имеем фактически два продукта.
Дублирование требует постоянных усилий разработчиков по синхронизации возможностей.
Другое дело - когда GUI фактически генерируется автоматически, примерно как customize в emacs.
> Внимание, вопрос: чем первое лучше, чем второе?
> Чем лучше второе, я могу сказать - облегчается начальное освоение продукта.
Объясняю.
Имеем два интерфейса вместо одного, и если требуется автоматизация деятельности,
то придётся изучать их оба.
GUI при этом может затруднять жизнь - из-за неестественного интеллекта - двойного преобразования.
Пример: конфигурационный файл vs. семейство диалоговых окон для настройки.
Файл может содержать комментарии - чтоб ты не забыл, зачем ты настроил именно так,
и чтобы другие могли понять это в случае необходимости.
В файле можно искать по ключевым словам, вместо бегания по менюшкам и напрягания глаз.
Файл можно сгенерировать, если писать руками надоело.
Можно запостить его на форум, послать почтой, продиктовать по телефону - текст - великая вещь.
Язык и письменность не зря придумали.
В случае GUI про него в таких случаях приходится забывать и изучать текстовое представление.
> Чем лучше второе, я могу сказать - облегчается начальное освоение продукта.
Довольно часто это лишь иллюзия облегчения.
Исключение - если задача очень хорошо формализована, тогда пользователю
действительно нужно только то, что даёт GUI.
Какие нибудь кассовые аппараты, пульт управления танком и т.п.
Дублирование работы (создание двух интерфейсов) - требует ресурсов.
Возникает соблазн подзабить на один из них.
Если программа пишется для продажи - смотрят на красоту гуя, добавляют
летающих розовых слонов и т.п.
Решение о покупке, как правило, принимается до изучения способов работы с текстовым представлением,
поэтому часто оно неудобно.
Пример: хранение настроек в registry.
Комментарии вставлять некуда, имена ключей неинформативны (так что поиск не поможет) -
разработчик не предполагал никаких способов работы, помимо GUI.
Если программа пишется для использования - можно забить на GUI,
начальное освоение неактуально.
> Уже на сегодняшний день видно, что из консольной строки выжали максимум.
> Интересно, за последние 20-30 лет что-нибудь нового сделали?
Уже на сегодняшний день видно, что возможности языка исчерпаны.
За последние 1000 лет ничего существенно нового не написали.
> В таком постановке задача плохо решаема, так как html не несет в себе высокоуровневой семантики.
Вот это и есть уеб-анство.
Выбрали HTML, потому что он ориентирован на GUI - показать картинку и всё.
Естественно, для общения с помощью команд выбрали бы другой язык.
Вот это и есть уеб-анство.
Выбрали HTML, потому что он ориентирован на GUI - показать картинку и всё.
Естественно, для общения с помощью команд выбрали бы другой язык.
> Пользователь работает с текстовой информацией (мультимедиа не учитываем, как я сразу написал).
Подменяешь понятия.
Пользователь работает с символами(образами).
Текст - это один из способов зафиксировать эти символы(образы) на "бумаге".
> И мыслит он об этом, соответственно, понятиями.
вот, именно.
> А в GUI - понятия заменяются на, грубо говоря, координаты.
Тоже самое можно сказать и о тексте. Понятие заменяются на их упрощенные текстовые термины.
ps Был же разговор о том, почему часто используют англоязычные термины, а не русские слова.
Есть, например, понятие "форум".
Какая разница в следующих вариантах ввода этого понятия в компьютер
набор в виде текста,
набор в виде текста с возможностью автодополнения,
выбором из выпадающего списка,
перетаскиванием из палитры,
нажатием соответствующей кнопки.
Замечу, что у просто набора в виде текста, есть следующий недостаток:
человек и компьютер могут друг друга не понять, т.к. у них разные текстовые представления одного и того же понятия.
т.к. у человека для понятие "форум" текстовое представление может быть "forum", а у компьютера "phorum".
Подходим к основной проблеме:
я хочу "сказать" понятие "форум" при этом я знаю, что в текстовом виде оно представимо, как "форум", "forum", "phorum", "сообщество", "интернет-форум" и т.д.
Какое из этих текстовых представлений мне вводить?
И как быстро узнать какой из этих терминов используется в данном случае.
Ключевое слово - быстро, т.е. не читая каждый раз документацию и т.д.
Особенно это проявляется, если приходится общаться сразу с несколькими системами, у каждой из которых свои предпочтения.
Пример из практики: я знаю где-то в районе 20-30 языков программирования. Если я каким-либо языком пару месяцев не пользовался, то на таком языке по памяти написать синтаксически правильную программу я просто физически не смогу.
замечу, что эта проблема не только общения человек<->компьютер, но и любого произвольного общения агент<->агент, когда у агентов пространство терминов совпадает только частично.
> Пример: конфигурационный файл vs. семейство диалоговых окон для настройки.
> Файл может содержать комментарии - чтоб ты не забыл, зачем ты настроил именно так,
Это проблема не GUI, а проблема автоматизированных преобразований.
т.к. если этот же скрипт придется автоматически преобразовывать в другой, то комментарии таким же чудесным образом похерятся.
В программирование есть такое понятие рефакторинг - полуавтоматическое изменение кода, замечено, что комментарии и рефакторинг вместе не живут. Это вызвано в первую очередь тем, что комментарии семантически никак не связаны с кодом.
есть мнение, что комментарии бесполезны, когда над одним и тем же куском кода работают несколько программистов, т.к. некому поддерживать соответствие между комментариями и реальным кодом.
А ведь в данном случае мы как раз двух участников и имеем: с одной стороны - это человек, с другой стороны - это программа, и каждый из них по своему правит код.
Комментарии должны быть выражены средствами языка.
> Другое дело - когда GUI фактически генерируется автоматически, примерно как customize в emacs.
К этому все и идет, вернее идет к наличию семантической связи между GUI и внутренними понятиями программы.
Подменяешь понятия.
Пользователь работает с символами(образами).
Текст - это один из способов зафиксировать эти символы(образы) на "бумаге".
> И мыслит он об этом, соответственно, понятиями.
вот, именно.
> А в GUI - понятия заменяются на, грубо говоря, координаты.
Тоже самое можно сказать и о тексте. Понятие заменяются на их упрощенные текстовые термины.
ps Был же разговор о том, почему часто используют англоязычные термины, а не русские слова.
Есть, например, понятие "форум".
Какая разница в следующих вариантах ввода этого понятия в компьютер
набор в виде текста,
набор в виде текста с возможностью автодополнения,
выбором из выпадающего списка,
перетаскиванием из палитры,
нажатием соответствующей кнопки.
Замечу, что у просто набора в виде текста, есть следующий недостаток:
человек и компьютер могут друг друга не понять, т.к. у них разные текстовые представления одного и того же понятия.
т.к. у человека для понятие "форум" текстовое представление может быть "forum", а у компьютера "phorum".
Подходим к основной проблеме:
я хочу "сказать" понятие "форум" при этом я знаю, что в текстовом виде оно представимо, как "форум", "forum", "phorum", "сообщество", "интернет-форум" и т.д.
Какое из этих текстовых представлений мне вводить?
И как быстро узнать какой из этих терминов используется в данном случае.
Ключевое слово - быстро, т.е. не читая каждый раз документацию и т.д.
Особенно это проявляется, если приходится общаться сразу с несколькими системами, у каждой из которых свои предпочтения.
Пример из практики: я знаю где-то в районе 20-30 языков программирования. Если я каким-либо языком пару месяцев не пользовался, то на таком языке по памяти написать синтаксически правильную программу я просто физически не смогу.
замечу, что эта проблема не только общения человек<->компьютер, но и любого произвольного общения агент<->агент, когда у агентов пространство терминов совпадает только частично.
> Пример: конфигурационный файл vs. семейство диалоговых окон для настройки.
> Файл может содержать комментарии - чтоб ты не забыл, зачем ты настроил именно так,
Это проблема не GUI, а проблема автоматизированных преобразований.
т.к. если этот же скрипт придется автоматически преобразовывать в другой, то комментарии таким же чудесным образом похерятся.
В программирование есть такое понятие рефакторинг - полуавтоматическое изменение кода, замечено, что комментарии и рефакторинг вместе не живут. Это вызвано в первую очередь тем, что комментарии семантически никак не связаны с кодом.
есть мнение, что комментарии бесполезны, когда над одним и тем же куском кода работают несколько программистов, т.к. некому поддерживать соответствие между комментариями и реальным кодом.
А ведь в данном случае мы как раз двух участников и имеем: с одной стороны - это человек, с другой стороны - это программа, и каждый из них по своему правит код.
Комментарии должны быть выражены средствами языка.
> Другое дело - когда GUI фактически генерируется автоматически, примерно как customize в emacs.
К этому все и идет, вернее идет к наличию семантической связи между GUI и внутренними понятиями программы.
> Выбрали HTML, потому что он ориентирован на GUI - показать картинку и всё.
Выбрали HTML потому что, его можно было легко обработать на клиентском компьютере.
Чем на более высокоуровневом языке мы пишем, тем более мощный компьютер необходимо для его исполнения.
Позапозавчерашних клиентских компьютеров хвататало только на консоль и маш. код.
Позавчерашних хватило на html и маш. код.
Вчерашних хватило на html и byte-код.
Сегодняшних хватает на xml (XUI, XAML) и byte-код.
На что хватит завтрашних?
Ведь и сейчас в программе на верхнем уровне пишется "хочу чтобы здесь ввели то, то и немножко этого".
Есть толстые книжки в которых расписывается, как это лучше отобразить на GUI.
Но у компьютера пока не хватает мощности все эти правила выполнить, поэтому в качестве исполнителя брать кодера, который выполняет правила описанные в книжке и рисует Gui.
Выбрали HTML потому что, его можно было легко обработать на клиентском компьютере.
Чем на более высокоуровневом языке мы пишем, тем более мощный компьютер необходимо для его исполнения.
Позапозавчерашних клиентских компьютеров хвататало только на консоль и маш. код.
Позавчерашних хватило на html и маш. код.
Вчерашних хватило на html и byte-код.
Сегодняшних хватает на xml (XUI, XAML) и byte-код.
На что хватит завтрашних?
Ведь и сейчас в программе на верхнем уровне пишется "хочу чтобы здесь ввели то, то и немножко этого".
Есть толстые книжки в которых расписывается, как это лучше отобразить на GUI.
Но у компьютера пока не хватает мощности все эти правила выполнить, поэтому в качестве исполнителя брать кодера, который выполняет правила описанные в книжке и рисует Gui.
> Сегодняшних хватает на xml (XUI, XAML) и byte-код.
Не хватает и на HTML сегодняшних компов.
Браузеры тормозят, работать некомфортно.
Не хватает и на HTML сегодняшних компов.
Браузеры тормозят, работать некомфортно.
в первую очередь, это связано с тем, что в низкоуровневый язык (html) пытаются засунуть высокоуровневую логику: подстраивание под пользователя: выпадающие менюшки, хитрые вводы информации и т.д.
не-а
даже статический код долго рендерится
потому что язык ублюдочный
даже статический код долго рендерится
потому что язык ублюдочный
html ориентирован под табличный вывод информации.
Поэтому когда необходимо нетабличное отображение информации, начинается шаманство, которое все понимают по разному.
ps
В html-е сильно не хватает Layouter-ов отличных от табличного.
Поэтому когда необходимо нетабличное отображение информации, начинается шаманство, которое все понимают по разному.
ps
В html-е сильно не хватает Layouter-ов отличных от табличного.
Что значит долго? Примеры, плиз.
Долго - значит пауза заметна глазу.
Таблицы бывает по десятку секунд рендерятся.
И так уже лет пять, тормознутость браузеров догоняет прогресс железа.
Таблицы бывает по десятку секунд рендерятся.
И так уже лет пять, тормознутость браузеров догоняет прогресс железа.
> Таблицы бывает по десятку секунд рендерятся.
Это ты где такие таблицы нашел? и на каком компе браузер бегает?
ps
Для таких случаев html-ю помогло бы индексация, которая делается в 3d-сценах, т.е. когда по html-ю генерится сначала общий каркас, потом более детальный, потом еще детальнее и т.д. Такие индексы можно класть в начале файла.
pps
Но на html-я в страницу, в две - это не даст особого выигрыша, а многостраничные html-и редко используются (вернее там уже другие требования и проблемы).
Это ты где такие таблицы нашел? и на каком компе браузер бегает?
ps
Для таких случаев html-ю помогло бы индексация, которая делается в 3d-сценах, т.е. когда по html-ю генерится сначала общий каркас, потом более детальный, потом еще детальнее и т.д. Такие индексы можно класть в начале файла.
pps
Но на html-я в страницу, в две - это не даст особого выигрыша, а многостраничные html-и редко используются (вернее там уже другие требования и проблемы).
В первую, очередь твои высказания сводятся к тому, что Gui - это плохо, потому что GUI-шные программы можно написать плохо, а консоль - это рулез, потому что там сложнее сделать неавтоматизируемые программы.
Причем для сравнения ты берешь хорошо спроектированную консоль (ту же nix-овую) и ей противопоставляешь плохо спроектированный GUI.
ps Плохоспроектированная консоль тоже встречается сплошь и рядом. Например, программа на все ошибки говорит "вы ввели неправильные данные" или вообще ничего не говорит, а документации нет или там написано два слова.
Фактически ты проводишь запретительную политику: давайте мы им все запретим, а то не дай бог они что-нибудь не так сделают.
AFAIK, конструктивнее "разрешительная" политика, т.е. в данном случае: чтобы такого сделать, чтобы gui-программы можно было тоже легко автоматизировать.
Причем для сравнения ты берешь хорошо спроектированную консоль (ту же nix-овую) и ей противопоставляешь плохо спроектированный GUI.
ps Плохоспроектированная консоль тоже встречается сплошь и рядом. Например, программа на все ошибки говорит "вы ввели неправильные данные" или вообще ничего не говорит, а документации нет или там написано два слова.
Фактически ты проводишь запретительную политику: давайте мы им все запретим, а то не дай бог они что-нибудь не так сделают.
AFAIK, конструктивнее "разрешительная" политика, т.е. в данном случае: чтобы такого сделать, чтобы gui-программы можно было тоже легко автоматизировать.
> Пользователь работает с символами(образами).
... которые существуют только у него в голове.
Поэтому нужен способ коммуникации.
Язык - наиболее универсальный из известных способов.
В случае работы с компьютером - формальный язык, так как
других компьютер не понимает.
Поэтому мой тезис такой: текстовое представление понятий должно быть основным,
а все остальные - вспомогательными, как иллюстрации в книгах.
> Есть, например, понятие "форум".
> Какая разница в следующих вариантах ввода этого понятия в компьютер ...
Разница в том, что разные способы удобны в разных ситуациях.
И поэтому представляется правильным иметь возможность использовать любой из них.
Хорошый формальный язык, используемый в качестве основного представления,
даёт такую возможность: можно и гуй прикрутить, и автоматически генерировать.
Если же внутреннее представление разработчиком не вынесено в качестве интерфейса,
то можно использовать лишь те способы, которые он заранее предусмотрел.
> Подходим к основной проблеме:
> я хочу "сказать" понятие "форум" при этом я знаю, что в текстовом виде оно представимо, как "форум", "forum", "phorum", "сообщество", > "интернет-форум" и т.д.
Компьютеры понимают только формальные языки, от этого никуда не деться.
> И как быстро узнать какой из этих терминов используется в данном случае.
> Ключевое слово - быстро, т.е. не читая каждый раз документацию и т.д.
Использовать различного рода готовые шаблоны.
GUI - один из вариантов, но довольно негибкий.
Бывают ещё, например, редакторы с настройкой под язык, и примеры конфигов,
где все возможные опции закоментированны, и можно раскомментировать требуемые.
Текстовое представление (всякие registry и базы данных тоже отнесём к ним,
разница лишь количественная, в удобстве ручного и автоматического изменения)
даёт возможность легко надстраивать различные интерфейсы сверху,
и чем оно продуманней, тем легче.
> замечу, что эта проблема не только общения человек<->компьютер, но и любого произвольного общения агент<->агент,
> когда у агентов пространство терминов совпадает только частично.
текст на формальном языке преобразовать гораздо проще, однако,
чем перенести данные из одного набора диалогов и визардов в другой
> т.к. если этот же скрипт придется автоматически преобразовывать в другой, то комментарии таким же чудесным образом похерятся.
а если не придётся, то они останутся
Поэтому, другой мой тезис такой: следует по возможности разделять текст, создаваемый человеком (исходник
и сгенерированный. Все комментарии - в исходниках.
> К этому все и идет, вернее идет к наличию семантической связи между GUI и внутренними понятиями программы.
Мне, со стороны, никаких радостных тенденций не заметно.
Гуи удобнее не становятся.
> В первую, очередь твои высказания сводятся к тому, что Gui - это плохо,
> потому что GUI-шные программы можно написать плохо, а консоль - это рулез,
> потому что там сложнее сделать неавтоматизируемые программы.
Повторю тезис: плохи те GUI, которые задуманы как основной способ коммуникации
вербально представляемой информации.
Хороши могут быть те, которые помогают пользователю перевести его задачи
в понятный компьютеру формальный язык, если при этом язык является
первичным средством коммуникации.
... которые существуют только у него в голове.
Поэтому нужен способ коммуникации.
Язык - наиболее универсальный из известных способов.
В случае работы с компьютером - формальный язык, так как
других компьютер не понимает.
Поэтому мой тезис такой: текстовое представление понятий должно быть основным,
а все остальные - вспомогательными, как иллюстрации в книгах.
> Есть, например, понятие "форум".
> Какая разница в следующих вариантах ввода этого понятия в компьютер ...
Разница в том, что разные способы удобны в разных ситуациях.
И поэтому представляется правильным иметь возможность использовать любой из них.
Хорошый формальный язык, используемый в качестве основного представления,
даёт такую возможность: можно и гуй прикрутить, и автоматически генерировать.
Если же внутреннее представление разработчиком не вынесено в качестве интерфейса,
то можно использовать лишь те способы, которые он заранее предусмотрел.
> Подходим к основной проблеме:
> я хочу "сказать" понятие "форум" при этом я знаю, что в текстовом виде оно представимо, как "форум", "forum", "phorum", "сообщество", > "интернет-форум" и т.д.
Компьютеры понимают только формальные языки, от этого никуда не деться.
> И как быстро узнать какой из этих терминов используется в данном случае.
> Ключевое слово - быстро, т.е. не читая каждый раз документацию и т.д.
Использовать различного рода готовые шаблоны.
GUI - один из вариантов, но довольно негибкий.
Бывают ещё, например, редакторы с настройкой под язык, и примеры конфигов,
где все возможные опции закоментированны, и можно раскомментировать требуемые.
Текстовое представление (всякие registry и базы данных тоже отнесём к ним,
разница лишь количественная, в удобстве ручного и автоматического изменения)
даёт возможность легко надстраивать различные интерфейсы сверху,
и чем оно продуманней, тем легче.
> замечу, что эта проблема не только общения человек<->компьютер, но и любого произвольного общения агент<->агент,
> когда у агентов пространство терминов совпадает только частично.
текст на формальном языке преобразовать гораздо проще, однако,
чем перенести данные из одного набора диалогов и визардов в другой
> т.к. если этот же скрипт придется автоматически преобразовывать в другой, то комментарии таким же чудесным образом похерятся.
а если не придётся, то они останутся
Поэтому, другой мой тезис такой: следует по возможности разделять текст, создаваемый человеком (исходник
и сгенерированный. Все комментарии - в исходниках.
> К этому все и идет, вернее идет к наличию семантической связи между GUI и внутренними понятиями программы.
Мне, со стороны, никаких радостных тенденций не заметно.
Гуи удобнее не становятся.
> В первую, очередь твои высказания сводятся к тому, что Gui - это плохо,
> потому что GUI-шные программы можно написать плохо, а консоль - это рулез,
> потому что там сложнее сделать неавтоматизируемые программы.
Повторю тезис: плохи те GUI, которые задуманы как основной способ коммуникации
вербально представляемой информации.
Хороши могут быть те, которые помогают пользователю перевести его задачи
в понятный компьютеру формальный язык, если при этом язык является
первичным средством коммуникации.
> Повторю тезис: плохи те GUI, которые задуманы как основной способ коммуникации
> вербально представляемой информации.
Если слово "вербально" выкинуть, то согласен.
> Хороши могут быть те, которые помогают пользователю перевести его задачи
> в понятный компьютеру формальный язык, если при этом язык является
> первичным средством коммуникации.
Согласен.
Только замечу, что классическая командная строка в этих случаях себя тоже плохо чувствует, т.к. современные языки неплоские по своей сути, а командная строка ориентирована на плоские языки.
> вербально представляемой информации.
Если слово "вербально" выкинуть, то согласен.
> Хороши могут быть те, которые помогают пользователю перевести его задачи
> в понятный компьютеру формальный язык, если при этом язык является
> первичным средством коммуникации.
Согласен.
Только замечу, что классическая командная строка в этих случаях себя тоже плохо чувствует, т.к. современные языки неплоские по своей сути, а командная строка ориентирована на плоские языки.
> Если слово "вербально" выкинуть, то согласен.
Ну для мультимедии всякой других вариантов не видно.
> Только замечу, что классическая командная строка в этих случаях себя тоже плохо чувствует,
> т.к. современные языки неплоские по своей сути, а командная строка ориентирована на плоские языки.
Что ты называешь "классической"?
Что-то вроде цисковского cli и прочего?
Потому что в unix можно ведь редактировать тексты с помощью любого из двух редакторов,
каждый из которых настраивается под язык, помогая формализации.
В случае unix shell - историю команд загрузить в редактор легко (есть несколько способов
добавляешь условия, циклы - готов скрипт. Вот с отладкой скриптов могло бы быть
и получше, правда может я каких фичей и не знаю.
Модные шеллы, опять же, имеют расширяемый язык и расширяемый редактор команд,
с настраиваемыми автодополнениями, но тут я тоже не разбирался.
Ну для мультимедии всякой других вариантов не видно.
> Только замечу, что классическая командная строка в этих случаях себя тоже плохо чувствует,
> т.к. современные языки неплоские по своей сути, а командная строка ориентирована на плоские языки.
Что ты называешь "классической"?
Что-то вроде цисковского cli и прочего?
Потому что в unix можно ведь редактировать тексты с помощью любого из двух редакторов,
каждый из которых настраивается под язык, помогая формализации.
В случае unix shell - историю команд загрузить в редактор легко (есть несколько способов
добавляешь условия, циклы - готов скрипт. Вот с отладкой скриптов могло бы быть
и получше, правда может я каких фичей и не знаю.
Модные шеллы, опять же, имеют расширяемый язык и расширяемый редактор команд,
с настраиваемыми автодополнениями, но тут я тоже не разбирался.
> Объясните бля через форум или того хуже по телефону челу, как сеть в виндах настроить.
> Хрен обойдёшься без скриншотов, да и те часто бесполезны, так как в немного другой
на спор объясню человеку любого уровня подготовленности, как настроить сеть под виндой.
> версии контролы по окошкам по другому расставят - и всё.
это _твоя_ задача, как админа, знать где какие кнопочки расположены. Если ты запоминает последовательность консольных команд лучше, чем расположение кнопок - это еще не значит, что все такие
> unix way: пользователь говорит компьютеру, что тот должен сделать
Какой командой под юниксом объяснить компьютеру, чтобы он сгонял за пивом?
Из под консоли ты тоже выбираешь только из рарешенных действий - наборов комманд/скриптов. Вылезти за рамки не можешь... Вопрос в границах этих рамок...
> microsoft way: пользователь выбирает из списка разрешённых действий
Никто никогда не читает факинг мануал... Оттого и думают, что что-то сделать нельзя...
Все что нельзя сделать стандартными средствами - можно напрограммировать. Написание коммандной строки (а тем более скриптов) - это программирование. А программить пока придумали только в тексте. Как придумают, как программить в ГУИ - тогда и можно их сравнивать.
> Потому что вместо естественного вербального представления используют
> образы и жесты (ткнуть мышой в вариант из списка - это жест,
Позволю себе напомнить, что эволюцонно сначала изобрели общение жестами - это у человека практически с рождения. А вот говорить еще научить надо...
И мыслит человек исключительно образами, а не как уж не буквами и не цифрами... А не надо пытаться сделать из человека подобие машины...
У человека, между прочим 3-хмерное восприятие. ГУИ - это 2D. Консоль - 1D. Зачем ограничивать себя?
И не надо приводить доводы, что кругом говнокодеры нагвонокодили говногоры говноинтерфейсов.
Просто и под ГУИ надо уметь программировать...
> А вот, вспомнил исключение: старый AutoCAD (под DOS, новых не видел).
Это назывется грамотный симбиоз...
По мне, так самый идеальный интерфейс - это когда любую команду можно сделать, как посредством команд с клавы, так и при помощи мышки (ввод текста не считается). Майкрософт, между прочим придерживается этого правила. Иногда, правда, бывает, что с консолью удобней... тогда приходят на помощь множество тулзов. Плюс юнихов перед виндой в том, что в них заранее заложен большой набор удобных тулзов. В этом различия интерфейса заканчиваются. Скрипты писать можно и под виндой - благо выбор языков в WSE достаточно большой. Вот чего винде не хватает - так это удобного механизма клавиатурных/мышиных макросов.
> Хрен обойдёшься без скриншотов, да и те часто бесполезны, так как в немного другой
на спор объясню человеку любого уровня подготовленности, как настроить сеть под виндой.
> версии контролы по окошкам по другому расставят - и всё.
это _твоя_ задача, как админа, знать где какие кнопочки расположены. Если ты запоминает последовательность консольных команд лучше, чем расположение кнопок - это еще не значит, что все такие
> unix way: пользователь говорит компьютеру, что тот должен сделать
Какой командой под юниксом объяснить компьютеру, чтобы он сгонял за пивом?
Из под консоли ты тоже выбираешь только из рарешенных действий - наборов комманд/скриптов. Вылезти за рамки не можешь... Вопрос в границах этих рамок...
> microsoft way: пользователь выбирает из списка разрешённых действий
Никто никогда не читает факинг мануал... Оттого и думают, что что-то сделать нельзя...
Все что нельзя сделать стандартными средствами - можно напрограммировать. Написание коммандной строки (а тем более скриптов) - это программирование. А программить пока придумали только в тексте. Как придумают, как программить в ГУИ - тогда и можно их сравнивать.
> Потому что вместо естественного вербального представления используют
> образы и жесты (ткнуть мышой в вариант из списка - это жест,
Позволю себе напомнить, что эволюцонно сначала изобрели общение жестами - это у человека практически с рождения. А вот говорить еще научить надо...
И мыслит человек исключительно образами, а не как уж не буквами и не цифрами... А не надо пытаться сделать из человека подобие машины...
У человека, между прочим 3-хмерное восприятие. ГУИ - это 2D. Консоль - 1D. Зачем ограничивать себя?
И не надо приводить доводы, что кругом говнокодеры нагвонокодили говногоры говноинтерфейсов.
Просто и под ГУИ надо уметь программировать...
> А вот, вспомнил исключение: старый AutoCAD (под DOS, новых не видел).
Это назывется грамотный симбиоз...
По мне, так самый идеальный интерфейс - это когда любую команду можно сделать, как посредством команд с клавы, так и при помощи мышки (ввод текста не считается). Майкрософт, между прочим придерживается этого правила. Иногда, правда, бывает, что с консолью удобней... тогда приходят на помощь множество тулзов. Плюс юнихов перед виндой в том, что в них заранее заложен большой набор удобных тулзов. В этом различия интерфейса заканчиваются. Скрипты писать можно и под виндой - благо выбор языков в WSE достаточно большой. Вот чего винде не хватает - так это удобного механизма клавиатурных/мышиных макросов.
Я бы посмотрел на дизайнера за командной строкой. 
Создаётся впечатление, что кое-кто не дочитал тред, на такое отвечать не хочется.
Как придумают, как программить в ГУИ - тогда и можно их сравнивать
LabView.
Иногда удобно, но когда размер проги увеличивается, что-либо отладить уже становится почти нереально.
я просто _частично_ повторил уже написанное, но и добавил нового от себя..
> на спор объясню человеку любого уровня подготовленности, как настроить сеть под виндой.
объяснишь, верю
но сколько циклов обмена (round trips) понадобится, чтобы обменяться не относящейся к делу информацией
о расположении контролов?
> это _твоя_ задача, как админа, знать где какие кнопочки расположены.
> Если ты запоминает последовательность консольных команд лучше, чем расположение кнопок - это еще не значит, что все такие
Подмена понятий и уход от темы.
В рассматриваемом случае админом является тот, кому объясняют.
Что он лучше запоминает, не имеет значения, пока ему не объяснили, что запоминать.
Я, который объясняет, могу сколько угодно помнить расположений кнопок, но задача - не вспомнить, а объяснить.
Обсуждали коммуникацию, а не запоминание.
Язык придумали для коммуникации.
Письменность придумали для коммуникации, когда участники разделены в пространстве-времени.
Это самые эффективные из известных средств коммуникации.
> Какой командой под юниксом объяснить компьютеру, чтобы он сгонял за пивом?
Как только будет у компьютера такая возможность, сразу появится и команда.
> Из под консоли ты тоже выбираешь только из рарешенных действий - наборов комманд/скриптов.
> Вылезти за рамки не можешь... Вопрос в границах этих рамок...
Язык позволяет задать любое действие, на которое способен компьютер.
GUI позволяет задать действие, предусмотренное разработчиком.
> Никто никогда не читает факинг мануал... Оттого и думают, что что-то сделать нельзя...
Скажем так, в данном случае не "думают, что нельзя", а "не думают, что можно".
В списке перечислено всё, думать вроде и незачем.
> Все что нельзя сделать стандартными средствами - можно напрограммировать. Написание коммандной строки (а тем более скриптов) - это программирование.
> А программить пока придумали только в тексте.
> Как придумают, как программить в ГУИ - тогда и можно их сравнивать.
Приходится сравнивать, когда GUI продвигается как основное средство коммуникации.
> Позволю себе напомнить, что эволюцонно сначала изобрели общение жестами - это у человека практически с рождения.
> А вот говорить еще научить надо...
Вот и надо учить говорить, а не только объясняться жестами.
> И мыслит человек исключительно образами, а не как уж не буквами и не цифрами...
Про отличия мышления от коммуникации уже обсудили.
> У человека, между прочим 3-хмерное восприятие.
И как этим пользоваться для коммуникации символьной информации?
Скульптурами обмениваться?
> ГУИ - это 2D. Консоль - 1D. Зачем ограничивать себя?
Это только один из параметров, описывающий пространство.
И тут ты не прав: "консоль" содержит дисплей, который вполне себе двумерный.
> И не надо приводить доводы, что кругом говнокодеры нагвонокодили говногоры говноинтерфейсов.
> Просто и под ГУИ надо уметь программировать...
И умение это должно заключаться в том, чтобы найти те подзадачи, где оно реально помогает.
И не настаивать на использовании конкретного варианта там, где он может помешать.
Иначе говноинтерфейс и получается.
> По мне, так самый идеальный интерфейс - это когда любую команду можно сделать,
> как посредством команд с клавы, так и при помощи мышки (ввод текста не считается).
Не-а. Идеальный вариант - когда всё делается само.
Практически достижимое приближение к идеалу - когда один раз объясняешь, что делать, а дальше само.
(Не надо понимать, что совсем само - значит обязательно неинтерактивно, это всего лишь объясняет, что
человеку остаётся творческая часть, которую автоматизировать пока не умеют).
Поэтому хороший вариант - тот, который облегчает это объяснение.
У GUI с этим - принципиальные трудности - необходимость двойного преобразования.
Поэтому и:
> Вот чего винде не хватает - так это удобного механизма клавиатурных/мышиных макросов.
Но хороший интерфейс должен включать возможность использовать GUI там, где это удобно,
что как правило означает - после достаточной формализации задачи.
Если задача формализуется уже пользователем, и для неё оказывается удобно GUI,
значит надо дать возможность его построить.
И удобные средства есть, что характерно, например tcl/tk.
объяснишь, верю
но сколько циклов обмена (round trips) понадобится, чтобы обменяться не относящейся к делу информацией
о расположении контролов?
> это _твоя_ задача, как админа, знать где какие кнопочки расположены.
> Если ты запоминает последовательность консольных команд лучше, чем расположение кнопок - это еще не значит, что все такие
Подмена понятий и уход от темы.
В рассматриваемом случае админом является тот, кому объясняют.
Что он лучше запоминает, не имеет значения, пока ему не объяснили, что запоминать.
Я, который объясняет, могу сколько угодно помнить расположений кнопок, но задача - не вспомнить, а объяснить.
Обсуждали коммуникацию, а не запоминание.
Язык придумали для коммуникации.
Письменность придумали для коммуникации, когда участники разделены в пространстве-времени.
Это самые эффективные из известных средств коммуникации.
> Какой командой под юниксом объяснить компьютеру, чтобы он сгонял за пивом?
Как только будет у компьютера такая возможность, сразу появится и команда.
> Из под консоли ты тоже выбираешь только из рарешенных действий - наборов комманд/скриптов.
> Вылезти за рамки не можешь... Вопрос в границах этих рамок...
Язык позволяет задать любое действие, на которое способен компьютер.
GUI позволяет задать действие, предусмотренное разработчиком.
> Никто никогда не читает факинг мануал... Оттого и думают, что что-то сделать нельзя...
Скажем так, в данном случае не "думают, что нельзя", а "не думают, что можно".
В списке перечислено всё, думать вроде и незачем.
> Все что нельзя сделать стандартными средствами - можно напрограммировать. Написание коммандной строки (а тем более скриптов) - это программирование.
> А программить пока придумали только в тексте.
> Как придумают, как программить в ГУИ - тогда и можно их сравнивать.
Приходится сравнивать, когда GUI продвигается как основное средство коммуникации.
> Позволю себе напомнить, что эволюцонно сначала изобрели общение жестами - это у человека практически с рождения.
> А вот говорить еще научить надо...
Вот и надо учить говорить, а не только объясняться жестами.
> И мыслит человек исключительно образами, а не как уж не буквами и не цифрами...
Про отличия мышления от коммуникации уже обсудили.
> У человека, между прочим 3-хмерное восприятие.
И как этим пользоваться для коммуникации символьной информации?
Скульптурами обмениваться?
> ГУИ - это 2D. Консоль - 1D. Зачем ограничивать себя?
Это только один из параметров, описывающий пространство.
И тут ты не прав: "консоль" содержит дисплей, который вполне себе двумерный.
> И не надо приводить доводы, что кругом говнокодеры нагвонокодили говногоры говноинтерфейсов.
> Просто и под ГУИ надо уметь программировать...
И умение это должно заключаться в том, чтобы найти те подзадачи, где оно реально помогает.
И не настаивать на использовании конкретного варианта там, где он может помешать.
Иначе говноинтерфейс и получается.
> По мне, так самый идеальный интерфейс - это когда любую команду можно сделать,
> как посредством команд с клавы, так и при помощи мышки (ввод текста не считается).
Не-а. Идеальный вариант - когда всё делается само.
Практически достижимое приближение к идеалу - когда один раз объясняешь, что делать, а дальше само.
(Не надо понимать, что совсем само - значит обязательно неинтерактивно, это всего лишь объясняет, что
человеку остаётся творческая часть, которую автоматизировать пока не умеют).
Поэтому хороший вариант - тот, который облегчает это объяснение.
У GUI с этим - принципиальные трудности - необходимость двойного преобразования.
Поэтому и:
> Вот чего винде не хватает - так это удобного механизма клавиатурных/мышиных макросов.
Но хороший интерфейс должен включать возможность использовать GUI там, где это удобно,
что как правило означает - после достаточной формализации задачи.
Если задача формализуется уже пользователем, и для неё оказывается удобно GUI,
значит надо дать возможность его построить.
И удобные средства есть, что характерно, например tcl/tk.
Согласен.
> И удобные средства есть, что характерно, например tcl/tk.
Я имел в виду стандартные средства винды...
> И удобные средства есть, что характерно, например tcl/tk.
Я имел в виду стандартные средства винды...
> Я имел в виду стандартные средства винды...
К сожалению, вряд ли когда-нибудь они станут удобными.
Но может это только у меня такой пессимистичный взгляд.
К сожалению, вряд ли когда-нибудь они станут удобными.
Но может это только у меня такой пессимистичный взгляд.
Да, ещё во всех моих рассуждениях можно вместо GUI поставить любой диалоговый (правильное слово?) интерфейс.
Например, предназначенный для текстового терминала.
Все выводы сохранят силу.
Вспоминаем начало обсуждения.
Необходимость именно графического интерфейса проявляется только
в задачах, связанных с обработкой некоторых видов несимвольных данных.
Хотя вот интересно, считать ли графы символьными данными?
Часто удобно именно графическое представление, с линиями и стрелочками.
Например, предназначенный для текстового терминала.
Все выводы сохранят силу.
Вспоминаем начало обсуждения.
Необходимость именно графического интерфейса проявляется только
в задачах, связанных с обработкой некоторых видов несимвольных данных.
Хотя вот интересно, считать ли графы символьными данными?
Часто удобно именно графическое представление, с линиями и стрелочками.
Я, который объясняет, могу сколько угодно помнить расположений кнопок, но задача - не вспомнить, а объяснить.
Обсуждали коммуникацию, а не запоминание.
а! я кажется понял что тебе надо: Remote Assistance!
> Remote Assistance!
Отличная штука, особенно если сеть не настроена.
Отличная штука, особенно если сеть не настроена.
а... ну да, ты говорил про "по телефону"...
ну а скрипт ты как собираешь по телефону надиктовывать?
ну а скрипт ты как собираешь по телефону надиктовывать?
Скрипт - громко сказано, простые действия требуют простой короткой последовательности операций.
Надиктовывать очень просто - слова, взятые из естественного языка - как обычно,
числа - как обычно, остальное - посимвольно.
Надиктовывать очень просто - слова, взятые из естественного языка - как обычно,
числа - как обычно, остальное - посимвольно.
В чем лучше создавать документы TeX-е или Word-е? Нормальные люди используют и то и другое. И было бы хорошо, если бы кто-нибудь спроектировал и написал хороший софт, который поддерживал и то и другое. Но в ближайшее время не напишут, денег на это нет.
Также и в других областях.
Также и в других областях.
Текст - чисто digital информация. GUI - шаг назад к аналоговой. Ведь весьма часто мы слышим: "...поищи в в районе закладки Свойства...". Цифровой аналог - ищи строку "abc".
Пример: конфигурационный файл vs. семейство диалоговых окон для настройки.
Файл может содержать комментарии - чтоб ты не забыл, зачем ты настроил именно так,
и чтобы другие могли понять это в случае необходимости.
В файле можно искать по ключевым словам, вместо бегания по менюшкам и напрягания глаз.
Файл можно сгенерировать, если писать руками надоело.
Можно запостить его на форум, послать почтой, продиктовать по телефону - текст - великая вещь.
Язык и письменность не зря придумали.
В случае GUI про него в таких случаях приходится забывать и изучать текстовое представление.
> Текст - чисто digital информация. GUI - шаг назад к аналоговой.
Сейчас тебе скажут, что может не назад, в вовсе даже вперёд.
Сейчас тебе скажут, что может не назад, в вовсе даже вперёд.
ну да, сначала скажут магическое заклинание "удобно",
а потом следствие -- "эффективно", вот и получается
типа "движение фпирёд"
а потом следствие -- "эффективно", вот и получается
типа "движение фпирёд"
шаг в сторону 
на спор объясню человеку любого уровня подготовленности, как настроить сеть под виндой.2Hegoat:
На спор по телефону настрою конфигурацию IP в UNIX, которого я до этого не видел. Человек на той стороне провода должен уметь читать английские символы и вводить их под диктовку, и иметь опыт работы с печатной машинкой (в противном случае я все равно смогу настроить, но это продлится долго). Согласен ли ты, что я так смело это заявляю именно по тому, что это делается через текст? Сможешь ли ты настроить сеть в Win2003 имев опыт только с win95 (или наоборот)?
Зачем все всерьез, это же КВЕСТ, тут (в ГУИ) и пиксельхантинг присутствует и нетривиальные последовательности кликов (иногда заглядываешься на руки гуевщика, который сродни мендельсону хот-кии давит)
> в UNIX, которого я до этого не видел
это вопрос совместимости вперед и назад...
у винды (ГУИ) с этим не очень хорошо
это вопрос совместимости вперед и назад...
у винды (ГУИ) с этим не очень хорошо
> Текст - чисто digital информация. GUI - шаг назад к аналоговой.
На конференциях разработчиков следующих поколений цифровых
процессоров вовсю обсуждаются проблемы использования аналоговых
компонент, вероятностного определения задержек распространения
сигнала в кристалле и т. п. Ещё непонятно что есть шаг куда.
На конференциях разработчиков следующих поколений цифровых
процессоров вовсю обсуждаются проблемы использования аналоговых
компонент, вероятностного определения задержек распространения
сигнала в кристалле и т. п. Ещё непонятно что есть шаг куда.
> На спор по телефону настрою конфигурацию IP в UNIX, которого я до этого не видел.
Прикинь, там запущено какое-нибудь CDE, и никто не знает, ни как терминал запустить,
ни какие доки почитать, в которых это написано
Прикинь, там запущено какое-нибудь CDE, и никто не знает, ни как терминал запустить,
ни какие доки почитать, в которых это написано
> в UNIX, которого я до этого не виделНет! Многие UNIX различаются очень сильно, или вообще не имеют общего предка. Дело не в похожести, а в свободе действий. Если UNIX будет совсем мне незнакомый, то я попрошу человека сделать grep -r /etc. Какие аналоги в GUI?
это вопрос совместимости вперед и назад...
Offtopic:
А в Minority Report скажите удобно было, когда они по воздуху руками окошки передвигали!
PS Как этот тред вообще в Programming попал
Потому что в консоли можно типа "программировать"?
А в Minority Report скажите удобно было, когда они по воздуху руками окошки передвигали!
PS Как этот тред вообще в Programming попал
Потому что в консоли можно типа "программировать"?Все предложения о легкой настройке сети в виндах по телефону основаны на том, что мы примерно представляем как выглядит тот самый GUI на другом конце телефона.
А если мы этого не знаем? ( пример MacOS X - не многие с ней работали, но там тоже все можно настроить через графический интерфейс).
Думаю, что времени прийдется потратить намного больше - сначала надо представить GUI со слов собеседника, и только потом сказать какие кнопки нажать и какие меню выбрать.
А если мы этого не знаем? ( пример MacOS X - не многие с ней работали, но там тоже все можно настроить через графический интерфейс).
Думаю, что времени прийдется потратить намного больше - сначала надо представить GUI со слов собеседника, и только потом сказать какие кнопки нажать и какие меню выбрать.
а теперь представь то же самое, только консоль с незнакомыми тебе коммандами. кстати в маках есть консоль?
В той же консоли есть help'ы, содержание которых гораздо легче передать в разговоре, чем описать GUI.
Начиная с MacOS X - есть.
Начиная с MacOS X - есть.
Ты хочешь сказать, что горячие клавиши --- это граф. интерфейс?
Это самая настоящая ком. строка!
Обычная линейная последовательность.
Можешь посмотреть, что такое Емакс.
---
You've got TECO. What more do you want?
Это самая настоящая ком. строка!
Обычная линейная последовательность.
Можешь посмотреть, что такое Емакс.
---
You've got TECO. What more do you want?
А ты эти "крысиные яды" запускал?
Я запускал.
Впечатляет.
Хочешь сказать, что это граф. интерфейс в обычном понимании?
---
"Я знаю правду! Все прежние правды --- прочь!"
Я запускал.
Впечатляет.
Хочешь сказать, что это граф. интерфейс в обычном понимании?
---
"Я знаю правду! Все прежние правды --- прочь!"
Я не знаю, что такое "документы."
Я знаю, что такое статья, что такое книга, что такое курсовая и что такое диплом.
Всё удобнее набирать в ТеХе, как ни странно.
Кстати, говорят есть какой-то tex-preview-mode или как его там.
Пока не пробовал.
---
"Я знаю правду! Все прежние правды --- прочь!"
Я знаю, что такое статья, что такое книга, что такое курсовая и что такое диплом.
Всё удобнее набирать в ТеХе, как ни странно.
Кстати, говорят есть какой-то tex-preview-mode или как его там.
Пока не пробовал.
---
"Я знаю правду! Все прежние правды --- прочь!"
Оставить комментарий
Ivan8209
Можно пояснить, какие задачи можно решать в граф. интерфейсе?---
...Я работаю антинаучным аферистом...