eao197 wrote: > Кстати да, после некоторого опыта работы с LaTeX меняется подход к > написанию документов. Особенно, когда используешь собственные команды > (либо собственные verbatim, или собственные колонтитулы) и одним легким > движением руки изменяешь оформление всех однотипных фрагментов во всем > документе -- это впечатляет.
Ворд это тоже позволяет делать И свои библиотеки стилей в том числе.
> Тем не менее, разговор свелся к обсуждению интеграции различных GUI > приложений. Интересно, имел ли в виду Kisloid именно GUI? Или же и > server side так же.
С server-side в Unix все нормально.
Kolhoz wrote:
> C>Мой любимый пример: как мне таблицу с графиками из Calc вставить в > C>AbiWord, а потом ее там же редактировать с помощью inplace-редактора? > Обе эти убогонькие программульки никакого отношения к unix way не имеют. > А вот R + MySQL + Python + latex + gnuplot + maxima идеально вяжутся в > одну систему, и, как показывает практика, вендовозные ламеры, любители > поредактировать табличку в текстовом процессоре, по эффективности работы > просто рядом не валялись с теми кто пользуется подобной связкой. Пара > дней — и идеального полиграфического качества статья готова, с > идеальными графиками и достоверно проверенным качеством вывода и > рассчётов. Вордописцы будут с тем же самым возиться не меньше месяца, > как, опять же, демонстрирует та же самая практика.
Вот именно что _ламеры_. А дай ламеру твой unix way, он и за год не справится. А не ламеры и в ворде шустро шуруют.
Попробуй потратить 2 недели обучая свою бабушку/маму word+excel для создания документа с парой графиков и mysql+tex на
те же 2 недели. О результатах расскажи.
Конечно, можно сказать, что ламерам за компьютер садиться нельзя, это и будет unix way, а windows way — компьютер вещь
простая, доступная всем, на чём MS деньги и зарабатывает.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Kolhoz, Вы писали:
K> Так и я о том же. Виндоводы при упоминании компонентов сразу рюшечки-менюшечки воображают да композитные документы. Чем сразу выдают свой стиль мышления — от формы к содержанию. Доверять таким людям разработку архитектуры сложных систем — самоубийство, они любую архитектуру будут от GUI проектировать. Особенно этим отлечаются дельфины, в них собрана вся квинтэссенция махрового виндуизма.
Давайте все-таки без экстремизма и максимализма. Битие определяет сознание. Если кому-то приходится лабать околоофисный софт под Windows, то тут хочешь не хочешь, а с установленными MS (и миллионами не технических пользователей) правилами приходится считаться. Все же главная цель программы -- это выполнение возложенных на нее обязанностей. Внутренняя архитектура покупателей не интересует.
Поэтому лучше не издеваться над теми, кто на подобной GUI-ёвой компонентности деньги зарабатывает, а рассказывать о том, что что-то можно делать совсем по другому. Чтобы не было дилетантских вопросов "Как же в Linux-е без OLE?".
Так что предлагаю не смеятся друг над другом, а учиться друг у друга
Чей-то я в пацифисты записался вдруг?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
dmz wrote: > C>Я не спорю, pipe'ы — это очень элегантное решение, позволяющее > C>эффективно решать *большую часть* административных задач. Только > C>вот пора бы уже что-то новое придумать. > Есть мнение, что надо руководствоваться не религиозным чувством, а > прагматизмом. > Если проще через пайпы — то через пайты. Если пайпы не катят — то > пожалуйста: CORBA, DCOP и черти-что еще. Примеры — KDE, KParts.
А вот тут проявляются проблемы — эти механизмы не совместимы между друг
другом. Да и по мощности эти компонентные системы уступают (или только
приближаются к) OLE2.
Здравствуйте, eao197, Вы писали:
E>Давайте все-таки без экстремизма и максимализма. Битие определяет сознание. Если кому-то приходится лабать околоофисный софт под Windows, то тут хочешь не хочешь, а с установленными MS (и миллионами не технических пользователей) правилами приходится считаться. Все же главная цель программы -- это выполнение возложенных на нее обязанностей. Внутренняя архитектура покупателей не интересует.
Не согласен. Если разработчики дизельных двигателей начнут их проектировать исходя из цвета и формы кузова автомобиля, под который делается движок, а так же при первоначальной оценке проекта обязательно учитывать обивку кресел — то это будет просто смешно.
GUI вторично всегда, даже в самом юзер-ориентированном проекте. И разработчик просто не имеет ни малейшего права выводить архитектуру приложения исходя из своих представлений о GUI. Такому разработчику в индустрии не место.
E>Поэтому лучше не издеваться над теми, кто на подобной GUI-ёвой компонентности деньги зарабатывает, а рассказывать о том, что что-то можно делать совсем по другому. Чтобы не было дилетантских вопросов "Как же в Linux-е без OLE?".
Так я и рассказываю. Не слушают-с. Сколько я этих GUI понаделал, преимущественно под Windows, и ну ни разу не приходилось применять их, вендовый стиль мышления. К чему бы это?
E>Так что предлагаю не смеятся друг над другом, а учиться друг у друга
Боюсь, мне у них учиться нечему... У нас ведь и так есть всё то же что и у них. Наигрались в прошлом и выкинули на помойку — а они, вендузятники, подобрали. И объектные компонентные модели были, и унифицированные рантаймы. Всякого добра хватало. Много лет назад отбраковали.
Здравствуйте, Kolhoz, Вы писали:
K> Так я и рассказываю. Не слушают-с. Сколько я этих GUI понаделал, преимущественно под Windows, и ну ни разу не приходилось применять их, вендовый стиль мышления. К чему бы это?
E>>Так что предлагаю не смеятся друг над другом, а учиться друг у друга
K> Боюсь, мне у них учиться нечему... У нас ведь и так есть всё то же что и у них. Наигрались в прошлом и выкинули на помойку — а они, вендузятники, подобрали. И объектные компонентные модели были, и унифицированные рантаймы. Всякого добра хватало. Много лет назад отбраковали.
Имхо, научится всегда есть чему, но это уже офтопик.
На самом деле меня больше волнует качество обсуждений в Философии Программирование, которое в последнее время регулярно снижается. Интересные темы превращаются в пустые флеймы, а затем переносятся в Священные Войны с теми редкими крупицами полезной информации, которые там все же есть.
Я это к тому, что высказывания типа "виндузятники", "невозможно поменять стиль мышления", "мне научиться не чему" как раз превращают обмен мнениями в бесполезный флейм. Вот я и призываю держать себя в руках, чтобы вот так
Kolhoz wrote: > C>Проблема если нужно одновременно два разных потока данных как-то > передавать. > ??? > Ни разу не проблема.
Как через один пайп передать два потока одновременно? Только named pipe'ами.
> C>S-выражения — те же яйца, вид в профиль. > Не те же. Обработка проще и дешевле. И вместе с ними можно передавать код, > не только данные.
Как мне из JavaScript прочитать S-expr? Упс... А как там с разными
кодировками?
> C>Как-то надо было сделать простую вещь — взять XML, пробежаться по всем > C>узлам с заданым путем, взять у них атрибут, сделать операцию с этим > C>атрибутом (это было имя файла, надо было regexp'ом его переименовать), а > C>потом записать его же в этот документ, но по другому пути. > И? Где трудности? Вставить в пайплайн xslt кто запретил?
А как мне из xslt вызвать файловые операции со сторонними файлами?
> C>После часа мучений с tee и прочими гадостями — просто взял > C>ActivePython+MSXML и за 10 минут написал все что нужно. > И чем же это не unix way?
COM ведь используется.
Создается компонент (написанный на С++) и прозрачно используется из
совершенно другого языка (о котором создатель компонента мог и не
догадываться).
Это я к тому, что Unix-pipes — это далеко не идеал.
> Этих стандартных утилит — вагон. На все случаи жизни хватит. Для меня > самые "стандартные" — perl и python.
И что? Тот же Word замечательно рулится через OLE2 из
Python/Perl/VisualBasic/Brainfuck (да!)/C#/Nemerle/....
> C>Без стандартных утиллит — получается простая идеология использования > C>соединенных фильтров. > Это и есть unix way. Много маленьких уединённых программок с CLI, > способных общаться через пайпы И СОКЕТЫ.
Вот только этот мирок разбивается, когда встречается с суровыми
реальностями настоящих требований пользователей.
> C>Нет. Это убогий unix way — так как RAR поддерживает создание архивов с > C>кодами коррекции ошибок (если повреждается часть файла — ее можно > C>восстановить). Но для этого ему нужен произвольный доступ к источнику и > C>результату. > Нужен произвольный доступ — значит, не нужен поток и масштабируемость. > Выбирай.
А мне хочется и того и другого. И я это могу получить, используя более
мощные абстракции.
В частности, для данного примера хватило бы возможности реализовывать
свои потоки произвольного доступа. В OLE это УЖЕ есть — смотри IStream.
>> > ЗАЧЕМ?!? Named pipes и unix domain sockets рулят со страшной >> > силой. > C>Покажите мне fseek на named pipe или domain socket. > Зачем?
А вы думаете, что мир заканчивается однонаправленными потоками?
> C>Можно использовать shmem с некоторыми ограничениями, но все равно не > C>хватает возможности полноценно реализовать свой файл. > Зачем? Тем более shmem не масштабируется, так что фтопку.
Именно в этом и проблема с ним.
> Какие факты? Есть две ущербные программульки, про unix way ничего не > знающие — так какое они имеют отношение тогда к обсуждаемой теме?
Есть 99% рынка домашних компьютеров, занятых этими ущербными программами.
А многочисленные попытки приспособить The Unix Way к десктопу — провалились.
> C>Пробовал. > Плохо пробовали. Неумело.
Я не ежик, чтобы колоться, но продолжать жрать кактус. Причем без
какой-то перспективы на улучшение.
> C> ОЧЕНЬ неудобно писать спеки — если в Word/OpenOffice/... я > C>могу запустить редактор, нарисовать нужную диаграмму, cut&paste'ом > C>вставить в документ (не волнуюясь при этом об именах файлов), то с TeXом > C>один ужас получается. > Какие такие спеки?!? Для тех. документации есть docbook. А тех, кто > пишет её в офисах — надо гнать в три шеи, им в IT не место.
Еще раз медленно, для тех кто долго понимает:
Технические спецификации — это НЕ документация к коду, это НЕ
документация к существующим системам, их НЕ нужно иметь в 10 форматах,
они ДОЛЖНЫ удобно редактироваться.
> C>Начиная с неправильных версий пакетов и стилей на разных компьютерах, и > C>заканчивая неполными документами. > Ну ну. Не умеете вы этих кошек готовить.
Ага. А может это просто кто-то много о себе думает?
> C>Понимаете, мне *НАФИГ НЕ НУЖНЫ* документы полиграфического > C>качества, так работа идет с электронными копиями (а печатаются они для > C>отчетности). > Тогда какие на хрен вордоофисы? Это задача для docbook.
Docbook не подходит по многим причинам:
1. Редактировать руками его неудобно.
2. Нет нормальных редакторов.
3. Куча ненужных возможностей.
4. Нет НУЖНЫХ возможностей.
> C>Плохие вордописцы. Или они там формулы рисуют? > Естественно рисуют.
Тогда действительно нафиг такое.
> C>Хотя в TeXе очень неудобно писать химические формулы (точнее, их вообще > C>неудобно как-либо в текстовом виде записывать). > Удобно, очень удобно. Удобней чем любой визуальный редактор. > Даже диаграммы Фейнмана — и то удобно, куда уж там всякой попсовой химии.
Ты просто не видел формул. Их и в 2D (на листе бумаги) неудобно иногда
рисовать, а уж в 1D — вообще невозможно.
Диаграммы Фейнмана — это десткий лепет по сложности рисования.
> C>ROTFL. > Это вы от незнания.
Задумайтесь, всякое общее утверждение — неверно.
> C>Как раз GUI — это идеальный пример для "компонентов" в понимании > C>COM/.NET/Delphi. > Отвратительный пример.
А что делать? Мир — жестокая штука.
> Идеальный GUI — это, например, Tcl/Tk, с частичной генерацией кода на > стороне логики. Другой вариант — сервер, отображающий визуальные > компоненты, которые описываются в виде XML или S-выражений.
А кто описания строит? Если автомат — то в морг.
Ну а задавать расположение визульных компонентов вручную с помощью
layout'ов (которые можно описывать как угодно) — додумались уже давным
давно.
> Всякой дебильной объектщине в GUI и близко места нет. То, что > извращенцы-объектщики так нагло и упорно в GUI лезут — ни разу им не > оправдание.
Ну так функциональщики показали бы класс.
> Нет тут фанатизма. Есть знания и опыт, которых нет у вас.
Вы случайно не Луговской? Что-то стиль похож.
Кстати, и откуда вы это знаете о моем опыте? Читали резюме? Видели мои
проекты? А?
Здравствуйте, Cyberax, Вы писали:
C>Ворд это тоже позволяет делать И свои библиотеки стилей в том числе.
А я вам не верю. Попробуйте ка встроить мне в Ворд **ВЕКТОРНУЮ** графику, созданную в Wolfram Mathematica. Так, чтоб пересчитывалось при изменении исходных данных, вписанных в тот же самый вордовы документ. И при этом чтоб его можно было прочитать на компьютере, где Mathematica не установлена.
Да и сами посудите — много ли можно наавтоматизировать на Вижуал Васике?!?
C>С server-side в Unix все нормально.
При правильном проектировании любой, сколь угодно сложный ГУЙ — это тонюсенькая (и легкоотрываемая) прослоечка над "server-side".
>> Ни разу не проблема. C>Как через один пайп передать два потока одновременно? Только named pipe'ами.
А оно точно надо? В один поток — точно нельзя? Точно-точно?
>> И? Где трудности? Вставить в пайплайн xslt кто запретил? C>А как мне из xslt вызвать файловые операции со сторонними файлами?
А это уже не поток. Работайте с файлами — но это уже другая история.
XML вообще формат, не рассчитанный на работу в потоковом стиле.
Вот хоть что делайте.
>> C>ActivePython+MSXML и за 10 минут написал все что нужно. >> И чем же это не unix way? C>COM ведь используется.
Я так понимаю, COM что бы MSXML дергать? Ну возьмите libxml которая есть в
питоне — и никакого кома.
C>Это я к тому, что Unix-pipes — это далеко не идеал.
Ничто — не идеал. Гвозди — молотком, шурупы — отверткой. Ы?
>> способных общаться через пайпы И СОКЕТЫ. C>Вот только этот мирок разбивается, когда встречается с суровыми C>реальностями настоящих требований пользователей.
Боюсь все эти суровые нереализуемые требования в реале сведутся к требованию
воткнуть эхельную таблицу в ворд и там ее редактировать. Что в реальной жизни и под
виндовс умеет крайне мало приложений — например, эхельная таблица в Лотус вставляется
как картинка. Даже в html или rtf-не конвертируется.
С другой стороны, внутри офисных пакетов — и OO и вроде KOffice так умеют.
С третьей стороны и телевизор (kmplayer) у меня вполне встраивается в бровзер.
KParts — и не говорите что не стандарт. В рамках KDE такой-же стандарт, как ActiveX
в Win.
>> Выбирай. C>А мне хочется и того и другого. И я это могу получить, используя более C>мощные абстракции.
по моему, вам просто хочется разрушить мозг оппонента, уж извините.
>> Какие факты? Есть две ущербные программульки, про unix way ничего не >> знающие — так какое они имеют отношение тогда к обсуждаемой теме? C>Есть 99% рынка домашних компьютеров, занятых этими ущербными программами.
Я таки не понял, если рару нужно random access то почему бы ему просто не скормить
файл? Из какого-то принципа? И чем в данном случае его поведение отличается от его
поведения под win?
C>А многочисленные попытки приспособить The Unix Way к десктопу — провалились.
Была где-то ссылка на статью, где убедително доказывалось, что KDE — это Unix Way в полный рост.
Стало быть, не провалились.
На самом деле, Unix way это не что иное, как принцип K.I.S.S. И ничего более.
Здравствуйте, Cyberax, Вы писали:
>> Нет тут фанатизма. Есть знания и опыт, которых нет у вас. C>Вы случайно не Луговской? Что-то стиль похож.
C>Кстати, и откуда вы это знаете о моем опыте? Читали резюме? Видели мои C>проекты? А?
Здравствуйте, kan_izh, Вы писали:
_>Вот именно что _ламеры_. А дай ламеру твой unix way, он и за год не справится. А не ламеры и в ворде шустро шуруют.
Фига. В ворде просто нет нужных не-ламеру фичей. Либо есть, но добраться до них — слишком трудно и долго.
_>Попробуй потратить 2 недели обучая свою бабушку/маму word+excel для создания документа с парой графиков и mysql+tex на _>те же 2 недели. О результатах расскажи.
Практика показывает, что двух недель более чем достаточно для обучения latex-у и сопутствующей обвязке. Кого угодно, причём, от библиотекарши до секретарши. С Вордом труднее — ни хрена не понимают, боятся и зовут эникейщика на каждый чих.
Здравствуйте, Андрей Хропов, Вы писали:
iZEN>>А кто сказал, что COM и .Net — компонентные технологии? АХ> COM = Component Object Model.
Маркетинг. Чтобы покупали виндовс.
iZEN>>Они обе завязаны на реестр и Windows. АХ>COM да, .NET — в принципе нет (реализация от MS — да). АХ>Но при чем здесь компонентность?
Компонентность подразумевает компонентность. Хотя да, здесь я с модульностью попутал.
iZEN>> Даже в Mono сталкиваются с неожиданными трудностями по реализации точка-нет, АХ>Извините, .NET — это международный стандарт, который с Windows никак не связан.
Шарашка под названием ECMA, которую спонсируют Intel, Apple и Microsoft, не такая уж и иеждународная организация по стандартизации.
Вот когда туда войдут IBM и Sun, тогда можно будет говорить об отраслевых стандартах, но не более.
ISO — вот это организация, причём международная, независимая от частных фирм и инвесторов. CLR ещё не входит в планы стандартизации на уровне ISO.
АХ>В Mono сталкиваются с трудностями в основном при реализации поведения WinForms точно как в Windows, но это уже немного другое.
Выходит, что точка-нет несовсем компонентна, если нельзя просто взять и переписать нужный компонент (библиотеку) без затрагивания остальной части (системного, низкоуровневого) кода.
iZEN>> не говоря уже о реализации COM на не-MS-платформах. Эти т.н. "компонентные технологии" не являются таковыми, так как компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают. АХ>А что компонентность обязательно включает в себя платформонезависимость? АХ>Я здесь этого не нашел.
Компонентность необязательно должна быть платформонезависимой и в точка-нэт это так.
iZEN>>Приложения ведут себя иначе — не как в Windows, где Explorer или глючное пользовательское приложение легко может свалить всю систему в BSOD. АХ>Это было во времена Win9x. АХ>В 2000/XP/Server 2003 все гораздо лучше. Я не помню когда у меня последний раз был BSOD не по причине железа, вышедшего из строя.
Есть два узких места в линейке Windows NT, которые могут привести к BSOD или зависанию: некорректные драйверы видеокарты и драйвер печати. Часть кода работает в режиме ядра, хотя по всем канонам весь их код должен работать в режиме пользователя. Другой пример из моей практики: USB-устройство, втыкаемое пользователем, может повесить наглухо операционку, драйверы USB родные-виндовые. Это спорные моменты, конечно же, так как всё-таки приведённые примеры "работают" на уровне драйверов, что к пользовательским процессам вроде бы не относится.
Ладно, берём вирус msblast, который выбивает сервис RPC с пользовательского уровня!!!
Такое однозначно не пройдёт в *.NIX.
Kolhoz wrote: > Не согласен. Если разработчики дизельных двигателей начнут их > проектировать исходя из цвета и формы кузова автомобиля, под который > делается движок, а так же при первоначальной оценке проекта обязательно > учитывать обивку кресел — то это будет просто смешно.
А если не учитывать форму кузова, то в итоге получится автомобиль
советского производства.
> Так я и рассказываю. Не слушают-с. Сколько я этих GUI понаделал, > преимущественно под Windows, и ну ни разу не приходилось применять их, > вендовый стиль мышления. К чему бы это?
Ну так покажите эти GUI. И их пользователей. Какие проблемы?
Kolhoz wrote: > А я вам не верю. Попробуйте ка встроить мне в Ворд **ВЕКТОРНУЮ** > графику, созданную в Wolfram Mathematica. Так, чтоб пересчитывалось при > изменении исходных данных, вписанных в тот же самый вордовы документ. И > при этом чтоб его можно было прочитать на компьютере, где Mathematica не > установлена.
С Mathematica так не получится (она OLE2 не поддерживает).
А вот с Visio — вполне. Данные к диаграмме (таблица какая-нибудь,
например) привязываются через OLE Linking, все это сохраняется в
документ. На компьютерах, где нет Visio будет использоваться сохраненное
WMF-описание встроенного объекта.
> Да и сами посудите — много ли можно наавтоматизировать на Вижуал Васике?!?
Да сколько угодно:
1. VB — сам по себе вполне нормально подходит для автоматизации.
2. Делается внешний компонент и подключается к Word'у через механизм
Addin'ов.
3. Управляем Word'ом полностью из внешней системы (через OLE2, на любом
языке, в том числе и на Haskell).
> C>С server-side в Unix все нормально. > При правильном проектировании любой, сколь угодно сложный ГУЙ — это > тонюсенькая (и легкоотрываемая) прослоечка над "server-side".
Агащазблин. Рассчет 3D-поверхностей и работу с ними вы мне тоже из моего
текущего проекта предлагаете на сервер вынести?
Здравствуйте, Cyberax, Вы писали:
C>Агащазблин. Рассчет 3D-поверхностей и работу с ними вы мне тоже из моего C>текущего проекта предлагаете на сервер вынести?
Это зависит от расчета и от того, что является результатом расчета. Может быть его нужно не то что на один сервер, а на отдельный high perfomance кластер выносить.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
>> Ни разу не проблема. C>Как через один пайп передать два потока одновременно? Только named pipe'ами.
Именно. Передаём имена пайпов или сокетов через коммандную строку.
C>Как мне из JavaScript прочитать S-expr?
Я видел не менее десятка библиотек. Только для JS и прочих ресурсных кастратов лучше использовать нормализованные S-выражения.
Типа, вместо ((a b) c) писать a b () . . c () . .
C> Упс... А как там с разными C>кодировками?
Замечательно там с кодировками.
>> И? Где трудности? Вставить в пайплайн xslt кто запретил? C>А как мне из xslt вызвать файловые операции со сторонними файлами?
А если это нужно — то вместо xslt использовать guile+ssax или CDuce. Собственно, я гораздо чаще SSAX использую чем XSLT.
>> C>После часа мучений с tee и прочими гадостями — просто взял >> C>ActivePython+MSXML и за 10 минут написал все что нужно. >> И чем же это не unix way? C>COM ведь используется.
А, понял. Ну тогда это глупо. Можно без всяких мерзких COM-ов, дешевле и быстрее получится.
C>Создается компонент (написанный на С++) и прозрачно используется из C>совершенно другого языка (о котором создатель компонента мог и не C>догадываться).
Какое извращение. Интерфейсы какие-то выдумывать... Гораздо проще — на любом языке создаётся компонент, который знает только про текстовые потоки и аргументы коммандной строки.
C>Это я к тому, что Unix-pipes — это далеко не идеал.
Pipes — это только один из многих механизмов. Это не есть краеугольная соль unix way. Соль unix way в способе разграничения компонент и в наборе общих требований к способу обмена между компонентами. Фундаментальнейшее из них: между любыми двумя компонентами можно встравить третий, так что ни первый ни второй об этом не будут знать. Всё остальное — детали и частности.
C>И что? Тот же Word замечательно рулится через OLE2 из C>Python/Perl/VisualBasic/Brainfuck (да!)/C#/Nemerle/....
Бледненько. Делать поддержку OLE для каждого очередного языка — не в радость.
>> Это и есть unix way. Много маленьких уединённых программок с CLI, >> способных общаться через пайпы И СОКЕТЫ. C>Вот только этот мирок разбивается, когда встречается с суровыми C>реальностями настоящих требований пользователей.
Обманываете. Ни разу ещё не встречал ситуации, когда нельзя было бы применить unix way. Причём, в Windows, в очень даже пользовательских гуйнячих приложениях.
>> Нужен произвольный доступ — значит, не нужен поток и масштабируемость. >> Выбирай. C>А мне хочется и того и другого. И я это могу получить, используя более C>мощные абстракции.
Обманываете. Невозможно без промежуточного хранилища, что ломает сразу всю идею.
C>В частности, для данного примера хватило бы возможности реализовывать C>свои потоки произвольного доступа. В OLE это УЖЕ есть — смотри IStream.
Чушь. Это НЕ решение.
>>> > ЗАЧЕМ?!? Named pipes и unix domain sockets рулят со страшной >>> > силой. >> C>Покажите мне fseek на named pipe или domain socket. >> Зачем? C>А вы думаете, что мир заканчивается однонаправленными потоками?
Я думаю, что не надо изображать из файлов то, чем они не являются. Файлы это одно, потоки — совсем другое.
>> Зачем? Тем более shmem не масштабируется, так что фтопку. C>Именно в этом и проблема с ним.
OLE, извините за выражение, тоже абсолютно не масштабируется. By design.
>> Какие факты? Есть две ущербные программульки, про unix way ничего не >> знающие — так какое они имеют отношение тогда к обсуждаемой теме? C>Есть 99% рынка домашних компьютеров, занятых этими ущербными программами.
Это что-то доказывает? У вас, кажется, с логикой серьёзные проблемы.
C>А многочисленные попытки приспособить The Unix Way к десктопу — провалились.
Чушь. Лучшие десктопные приложения сделаны в рамках Unix Way. Например, лучший и удобнейший в своём классе GUI — у Wolfram Mathematica.
>> C>Пробовал. >> Плохо пробовали. Неумело. C>Я не ежик, чтобы колоться, но продолжать жрать кактус. Причем без C>какой-то перспективы на улучшение.
Это и есть первейший признак хронического ламеризма. Обломиться, сесть под кустик и захныкать.
C>Технические спецификации — это НЕ документация к коду, это НЕ C>документация к существующим системам, их НЕ нужно иметь в 10 форматах, C>они ДОЛЖНЫ удобно редактироваться.
Ну так. Как раз для docbook задача.
Или по вашему "удобно редактироваться" — это в дебильном WYSIWYG, где ненужное (сами сказали) оформление будет постоянно отвлекать от сути? Ну так это и есть махровейший ламеризм. Хорошо, что мне никогда больше не придётся работать с такими, как вы, любителями бардака и бессистемности.
>> Ну ну. Не умеете вы этих кошек готовить. C>Ага. А может это просто кто-то много о себе думает?
Кто-то имеет к тому все основания. У меня-то их готовить получается. И результаты по качеству и скорости на порядки превосходят всё, на что способны вы, вендоводы.
>> Тогда какие на хрен вордоофисы? Это задача для docbook. C>Docbook не подходит по многим причинам: C>1. Редактировать руками его неудобно.
А не надо руками.
C>2. Нет нормальных редакторов.
Есть. Emacs.
C>3. Куча ненужных возможностей.
В отличии от ворда, они не мешают.
C>4. Нет НУЖНЫХ возможностей.
xslt.
>> C>Плохие вордописцы. Или они там формулы рисуют? >> Естественно рисуют. C>Тогда действительно нафиг такое.
Вот вот. А что же это за документы, и без формул? Стихи Пушкина?
C>Ты просто не видел формул. Их и в 2D (на листе бумаги) неудобно иногда C>рисовать, а уж в 1D — вообще невозможно.
Понимаете — формулы не надо рисовать. Вообще. Надо описывать структуру. Каковая всегда — либо дерево, либо в крайнейшем случае циклический граф. На одномерный синтаксис ложится тривиально и интуитивно понятно.
>> C>ROTFL. >> Это вы от незнания. C>Задумайтесь, всякое общее утверждение — неверно.
Это конкретное утверждение. Вы не знаете, что такое GUI и как его правильно готовить, но уже позволяете себе ROTFLить.
>> C>Как раз GUI — это идеальный пример для "компонентов" в понимании >> C>COM/.NET/Delphi. >> Отвратительный пример. C>А что делать? Мир — жестокая штука.
Да нет. Мир — глупая штука. Но он не мешает быть умным и не вестись за толпами идиотов.
>> Идеальный GUI — это, например, Tcl/Tk, с частичной генерацией кода на >> стороне логики. Другой вариант — сервер, отображающий визуальные >> компоненты, которые описываются в виде XML или S-выражений. C>А кто описания строит? Если автомат — то в морг.
C>Ну а задавать расположение визульных компонентов вручную с помощью C>layout'ов (которые можно описывать как угодно) — додумались уже давным C>давно.
Вы абсолютно не в состоянии понять, о чём я говорю. Layout manager-ы тут вообще никаким боком.
>> Всякой дебильной объектщине в GUI и близко места нет. То, что >> извращенцы-объектщики так нагло и упорно в GUI лезут — ни разу им не >> оправдание. C>Ну так функциональщики показали бы класс.
Какие функциональщики? GUI — это такой КА. Вот и описывать его надо как КА.
C>Кстати, и откуда вы это знаете о моем опыте? Читали резюме? Видели мои C>проекты? А?
Человек, считающий ООП идеальной моделью для GUI, опытным быть не может просто по определению.
И свои библиотеки стилей в том числе.
