Re: CLI vs. GUI
20.05.2012 21:21, Artem Chuprina пишет:
> Артём Н. -> debian-russian@lists.debian.org @ Fri, 18 May 2012 12:07:00 +0400:
> >> Так что писать на коленке презентацию, которая будет выведена плюс-минус
> >> так, как ты ее видишь, еще можно (и то не всегда нужно - видел я
> >> подобные поползновения печатать объявления в ворде...), а HTML - уже ни
> >> в коем разе.
> АН> Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете
> АН> на то, что все ваши пользователи используют lynx, links, w3m или
> АН> подобное.
>
> Доктор, это ничего, что у меня есть информативный сайт, все HTML
> которого написаны вручную, старые в vim, новые в emacs? Ключевое слово
> - "информативный".
Вообще-то, это частный случай, когда требуется преимущественно подсветка HTML и
CSS. С чем VIM неплохо справляется.
> А если мне нужно интерактивное веб-приложение, то
> там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно
> ручное редактирование.
Хм... Haml - любопытно.
> Как это выглядит, нужно смотреть в браузере и только в браузере.
> Желательно не в одном.
Как это выглядит и работает нужно проверять в браузере. Обязательно не в одном,
как говорят. По крайней мере, в наиболее популярных (или в тех, на которых это
будет работать, если это нечто специфическое). И, затем ещё вносить
корректировки для конкретных экземпляров. :-|
> АН> но графический режим добавляет возможность предосмотра картинок,
> АН> например. Поддержка мышки и d&d добавляет возможность быстрой
> АН> компоновки. Меню организуют структуру команд и позволяют быстро
> АН> найти нужную (они не заменяют горячих клавиш), без использования
> АН> справки... В итоге, получается GUI (причём, никто не отменяет
> АН> поддержку консольного режима). По-моему, это очевидно. И чем тут
> АН> он мешает (при условии, что он спроектирован и реализован
> АН> грамотно)?
>
> Мешает он тем, что то, как это выглядит в этом гуе, автор и считает
> реальным видом документа. А что этот гуй выдает в код, и какой ужас
> потом в браузере... Это - практика.
o.O Я разве агитирую за "Фронтпэйдж"? Я предполагаю, что автор имеет
представление о том, что существуют разные средства вывода (и, если уж быть
точным, не обязательно визуальные).
> АН> К тому же, для написания кода необходим нормальный интерфейс (ну,
используя cat
> АН> или echo, тоже возможно кое-что написать, но идея плохая (как крайний
случай)).
> АН> Если вы будете писать в notepad-like, это затянется.
> АН> Т.е. нужен редактор с подсветкой синтаксиса. Причём, желательно, с
> АН> автоматическим определением по контексту того, что подсвечивать
(например, js в
> АН> <script> и css должны подсвечиваться по-разному).
> АН> Он не обязательно должен работать в графическом режиме,
>
> Дело не в этом. Дело в том, что он обязательно НЕ должен быть WYSIWYG.
Вот именно об этом я и говорю. "WISYWYG плохо, потому что это WISYWYG" (и ещё
десять надуманных причин).
Дело в том, что там он крайне желателен. Вопрос удобства.
Пример грамотно (несмотря на то, что они там напилили в последних версиях и ещё
множество лишних вещей) реализованного редактора - "Dreamweaver".
WISYWYG нужен для примерного представления о том, как будет выглядеть документ.
Никто не отменяет "ручной правки" результата.
Но этак даже формочки во всяких "Делфи" возможно вручную делать. Но зачем?
> А JS длиннее одного вызова функции в <script> в ручную написанном HTML -
> это признак того, что у автора слишком много свободного времени, и ему
> нечем это время занять, кроме как вычисткой потом глюков из результата.
Мда? А эта функция тянет за собой библиотеку на 300 Кб и ещё один внешний JS,
который включает объект её реализующий? Про "много свободного времени" - это вы
объясните авторам всяких там гуглов и ещё 100500 сервисов, которые этим JS
буквально пронизаны (местами это даже удобно и, бывает, работает).
Reply to: