Re: CLI vs. GUI
Артём Н. -> debian-russian@lists.debian.org @ Tue, 22 May 2012 22:48:11 +0400:
>> >> >> Так что писать на коленке презентацию, которая будет
>> >> >> выведена плюс-минус так, как ты ее видишь, еще можно (и то
>> >> >> не всегда нужно - видел я подобные поползновения печатать
>> >> >> объявления в ворде...), а HTML - уже ни в коем разе.
>> >> АН> Как-раз для HTML, GUI необходим. Если, конечно, вы не
>> >> АН> рассчитываете на то, что все ваши пользователи используют
>> >> АН> lynx, links, w3m или подобное.
>> >>
>> >> Доктор, это ничего, что у меня есть информативный сайт, все HTML
>> >> которого написаны вручную, старые в vim, новые в emacs? Ключевое слово
>> >> - "информативный".
>> АН> Вообще-то, это частный случай, когда требуется преимущественно
>> АН> подсветка HTML и CSS. С чем VIM неплохо справляется.
>>
>> Причем, если делать по уму, то HTML и CSS не нужно смешивать в одном
>> файле, отчего все еще проще.
АН> Правильный редактор не должен рассчитывать на то, что всё будет "по
АН> уму", к тому же, иногда надо смешивать CSS и HTML.
Правильный _для меня_ - имеет право на это рассчитывать. Более того,
ему рекомендуется так делать. Типа если он не справляется с подсветкой,
значит, я фигню порю. emacs вполне успешно справляется с задачей ловли
меня за руку.
Смешивать CSS и HTML иногда надо. Но если это приходится делать до
такой степени, что нужна синтаксическая подсветка CSS - фигню порешь.
Что и наблюдается в случае HTML из-под винворда :-)
>> Суть, собственно, в том, что vim и emacs - это TUI, а не GUI. Хотя
>> emacs даже умеет показывать картинки. Лучше б не умел...
>>
>> >> А если мне нужно интерактивное веб-приложение, то
>> >> там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно
>> >> ручное редактирование.
>> АН> Хм... Haml - любопытно.
>>
>> Угу. Технология создания веб-приложений сводится к тому, что дизайнер
>> делает дизайн, HTML-верстальщик (это совершенно другой человек)
>> превращает его в HTML, CSS и набор картинок, а программист превращает
>> эти HTML и CSS (картинки обычно оставляет как есть) в набор шаблонов,
>> которые динамически заполняются данными. Гуй для HTML при этом может
>> использоваться в принципе только на втором этапе, но тем верстальщикам,
>> кто пытается его там использовать, быстро отрывают руки. Ну, или
>> результат получается, мягко говоря, неюзабельным для пользователя.
АН> Хм. Что, вы хотите сказать, что во всех компаниях, которые
АН> занимаются созданием WEB-данных (документов или приложений и т.п.)
АН> и могут позволить себе иметь дизайнера, не имеющего представления о
АН> вёрстке и ей не занимающегося, верстальщика и прочих, вторые всегда
АН> работают без GUI? Кстати, а дизайнер тоже обязательно, либо не
АН> использует компьютер, либо работает без GUI? :-) Или, всё-таки, на
АН> первом этапе тоже есть GUI, только совершенно отличный от GUI
АН> верстальщика?
К слову, в большинстве контор, занимающихся созданием веб-приложений,
своего дизайнера вообще нет. Аутсорсят. Дизайнер не работает с HTML,
поэтому ему гуй для (читаем внимательно!) HTML не нужен.
Верстальщик тоже работает с гуем - но не для создания HTML, а для
нарезки того, что сделал дизайнер, и для извлечения оттуда информации о
цветах :-)
АН> Кстати, а операторам на станциях например, GUI тоже не требуется?
АН> :-) Или, всё-таки, он иногда нужен (почему-то вы та упорно
АН> пытаетесь доказать, что GUI - всегда плохо)?
Почему-то вы упорно вычитываете в моих словах то, что там не написано.
>> >> Как это выглядит, нужно смотреть в браузере и только в браузере.
>> >> Желательно не в одном.
>> АН> Как это выглядит и работает нужно проверять в браузере. Обязательно
>> АН> не в одном, как говорят. По крайней мере, в наиболее популярных
>> АН> (или в тех, на которых это будет работать, если это нечто
>> АН> специфическое). И, затем ещё вносить корректировки для конкретных
>> АН> экземпляров. :-|
>>
>> Тонкость в том, что если у тебя есть информация, то можно написать
>> достаточно простой HTML для того, чтобы проверять его нужно было
>> максимум в одном. Тому, кому есть, что сказать, дизайнерские изыски
>> обычно не шибко нужны.
АН> Просто выглядящий и преподносящий информацию в удобочитаемом виде
АН> или просто устроенный? :-)
Все три. Первые два вообще очень тесно коррелируют - чем проще выглядит
HTML, тем информация в нем удобочитаемее.
>> >> Мешает он тем, что то, как это выглядит в этом гуе, автор и считает
>> >> реальным видом документа. А что этот гуй выдает в код, и какой ужас
>> >> потом в браузере... Это - практика.
>> АН> o.O Я разве агитирую за "Фронтпэйдж"? Я предполагаю, что автор
>> АН> имеет представление о том, что существуют разные средства вывода
>> АН> (и, если уж быть точным, не обязательно визуальные).
>>
>> Наличие гуя провоцирует не иметь такого представления.
АН> Это, как "наличие пистолета провоцирует с кем-то разобраться"...
АН> Уменьшает порог вхождения.
АН> Но человек во вменяемом состоянии, вряд ли побежит разбираться с
АН> кем-то лишь потому, что у него в кармане оружие.
Аналогии лгут.
>> >> А JS длиннее одного вызова функции в <script> в ручную написанном HTML -
>> >> это признак того, что у автора слишком много свободного времени, и ему
>> >> нечем это время занять, кроме как вычисткой потом глюков из результата.
>> АН> Мда? А эта функция тянет за собой библиотеку на 300 Кб и ещё один
>> АН> внешний JS, который включает объект её реализующий? Про "много
>> АН> свободного времени" - это вы объясните авторам всяких там гуглов и
>> АН> ещё 100500 сервисов, которые этим JS буквально пронизаны (местами
>> АН> это даже удобно и, бывает, работает).
>> Это второй вопрос. Но программа на JS, если она используется, должна
>> быть в отдельном файле, а не включена в тот же HTML.
АН> Когда как...
Ни одного контрпримера не попадалось.
Reply to: