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