|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Victor Wagner 2:5020/400 12 Nov 2002 11:20:54
To : Alexey Veretennikov
Subject : Re: Вопросы к выбору
--------------------------------------------------------------------------------
Alexey Veretennikov <Alexey.Veretennikov@p39.f113.n5020.z2.fidonet.org> wrote:
VW>> любую платформу) красивый отчет, если на компьютере, на котором
VW>> она запускается, установлен TeX?
VW>> Причем принцип универсальный. Подозреваю, что выписывать на C++
VW>> генерацию теховских команд, котоыре посредством окружения picture
VW>> нарисуют тебе нужный график, тебе тоже лень.
AV> Обычно если я пользовался генерацией .tex файлов, то создавал .bmp и включал
AV> его по \includegraphics
График в bmp? Фи, это все равно что рыбу ножом. Я понимаю еще в eps
или MetaPost. Ведь график в bmp с разрешением 75 dpi будет безобразно
коряво выглядеть на принтере с разрешением 1200, а bmp на 1200 dpi на
экране в 75 просто потеряет все линии.
VW>> Примеры находятся на раз и в вебе, и в книжном магазине. Hадо только
VW>> дать себе труд выйти за рамки привычных концепций.
AV> Вот концепции как раз и представляют проблему.
Это я согласен. TeX, пожалуй единственная софтина, авторы книжек по которой
это осознают. По Unix тоже есть парочка хороших концептуальных книжкек,
Керниган и Пайк "Среда программирования Unix" (The Unix Programming
Environment) например. Она, конечно, старая, ей почти столько же лет,
сколько Unix-у. Hо концепции-то с тех пор живы. А появившиеся позже уже
можно по аналогии.
VW>> 2. Разработка алгоритмов, иерархий классов etc. По-моему, с этим, в
VW>> частности с рисованием UML- и ER-диаграм там тоже есть проблемы.
VW>> Как с этим работает Emacs, признаюсь честно, не знаю. Вот dvi в
VW>> wysiwyg показывать, это он умеет.
AV> Решалось с помощью Rational Rose (для msvc по крайней мере)
AV> Как раз об этом есть очередной вопрос: отдельные CASE - средства типа
AV> ERWIN/BPWIN есть?
Hу есть RR, есть Oracle Developer, есть куча всяких прибабахов на Java
типа ARGO UML.
VW>> 3, Изучение документации на используемые инструменты. Опять таки, не
VW>> видел ни одной винодовой среды разработки, кроме разве Homesite, где
VW>> бы это было интегрировано. Да собственно зачем? Мощных средств работы
VW>> с текстом, которые бы делали чтение хелпов в борландовском редакторе
VW>> более удобным, чем в Winhelp все равно нет. А в Emacs - info mode.
AV> В принципе MSDN устраивал. Есть ли нормальная смотрелка info, чтоб глаза от
AV> текстового режима не болели?
1. Emacs.
2. TkInfo
4. Чтобы глаза от текстового режима не болели, все текстовые программы
следует пускать в правильно настроенном xterm.
Какая настройка xterm правильная (шрифты, цвета etc) решать тебе. Для
меня это черный фон, светло серые буквы и шрифт примерно 10x20. Лучше
Болховитяновский, чем cronyx.
Только надо сначало выяснить разницу между monospaced и character cell
шрифтами.
VW>> 4. Собственно написание кода. Hу ладно, человек который не работал ни
VW>> с одним из двух настоящих текстовых редакторов и знать не знает что в
VW>> этой области можно что-то усовершенствовать. А ведь можно.
VW>> Разнообразный completion, навигация по логическим фрагментам кода,
VW>> навигация по файлам (не только явным образом включенным в проект),
VW>> folding
AV> Hадо проверить.
VW>> 5. Подготовка тестовых данных.
AV> Этого нет нигде. ИМХО неформализуемая задача.
Hу не более неформализуемая, чем написание кода.
VW>> 6. Сравнение результатов тестового прогона с ожидаемым. Есть в
VW>> Jbuilder встроенный diff?
AV> ?
Hу вот видишь!!!
Представь себе что у тебя есть две простыни отладочного вывода
мегабайт по двадцать. И в строке номер 158234 там есть первое
расхождение, увидив которое, ты сразу начнешь бить себя пяткой в лоб,
и исправишь ошибку через пять минут.
Что делаю в таком случае я?
Говорю vimdiff простыня.1 простыня.2
и вижу
+--- 158232 одинаковых строки|+--- 158232 одинаковых строки
ччч |ччч
good |$:па
ццц |ццц
+--- 1000000 одинаковых строк|+--- 1000000 одинаковых строк
VW>> При всем моем уважении к тебе как программисту, я не верю что ты
VW>> можешь позволить себе потратить на оптимизацию базовых примитивов
VW>> работы с текстом (regexp engine, например) столько времени, сколько на
VW>> это потратили Ларри Уолл и компания. А правильно написанный скрипт на
VW>> perl 99% времени при обработке больших данных тратит как раз на
VW>> этих встроенных конструкциях.
AV> Я работаю не с текстом, а с потоками байт.
А что есть текст, как не поток байт? Хотя согласен, если у тебя 10-20Gb
бинарных данных с каждого эксперимента, обработка должна вестись на...
Стой, а не image ли это у тебя? Если image, то обрабатывать его имеет
смысл на Script-Fu.
VW>> Потому что по опыту многих здесь
VW>> присутсвующих, проекты, написанные на одном языке, удобством в
VW>> обращении (в смысле развитии и модификации) не обладают. А если этот
VW>> язык еще и С++...
AV> Возможно.
VW>> Этот язык обладает тем неудобством, что из программы на нем ты
VW>> решаешь
VW>> всякие разные задачи не так, как ты их решаешь, когда работаешь как
VW>> пользователь.
AV> Естественно. Hо как если использовать соответствующий язык для задачи, то
Если использовать соответствующий язык для задачи, то в
производительности выиграешь.
Только надо задаче четко поставить границы.
AV> можешь потерять в производительности. Вспомним prolog. Должна
AV> быть золотая середина. В идеале хотелось бы писать саму логику и
AV> обработку данных на одном языке, а все остальное (интерфейс и т.п.)
AV> чтоб получалось автоматически, стандартно, привычно и удобно. Хоть
AV> мышкой в менюшках галочки потыкать, заполнив стандартные формы. Hо
AV> учить еще один очередной язык для этого (я из
А ты попробуй поучить. После десятого языка, изучить новый язык для
решения новой задачи будет казаться гораздо проще, чем продраться через
диалог с тремя закладками. Я серьезно. Потому что начинаешь мыслить на
метаязыковом уровне абстракции.
AV> принципа работая в Rational Rose UML не учил) - это не вариант.
UML это не язык, Это скорее система условных знаков для диаграм.
AV> Пусть это хоть C++ с десятью плюсами. Как давно вошел в
AV> использование XML? Вот tex или c - это хоть понятно.
Дело не в том, как давно. Дело в том, что XML это не язык. Это подложка
для легкого и простого конструирования своих, заточенных под задачу
языков. Чтобы сочинить язык, но использовать для него готовые парсеры,
готовые инструменты трансформации и т.д.
Т.е. это инструмент для тех, кто не то что "выучить новый язык"
- "сочинить новый язык" считает вполне разумными трудозатратами.
--
Три главных добродетели программиста - лень, гордыня и нетерпение
-- Ларри Уолл.
--- ifmail v.2.15dev5
* Origin: Free Net of Leninsky,45 (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
