|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Victor Wagner 2:5020/400 11 Nov 2002 23:11:03
To : Alexey Veretennikov
Subject : Re: Вопросы к выбору
--------------------------------------------------------------------------------
Alexey Veretennikov <Alexey.Veretennikov@p39.f113.n5020.z2.fidonet.org> wrote:
AV> Вот теперь начинается резговор. ТеХ я знаю и усиленно использую в
AV> виндах. XML -
Hу так и используй дальше. В Unix-программировании есть один
основополагающий принцип (даже не в программировании а в работе
пользователя) - если тебе лень читать вывод/писать ввод для некоторой
программы, заставь это делать другую программу.
У тебя еще есть вопросы как сделать из своей программы на C++ (под любую
платформу) красивый отчет, если на компьютере, на котором она
запускается, установлен TeX?
Причем принцип универсальный. Подозреваю, что выписывать на C++ генерацию
теховских команд, котоыре посредством окружения picture нарисуют тебе
нужный график, тебе тоже лень.
Так берешь программу gnuplot, говоришь ей set term=latex кормишь в нее
данные, и получаешь TeX-овский файл, который и втыкаешь в генерируемый
отчет. В Unix я бы все это реализовал так, что весь отчет
последовательно бы лился в одни файловый дескриптор. Под виндами могут
быть сложности. То есть в нормальных виндах все нормально. А в 9x - ну
нет там нормальных пайпов.
AV> приходилось использовать мало, в основном для генерации ответа от MS SQL.
AV> Чем он может помочь, и как его использовать в случае автоматической
AV> генерации
Так и может. Его очень легко генерировать из своей программы.
Если DTD правильно сдизайнена исходя из потребностей твоей проблемной
области.
Дальше берешь и пишешь xslt, которая преобразует твою DTD скажем, в
xsl-fo, или в то что последние ворды умеют кушать, или в тот же самый
LaTeX.
AV> отчетов моей программой? Желательно сразу ссылки.
Какие нафиг ссылки? Чистый здравый смысл.
В виндовой культуре потеряна (несмотря на все усилия Микрософта по
поводу внедрения всяких DDE и ActiveX) одна большая и ценная концепция
существовавшая ранее в IT - программа имеет возможность пользоваться
всеми теми же инструментами для решения своей задачи, какими может
пользоваться пользователь для решения этой же задачи вручную.
VL>> Встраиваемых средств визуализации под виндой тоже
VL>> маловато, даже приблуду уровня gnuplot - и то весьма непросто в своё
VL>> приложение встроить.
AV> Так-так. Легко ли в xfree86 создать окно и рисовать в нем? Конструктивный
AV> ответ, пожалуйста.
Во-первых, если хочешь получить ответ на свой вопрос, про free86 забудь
сразу. Есть стандарт. X Window System version 11 release 6. (про release
лучше тоже забыть, от греха) Есть его конкретные реализации. Одна из
которых называется XFree86. Если она и обладает какими-то свойствами,
которых не упомянуто в стандарте, то лучше в своей программе эти
свойства не использовать. Дабы не было мучительно больно, когда
выяснится что на соседнем Sun-е с Solaris, куда пришлось переползти ибо
мощности писюка объективно не хватает, это вдруг не работает. Или еще
того хуже - на локальном дисплее показывается, а на X-сервере,
установленном на твоей любимой виндовой рабочей станции - не
показывается.
Вообще, что касается встраиваемых средств то здесь вопрос ставится не
"создать окно и рисовать в нем", а "создать фрейм и велеть другой
программе разместить свое окно в нем", или "создать окно, и дать другой
программе хэндл пиксмэпа этого окна, чтобы она в нем рисовала".
И та, и другая функиональность в X-ах базовая и тривиальная. Об этом не
подозревают разве что авторы Gtk и Qt (и то наверное подозревают -
kghostview как-то работает)
VL>> создавать диалоги в тулките, в коем даже нет layout manager-а? Да это
VL>> надо очень сильно презирать себя и ненавидеть своих
VL>> пользователей, чтоб до такого дерьма опуститься!
AV> Hу, это все слова. Где примеры.
Примеры находятся на раз и в вебе, и в книжном магазине. Hадо только
дать себе труд выйти за рамки привычных концепций.
Я понимаю, очень тяжело привыкнуть к мысли, что не надо самостоятельно
размещать в диалоге кнопки, надо сказать программе "вот эти три кнопки в
ряд внизу окна" и все будет как надо.
Виндовая культура отучила пользователей доверять программам.
>>> - тут встает множество вопросов.
VL>> Пока вопросов не видел. Были глупые наезды, проистекающие из
VL>> безграмотности, дурной инициативности и наличия множества вредных
VL>> привычек.
VL>> А это к чему? Кроссплатформенного тулкита захотелось? А какой вообще
VL>> резон привязываться к одному конкретному тулкиту? Логика - отдельно,
VL>> гуйня - отдельно, структура гуйни - посередине.
AV> Вот мне и необходимо бысто написать структуру gui. Логика отдельно уже есть.
AV> И
Тебе необходимо написать быстро написать структуру?
Hу так и вооружись инструментом, который позволяет ее именно писать, и
именно быстро, а не аккуратно с точностью до пиксела разрисовывать.
Потом выяснится что проще запустить это же самое под виндами, чем
портировать.
>>> Я имею ввиду среды типа Kylix или
>>> JBuilder - действительно мощные ide.
VL>> С каких это пор эти помои стали IDE?!?
AV> :-) no comments.
А зря. Я, пожалуй, покомментирую. В данном контексте под IDE, вероятно,
понимается не Integrated Drive Electroncs, а Integrated Development
Environment. Что по-моему масло масляное. Как же это Environment, и не
Integrated? Во всяком случае все, чему меня научили в свое время по
поводу разнообразных envirоnment-ов на географическом факультете МГУ,
против этого восстает.
Таким образом, Development Environment это объединенный некими общими
интерфейсными концепциями набор инструментов, позволяющий решать
все задачи, связанные с тем, что понимается под словом Development,
в рамках единой среды.
Hачинаем, рассматривать вопрос о том, какие, собственно, задачи
возникают в процессе разработки программы:
1. Обсуждение и согласование спецификации программы. Где в JBuilder
средства collaboration? А в Emacs есть и почтовый и ньюсовый клиент.
2. Разработка алгоритмов, иерархий классов etc. По-моему, с этим, в
частности с рисованием UML- и ER-диаграм там тоже есть проблемы.
Как с этим работает Emacs, признаюсь честно, не знаю. Вот dvi в wysiwyg
показывать, это он умеет.
3, Изучение документации на используемые инструменты. Опять таки, не
видел ни одной винодовой среды разработки, кроме разве Homesite, где бы
это было интегрировано. Да собственно зачем? Мощных средств работы с
текстом, которые бы делали чтение хелпов в борландовском редакторе
более удобным, чем в Winhelp все равно нет. А в Emacs - info mode.
4. Собственно написание кода. Hу ладно, человек который не работал ни с
одним из двух настоящих текстовых редакторов и знать не знает что в этой
области можно что-то усовершенствовать. А ведь можно. Разнообразный
completion, навигация по логическим фрагментам кода, навигация по файлам
(не только явным образом включенным в проект), folding
5. Подготовка тестовых данных.
6. Сравнение результатов тестового прогона с ожидаемым. Есть в Jbuilder
встроенный diff?
7. Поддержка жизненного цикла проектов, интеграция с системой
версионирования исходных текстов.
9. Разработка документации. Где в
Jbuilder средства работы с SGML/XML, аналогичные PSGML, и с TeX,
аналогичные AucTeX?
>>> Правда интересют ide для языка C++
Опять же, следствием идеологии Unix является использование для крупного
проекта нескольких разных языков. Для каждой задачи свой, наиболее
удобный именно для нее инструмент. GUI пишем на Tcl/Tk, AI на Common
Lisp, обработку текстовых данных на perl, xml-ных - на xslt,
расчеты на C или C++. А можно
и на Fortran90, ежели под него библиотеки есть, а под плюсы - нет.
И все это замечательно интегрируется. Здесь Emacs с vim-ом опять-таки
вне конкуренции. Они все вышеперечисленные языки умеют. В смысле
вышеприведенного пункта 4. И еще пару сотен других.
AV> :-) Мне хватает одного c++. Я не пишу "все подряд", мне не нужны доступ к
Это снижает скорость разработки примерно на порядок.
Как не пишешь "все подряд"?
Ты пишешь
а) GUI
б) алгоритмику
в) обработку больших потоков данных.
г) графическую визуализацию оных данных
Более "всего подряд" мне и представить себе трудно
AV> интернет базам данных или еще какие проблемы, мне необходимо
AV> обрабатывать кучи данных (в десятках гигабайт), и делать с ними
AV> нетривиальные преобразования. Что я, perl для этого использовать
AV> буду? :-)))
А попробуй. Есть шанс, что на Perl проанализировать файл из нескольких
десятков гигабайт и откинуть лишнее будет быстрее, чем на C++.
А нетривиальные преобразования пишешь на том же C++ и цепляешь к перлу
через xsub interface.
При всем моем уважении к тебе как программисту, я не верю что ты можешь
позволить себе потратить на оптимизацию базовых примитивов работы с
текстом (regexp engine, например) столько времени, сколько на это
потратили Ларри Уолл и компания. А правильно написанный скрипт на perl
99% времени при обработке больших данных тратит как раз на этих
встроенных конструкциях.
AV> программу, но не программиста. Я не знаю, чем вы занимаетесь по
AV> работе. И я не являюсь программистом-маниаком, который в свободное
AV> от работы время пишет кластерную ОС для Psion. Я математик, и от
AV> средств разработки, которыми пользуюсь, требую удобства в обращении.
Именно поэтому стоит немножко потратить время на изучение Unix way.
Хотя бы книжек почитать. Потому что по опыту многих здесь присутсвующих,
проекты, написанные на одном языке, удобством в обращении (в смысле
развитии и модификации) не обладают. А если этот язык еще и С++...
Этот язык обладает тем неудобством, что из программы на нем ты решаешь
всякие разные задачи не так, как ты их решаешь, когда работаешь как
пользователь.
AV> Я не собирался переходить на linux, меня уговорили системщики.
AV> Hо, повторяю, я не оскорбляю никого, не называю вышеприведенными
AV> словами. В ответ прошу такого же отношения.
P.S. Hу не обижайся ты на Луговского. У него амплуа такое "кругом все в
дерьме, и тут я, весь в белом". Что совершенно не мешает ему иногда
говорить умные вещи. Правда, в пылу гневного возмущения его тоном, его
обычно не слышат.
--
Брюки протираются даже на троне.
--- С.Е. Лец
--- ifmail v.2.15dev5
* Origin: Free Net of Leninsky,45 (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
