[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CLI vs. GUI



Артём Н. -> debian-russian@lists.debian.org  @ Fri, 18 May 2012 12:07:00 +0400:

 >>  >> Поскольку им нужно не только видеть, как выглядит текст сейчас, но и
 >>  >> понимать что с ним будет происходить при некоторых изменениях (например
 >>  >> при переформатировании на другую ширину) и быть уверенными что от этого
 >>  >> смысл не потеряется.
 >>  АН> И, всё-таки, GUI... :-)
 >> 
 >> Конкретно в этой задаче GUI как раз сильно мешает.  Особенность
 >> человеческой психики, ничего личного.
 >> 
 >> Так что писать на коленке презентацию, которая будет выведена плюс-минус
 >> так, как ты ее видишь, еще можно (и то не всегда нужно - видел я
 >> подобные поползновения печатать объявления в ворде...), а HTML - уже ни
 >> в коем разе.
 АН> Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете
 АН> на то, что все ваши пользователи используют lynx, links, w3m или
 АН> подобное.

Доктор, это ничего, что у меня есть информативный сайт, все HTML
которого написаны вручную, старые в vim, новые в emacs?  Ключевое слово
- "информативный".  А если мне нужно интерактивное веб-приложение, то
там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно
ручное редактирование.

 АН> К тому же, для написания кода необходим нормальный интерфейс (ну, используя cat
 АН> или echo, тоже возможно кое-что написать, но идея плохая (как крайний случай)).
 АН> Если вы будете писать в notepad-like, это затянется.
 АН> Т.е. нужен редактор с подсветкой синтаксиса. Причём, желательно, с
 АН> автоматическим определением по контексту того, что подсвечивать (например, js в
 АН> <script> и css должны подсвечиваться по-разному).
 АН> Он не обязательно должен работать в графическом режиме,

Дело не в этом.  Дело в том, что он обязательно НЕ должен быть WYSIWYG.
Как это выглядит, нужно смотреть в браузере и только в браузере.
Желательно не в одном.

 АН> но графический режим добавляет возможность предосмотра картинок,
 АН> например. Поддержка мышки и d&d добавляет возможность быстрой
 АН> компоновки. Меню организуют структуру команд и позволяют быстро
 АН> найти нужную (они не заменяют горячих клавиш), без использования
 АН> справки...  В итоге, получается GUI (причём, никто не отменяет
 АН> поддержку консольного режима).  По-моему, это очевидно.  И чем тут
 АН> он мешает (при условии, что он спроектирован и реализован
 АН> грамотно)?

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

А JS длиннее одного вызова функции в <script> в ручную написанном HTML -
это признак того, что у автора слишком много свободного времени, и ему
нечем это время занять, кроме как вычисткой потом глюков из результата.


Reply to: