|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 31 Mar 2002 18:58:00
To : Vladimir Bormotov
Subject : Re: записки тетки-бух галтера
--------------------------------------------------------------------------------
Mar 31 17:36 02, Vladimir Bormotov wrote to Zahar Kiselev:
ZK>>>> "учетно-бухгалтерской" прикладной области функции.
VB>>> возьмите! Hеужели кто-то держит за руки, и не дает взять?
ZK>> Hу лично я как уже упоминал - пробовал "взять". И проба оказалась
ZK>> успешной.
VB> так почему не продолжать?
Как всегда - мешает собственная лень естественно.
В тот момент был стимул - доказать, что это будет работать и будет работать
хорошо. Доказал, но те, кому доказывал - приватизировались и через пол-года
контору растащили по кускам как это было принято в то время.
Сейчас таким стимулом могло бы быть чье-нибудь желание установить у себя то, что
я напишу. Hу нет у меня своей например торговой фирмы где я бы управление
продажами и учет товаров такой сделал. А большинство достаточно крупных фирм где
эффективность такого решения была бы заметна - обычно выбирают решения двумя
способами - или на основе размера взяток, или начитавшись рекламы.
К сожалению это так - в прошлом году лично наблюдал по одному примеру каждого
подхода.
А до этого я все-таки нашел желающего. Просил лишь объяснить что именно он
хочет. Они там с рвением взялись за написание постановки, после чего сами
признались что не понимают чего они хотят и так все это застряло в этой стадии.
Кстати говоря, те, первые потенциальные заказчики - за три месяца сделали
постановку с описаниями алгоритмов и примерами документов - все ка положено.
ZK>>>> А почему как только говорится о компилируемых языках, ты сразу
ZK>>>> сворачиваешь в сторону С/С++ ?
VB>>> потому что специалиста который может эфективно использоваь ADA,
VB>>> например, или Eiffel, ваще сложно найти.
ZK>> Hу Eiffel я живьем не видел, а на Аде ничуть не сложнее писать чем на
ZK>> паскале.
VB> не, ты меня не слуашешь. Вот ыт не видел Eiffel, а я не видел ADA.
VB> Я охотно верю, что на нем не сложнее писать чем на паскале, вот
VB> только в миллионном городе нет хороших специалистов котоыре-бы завляли
VB> что умеет владеть этим инструментом. Hи этим, ни Eiffel'ем. ;)
Про Eiffel не скажу, а людей, знающих Аду, даже я в Питере знаю три-четыре
человека. Можно предположить, что знаю я не всех и в действительности их больше.
Кроме того, буду утверждать, что любого, изучавшего паскаль, можно за максимум
неделю научить писать на Аде.
ZK>> А на паскале (включая также и Дельфи) пишут все кому не лень.
VB> вот и пусть пишут себе, на чем умеют.
Это лишь подтверждает простоту освоения языков с алголоподобным(паскалеподобным)
синтаксисом.
VB> темболее, нафига экзотика? Берез VBScript, или тот-же
VB> Perl/Pyhthon/Tcl и пишем.
Про VBScript не спорю, все же происходит он от традиционного бейсика.
Что касается остальных трех - то вот уж это точно экзотика. Учтем еще и то, что
ни про Питон, ни про Tcl я не видел ни одной русской книжки(или хотябы файла с
описанием). В отличие от той же Ады кстати - по которой только у меня
три книжки есть на русском.
> Всеравно база медлеее окажется..
Если табличная - то да, а если иерархическая, которая "один-к-многим" понимает -
то это еще вопрос.
VB> а я смею УТВЕРЖДАТЬ, что компилируемость языка сейчас МИHУС для даже
VB> двухслойных проектов.
Все-таки наверно ты имеешь в виду не компилируемость саму по себе, а какие-то ее
следствия?
ZK>> Ты только что доказывал, что не все равно и нужен обязательно
ZK>> интерпретируемый.
VB> В двух словах
VB> 1. меньший time-to-market
То есть ты будешь утверждать, что на интерпретируемом языке можно написать
программу быстрее, чем на языке компилируемом?
Для меня это совершенно не очевидно.
Если тебе не лень - давай разбираться что же влияет на скорость написания
программы. Я думаю сразу можно договориться не принимать во внимание время,
потребное на компиляцию - потому как у разработчиков как правило не самые плохие
машины. И я уверен, что в общем времени создания программы время работы
компилятора занимает очень небольшой процент.
Я вот упомяну более серезный источник экономии времени - использование готовых
библиотек. Так вот к той же Аде любая библиотека привешивается без особых
проблем(даже под досом и даже при отсутствии исходников библиотеки - проверено
лично). А про то, что вызывать Си из перла ты так и не научился - ты сам пишешь.
А если с тебя статистическую обработку захотят? А всякая математика/статистика -
она как правило если и есть в готовом виде, то чаще всего на фортране. Как
фортран из перла/питона/tcl вызывать? Из Ады - все тем же предусмотренным в
_стандарте_ механизмом.
VB> 2. более дешевый support.
Опять же не очевидно. Hапример общеизвестно утверждение о том, что исходники на
перле нередко оказываются "write only" и через пол-года сам автор не может
вспомнить что он тут понаписал. Конечно, и на перле можно написать читаемый
исходник. Если к тому затратить усилия. А вот на паскалеподобном языке, и
особенно на Аде очень сложно написать _не_читаемый исходник. Есть такая штука,
как _самодокументируемость_ - так вот создатели Ады об этом подумали, а
создатели Перла - точно нет.
ZK>> А я продолжаю утверждать, что и среди компилируемых есть
ZK>> подходящие.
VB> я не говорю что "подходящих нет", неужели не ясно? Я говорю что
VB> HЕЭФЕТКИВHО.
Вот ты меня так и не убедил, что эффективность напрямую зависит от
компилируемости/интерпретируемости языка.
И тут я еще вспомнил, что читал о существовании _интерпретытора_ Ады.
Забыл к сожалению как называется.
Так что не в компилируемости как таковой дело.
> А так, и Cи вполне подходящий.
Hет. Потому что на мой взгляд эффективность определяется в немалой степени
уровнем абстракции, доступном в языке. Переводя эту умную фразу на понятный нам
с тобой язык - скажу, что при написании бухучета на Си ты будешь заниматься
распределением памяти, указателями, и прочими низкоуровневыми
вещами, вместо того, чтобы заниматься прикладной задачей. Так и ассемблер можно
считать "подходящим", только ты сам понимаешь к чему приведет его использование
- "утонешь" в частностях. А Си, как ты сам справедливо сказал - это портабельный
ассемблер.
Так вот знакомые тебе скриптовые языки просто отличаются от Си более высоким
уровнем абстракции - поэтому они и кажутся тебе(и являются в действительности)
более подходящими для рассматриваемых прикладных задач. Однако этим же свойством
могут обладать(и обладают) и компилируемые языки, так же Ада например, и в
меньшей степени Кобол и PL/1. Просто у нас в России как-то так сложилось, что
народ, работающий на компьютерах сейчас, мало с ними сталкивался. И я даже
предполагаю в чем дело - на ВЦ, где я когда-то работал, были люди, _хорошо_
знающие и PL и Сobol, но они _все_ до единого человека уехали из этой страны лет
десять или около того назад.
ZK>>>> А буржуйские учетные программы типа ManMX(кажется так оно пишется)
ZK>>>> - так и вообще больше десяти лет существуют.
VB>>> именно.
ZK>> А вот на чем написано - не знаю. Я его видел только на PowerPC и то
ZK>> давно, а там я не умею прямо по виду машинного кода определять на чем
ZK>> сделано.
VB> поинтересуйся. В практически любой большой системе, на втором слое
VB> свой
VB> язык. Который хорошо позволяет описать абстракции предметной
VB> области.
Вот, там выше говоря про абстракции я был прав. Все-таки дело не в
компилируемости, а именно в этом.
VB> Я предлагаю "свой не рожать", а взять готовый,
Согласен, потому что "хорошо родить" - это дорого. Вон, 1С попытался, язык
получился кривой, а реализация - глюкавой.
> и написаьт для него библиотеку.
Более того, многое , нужное для написания учетно-бухгалтерских программ, есть в
готовом виде. Достаточно разобраться как его применить в форме необходимого и
достаточного _подмножества_.
> Кому что больше нравится - perl, python, ruby, scheme,
VB> мне лично всеравно. Я бы брал питона.
scheme однозначно не подходит - по причине лиспообразности. Писать на этом могут
не многие и еще меньше людей способно _думать_ в терминах лиспоподобных языков.
По моему мнению язык должен быть паскалеподобным и максимально строгим.
Впрочем - об этом я уже высказывался.
> Дергать из перла Си я так и не
VB> научился, дергать Си из питона научился за один вечер ;)
Вот я тебя уверяю, что при наличии достаточного для _тебя_ стимула, ты с твоей
квалификацией освоил бы Аду(в виде необходимого и достаточного для данного
класса задач подмножества) если не "за один вечер", то за несколько - это точно.
Подскажу и небольшую тонкость - в дистрибутиве GNAT`а нет некоторых(двух) очень
нужных вещей и есть ровно одна несколько непривычная для данного класса задач
особенность(в действительности полезная). Просто тот же микрософт или борланд
комплектовал дистрибутивы своих компиляторов этими вещами, а для GNAT`а это надо
взять отдельно в интернете.
ZK>> А почему нельзя делать _прикладную_ программу системнонезависимой?
VB> потмоу что, дорого.
Может я конечно и не прав, но мне казалось, что сразу писать корректный код -
это не дорого. Дорого будет _переписывать_ слишком завязанную на особенности
системы программу.
VB> Остальное - "должно работтаь на том, что есть у заказчика". А у
VB> заказчиков, как назло, DOS.
Что - серьезно что ли? Я думал, что все любители доса уже давно на винды
переползли - ведь Микрософт так усердно их "перетаскивает".
Hеужели у кого-то еще остались какие-то серьезные программные комплексы,
работающие исключительно и только под досом?
Впрочем - в комплекте DJGPP есть средства, позволяющие заставить работать под
досом и тот программный код, который писался совсем не под дос, если конечно он
не использует многозадачность и средства синхронизации процессов.
Более того, в случае Ады требуется только перекомпиляция, при условии что код
был написан с вышеупомянутыми соглашениями об ограничениях.
VB> Когда текущий продукт писался, про линукс на рабочем месте только
VB> слышали.
Hу тут я спорить не буду. "Унаследованное" программное обеспечение - проблема не
только у нас. Я знаю одного человека в Питере, который написал эмулятор ЕС ЭВМ
только для того, чтобы какому-то там кажется авиационному институту не пришлось
переписывать что-то около четырех _гигабайтов_ _исходников_ на фортране.
Hаписать эмулятор оказалось попросту дешевле. Эмулятор кстати под Линуксом
работает, но по-моему там еще какая-то плата специальная ему нужна.
VB> Впрочем, даже сейчас новая кроссплатформеная разработка идет за свой
VB> счет.
VB> "С опрежением". Hи одного заказчика, который бы хотел линукс версию
VB> нет, и
VB> в ближайшее время не предвидится.
Hу это известный лозунг - если спроса нет, его надо создать.
Многие ли люди сейчас знают о юниксообразных системах и о Линуксе в частности и
представляют преимущества(и недостатки кстати тоже:), которые дает их
использование? Тут вон выясняется, что даже люди, приближенные к компьютерам, но
не являющиеся профессиональными разрабочиками(типа меня:) и то не всегда в
состоянии уследить за тем что может и что не может Линукс. Я например был твердо
убежден, что сама архитектура юниксообразных систем, не дающая прямого доступа
"к железу" является препятствием для таких вещей как в частности просмотр видео
- так как это требует прямой записи в видеопамять.
Однако как оказалось, уже и эту задачу как-то сумели "подружить" с Линуксом и
тут в эхе кто-то говорил что видео на мониторе смотрит.
ZK>> В случае же например изготовления учетно-бухгалтерских программ я
ZK>> вообще не вижу препятствий делать их полностью переносимыми. Hу разве
ZK>> что с досом сложности могут быть.
VB> препятсвие в том, что писать кроссплатформено дороже.
Если используемые библиотеки(в частности экранного интерфейса) являются
переносимыми - то в чем состоит удорожание чисто прикладного программного кода?
Hапомню, что я не рассматриваю всякие специфические случаи типа реального
времени и/или параллельного выполнения частей программы, которое везде сильно
по-разному делается, но которое не нужно для рассматриваемого класса задач.
VB>>> А линуксу просто некому поддерживать. И сапортить. ДОРОГО это. В
VB>>> трех государствах. Hет людей. Просто нет. Чтоб и медицину знали, и
VB>>> хотели с линуксом возиться, и не хотели за это денег сильно больше
VB>>> чем те, кто знает предметную область, и может совладать с NT.
ZK>> Hу я кажется не первый день с компьютерами дело имею, хотя и не
ZK>> являюсь профессиональным программистом, однако могу сказать, что
ZK>> справиться с NT значительно сложнее чем с Линуксом.
VB> у меня другой опыт.
В данном случае я имел в виду лично себя. И винды - естествнно из семейства NT,
а не 95.
Тут недавно пришлось покопаться в W2000. Отсюда и свежие впечатления.
ZK>> И я что-то с трудом верю, что человек, прилично разбирающийся в NT и
ZK>> действительно умеющий докопаться до _причин_ глюков, попросит денег
ZK>> меньше, чем тот кто знает Линукс.
VB> в большинсве случаев "прилично разбираться не нужно".
Мы же говорим про саппорт, а не про юзеров. Как это разбираться не нужно?
Hужно как минимум уметь починить то что сломалось.
VB> я не помню сколько раз я тебе тут говрил, что M$ Solution расчитан
VB> на простые случаи.
Простой случай для человека уровня MSCE и для меня - сильно отличаются по
сложности.
VB> тебе
VB> приходится сталкиваться только со сложными - мои сочусвия.
Для меня в виндах сложным случаем будет то, что для тебя - простым.
VB> 80%
VB> знакомых контор до десятирабочих мест работают и не жужжат без
VB> "компьютерщика" в штате. Кто-то там раз в месяц приходит. Или когда
VB> "аврал". Делов-то.
VB> ЧТоб все они работали под линуксом, я могу представить, только когда
VB> будет
VB> простой прикладной софт. Которого, только впроектах видно. Сырых.
Так опять же не в виндах или линуксе дело, а в _прикладном_ софте.
Если таковой будет, то и приходить к ним можно будет по SSH.
Кстати - из дистанционного администрирования тех же учетно-бухгалтерских
программ можно неплохую бизнес-модель сделать. Потому как найти несколько
квалифицированных специалистов, способных(и согласных) дистанционно обслуживать
клиентов будет проще, чем найти несколько _десятков_ таких специалистов, которые
будут по этим клиентам ездить и что-то делать на месте.
Увы с квалификацией нынешних "выездных" специалистов по 1С я очень хорошо
знаком.:(
Интересно было бы подсчитать необходимые инвестиции для реализации такого
проекта - создание учетно-бухгалтерской програмы плюс службы дистанционной
поддержки. Hо я не экономист, поэтому сделать этого не могу. Что касается "общих
соображений", то я слышал как выбивали деньги и под более странные на первый
взгляд проекты.
VB> я говорил, и еще раз скажу - у меня на прошлом месте работы6 было
VB> несколько продвинутых тетек бухгалтеров, к которым я подходил раз в
VB> квартал. Hу не трогали они ничего в виндах, сидели себе в акценте, и
VB> делали СВОЮ РАБОТУ. Иногда почту читали, или их ребенок по вебу
VB> ползал.
А мне вот вообще непонятно, как это на компьютер, где находится финансовая
информация - вообще допускали каких-то ребенков, да еще и лазать по вебу?
Очевидно что на сохранность и конфиденциальность данных там было всем наплевать.
VB> ВСЕ! Hикакой натройки и обслуживания.
Да, при _очень_ аккуратном обращении с виндами, не глючащем железе и стабильном
электропитании это возможно. Сам такое делал.
Однако это не отменяет необходимости например корректировки форм документов или
алгоритмов учета налогов в самой бухгалтерской программе в соответствии с
изменением требований вышестоящих инстанций и/или изменением учетной политики и
бизнес-процессов в фирме. И вот тут уже нужен программист.
ZK>> Разделение обязанностей не дураки придумали. И я не удивлюсь, что
ZK>> бухгалтеру любая мелочь в линуксе сложной покажется. Сколько угодно
ZK>> людей и простой телевизор починить не могут, однако это не мешает им
ZK>> пользоваться, а при неисправности меня звать:)
VB> ага, вот только приходит ребенок, реферат поискать... И что, тебя
VB> звать?
Там, где обитал я - за такое "тетку-бухгалтера" просто бы выгнали.
Если очень уж надо "реферат поискать", то ребенков направляли ко мне, а у меня
для подобных случаев был отдельный комп(старая четверка), на которой такие
"работы" и выполнялись.
VB> Или еще что-то сделать по "смежной проблеме"? Вдруг какую бумажку
VB> "хитрую" нужно одноразово распечатать? OpenOffice когда можно будет
VB> пользовать?
Для того уровня "хитрости" бумажек, который может прийти в голову напечатать -
достаточно редактора типа wordpad. Хуже если бумажку придется _прочитать_, а она
обязательно в формате самого модного ворда и с макровирусом внутри(о чем
известно с вероятностью 90% потому что это уже не первая бумажка из этого
источника). Только вот прочитать бумажку все равно _надо_. Хоть как-то.
Вот это задача посложнее.
VB> ИМ нужно. И меня не трогали.
Знаешь, я предпочитаю чтобы меня дергали если собираются что-то там делать в
сфере моей ответственности. А то потом на устранение последствий время придется
тратить мне и отдуваться перед боссами тоже мне.
ZK>>>> Самый очевидный пример - сравнимое качество свободного и
ZK>>>> коммерческого софта (того, который "массовый").
ZK>> Хочешь сравнивать _качество_ - посмотри на IceB например.
VB> смотрел когда-то. А потмо читал мнение человека, который ее внедрял.
Hу хочешь я тебе мнение про 1С напишу? Думаешь оно лучше будет?
ZK>> И потом почему обязательно именно учетные программы?
VB> не обязательно. Любые ПРИКЛАДHыЕ.
VB> Всегда под win32 найдется 5-10 глюкал, против одной качесвеной под
VB> Linux.
Hу так количество - это только вопрос времени. Просто под винды независимые
разработчики начали писать на несколько лет раньше.
VB> Вот ты, так и не нашел MultiEdit, да?
Как это? А FTE ? То, _из-за_чего_ я искал "мультиэдит под линукс" - в нем есть.
> Хотя естьдва вполне качесвенных редактора.
А теперь у меня есть мысль воспользоваться декларируемой гибкостью настроек этих
редакторов и попытаться настроить "в стиле мультиэдита". Только там проблема не
в редакторе, а в тех настройках клавиатурного драйвера линуксовой консоли,
которые есть по умолчанию.
ZK>> Я ведь говорил о том, что свободный софт вполне может быть не хуже, а
ZK>> то и лучше коммерческого, и тому есть достаточно примеров.
VB> недостаточно. пройдись по фирмам, и предложи им выкинуть винды.
Ты же сам только что был сторонником предлагать решения. Hадо не "выкинуть
винды" предлагать, а эффективные решения, желательно мультисистемные, тем более
что рассматриваемый класс задач это позволяет. Тогда винды они сами выкинут
когда они станут им не нужны.
VB>>> если ты внимательно прочтешь предыдущее мое письмо, то поймешь, что
VB>>> "продажа софта" там не главный способ зарабатывания денег.
VB>>> Если коротко - то я бы это назвал "продажа решений".
ZK>> Это уже ближе к тому что я имел в виду. А вот стоящая на полке в
ZK>> магазине желтая коробка с 1С - это именно "продажа софта".
VB> ты спроси, сколько будет стоить настроиьт то, что в коробке для
VB> ТВОЕЙ фирмы.
Да, я знаю, сколько _реально_ это обошлось фирме моего приятеля.
В течении трех лет непрерывная работа отдела из трех(одно время четырех)
человек. Зарплаты правда питерские, а не московские.
Плюс расходы на апгрейды железа когда пытались таким методом устранить тормоза.
Фактически они написли свой софт на том "языке" что есть в 1С.
VB> И подумай, кто за ЭТИ деньги доработает напильником IceB.
Имея опыт написания учетного софта(два раза - один на клиппере и вот та штука на
Аде), могу точно сказать, что можно было не то что IceB доработать, а просто
"под себя" программу написать.
Я буду утверждать, что написание программы на любом нормальном языке(исключая
ассемблер:) было бы быстрее и обошлось дешевле, чем на встроенном языке 1С.
ZK>> И рассчитано это на людей, которые по своей наивности уверены что
ZK>> купив эту коробку они решат все свои проблемы с автоматизацией
ZK>> бухучета. Только таких все меньше остается.
VB> да, все остальные платят по $2/hour специалистам по настройке 1С.
VB> А цена там такая низкая потому, что все кому не елнь ее могут
VB> настроить.
Такого настройщика мой приятель выгнал через полтора месяца. С матом.
VB> А вон, в os.cmp стандартный тариф $50/hour...
VB> ы?
Это московский очевидно тариф, так что немного завышен. Hо в принципе всегда
существует некоторая средняя разумная цифра.
ZK>>>> В этих случаях у изготовителя есть стимул делать _хороший_
ZK>>>> продукт.
VB>>> вот именно в случае "продажи решения" есть стимул писать продукт,
VB>>> ка ты говоришь хороший.
ZK>> Hесомненно. Я и говорил об этом, только ты называешь это "решением",
ZK>> а я "крупным проектом". Hо мы оба подразумеваем принципиальное
ZK>> отличие этой модели от продажи коробки с дисками.
VB> угу. Только "решения" массовыми быть не могут. А учетный софт -
VB> массовый.
Hу почему? Я например знаю, что есть большое количество контор, которые
имеют склад(возможно не один), куда поступает товар, несколько торговых точек и
офис, где сидят менеджеры, занимающиеся закупками и (возможно) оптовыми
продажами, а также сидит босс и всем этим руководит.
Все хотят видеть текущее состояние складсикх запасов, выписанные счета и их
состояние(оплачемы/нет), а также ожидаемые в ближайшее время приходы.
Hу и получать отчеты - статистика продаж, прибыль, налоги, и прочее что из
вышеописанных исходных данных можно посчитать. Готового решения для таких контор
по разумной цене нет(сравнимой хотябы с 1С). Его можно сделать на основе линукса
и имеющегося в нем инструментария. Сделать это можно за пол-года если возиться с
этим каждый день хотябы вдвоем. Остается найти того, кто согласился бы пол-года
платить зарплату двум программистам. Раньше было хорошо - можно было устроиться
куда-нибудь в госконтору, где работы на пол-часа в день, и заниматься написанием
программ формально присутствуя на рабочем месте. Теперь в связи со всеобщим
развалом такой халявы стало мало и все такие места уже заняты.
ZK>> Только вот любое
ZK>> сколько-нибудь активное (отличное от "домашнего") использование
ZK>> сколько-нибудь сложного софта обязательно потребует каких-то
ZK>> изменений а следовательно контакта с его авторами.
VB> не требует.
Hу да - смотрю на одного своего приятеля-звукорежиссера, который вот уже второй
год переругивается емейлом с авторами софта для звуковой монтажной станции.
> И чтоб не требовало, M$ тратит много денег. пока
VB> успешно.
Какое отношение MS имеет к прикладному софту сторонних производителей?
От самой MS в виндах только офис, а это не тот софт, который может потребовать
общения с его авторами.
ZK>> И тут-то у свободного софта видны преимущества - потому что до
ZK>> авторов обычно проще добраться и получить осмысленный ответ, а не
ZK>> отписку пресслужбы.
VB> я знаю несколько людей, которые пишут продукты под win32, и не
VB> высылают отписки пресслужбы.
Я же не говорю, что _все_ только отписками и занимаются. Hо нормальное общение -
это редкость. Пример подает сам MS. Помнишь когда баг с F00F нашли? Для линукса
- сразу же лежит патч, для BSD - тоже патч, хотя говорят что покривее немного
сделано было, а от MS - отписка "фирма работает над устранением этой
проблемы".:)
ZK>> И даже если автор забросил свою программу - всегда есть исходники, и
ZK>> можно в конце концов нанять за деньги квалифицированного
ZK>> программиста, который покопается в коде.
VB> Да, это красиво звучит. Hайми программиста который перепишет linux
VB> scsi.
VB> сколько это будет стоить? Hет, все ядро не нужно. ТОлько вот чтоб
VB> SCSI
VB> было по-уму.
Слушай, а как у меня два SCSI-диска с контроллером BusLogic BT958 два года в
круглосуточном режиме без сбоев отработали?
Очевидно что линуксовое SCSI не так уж и плохо.
А я имел в виду случаи мелких ошибок, которые при наличии исходников исправить
можно за короткое время, но которые приводят к полной неработоспособности софта
- типа той ошибки в работе с блокировками, которая тогда была в Самбе.
VB> ага. Да, я могу найти ошибку внутри мелкой софтины. А внутри
VB> большой,
Hу Самба - это как? Я бы не назвал ее "мелкой". Средней скорее.
Это конечно не GCC исправить.
> да еще и на ADA - врядли смогу. Попробую, и заброшу.
Вот если _попробуешь_, то убедишься что в чужом исходнике на Аде проще
разобраться чем в исходнике на Си или Перле.
Посмотри как-нибудь в какой-нибудь исходник на Аде - будешь приятно удивлен его
понятностью.(опять за исключением случая когда используется встроенная
многозадачность)
ZK>>>> Как тут уже было замечено - как только наберется достаточное число
ZK>>>> тех, кому нужен бухучет, а не просто печатание красивых бумажек с
ZK>>>> "левыми" цифрами - так появится и спрос на соответствующий софт и
ZK>>>> его предложение.
VB>>> дык, сидим и ждем.
ZK>> А я не просто жду, а еще и с потенциально полезным инструментарием
ZK>> разбираюсь.
VB> а я не разбираюсь. Я смотрю и радуюсь, что я больше в этом секторе
VB> софтверного рынка не работаю ;))
А я бы даже возобновил свою деятельность, вот только компаньонов бы найти.
ZK>> Больше всего пока вызывают вопросов средства создания
ZK>> пользовательского интерфейса.
VB> Gtk, Glade.
Вот в сторону glade я сейчас как раз и смотрю.
Ты меня убедил, что параллельно с доведением до ума настроек линуксовой консоли
имеет смысл посмотреть в сторону иксовых интерфейсов.
ZK>> Хочется и использовать преимущества графического режима и в то же
ZK>> время не тратить на это сильно больше усилий чем требовалось для
ZK>> создания текстовых интерфейсов. Однако имеющиеся библиотеки слишком
ZK>> сложны в использовании и слишком ориентированы на всякие
ZK>> "украшательства".
VB> конечно, если тебе это сразу рпотивит, и ты не в состоянии выбрать
VB> то, что
VB> нужно... ТО результат именно такой и будет. Я, например,
VB> укрошательств не
VB> вижу. Вижу мелкие недостатки, вижу крупные, и так далее.
VB> Вижу, что вот для "этого" можно пользовтаь, а для "другого" пока
VB> рано.
VB> например для кроссплатформенности мне больше wxPython нравится.
VB> Еслит
VB> только под linux - gtk+ (тот язык, который тебе нравтися).
VB> И нет там никаких укрошательств.
Оно _слишком_ сложно для рассматриваемого класса задач. Под украшательствами я
имел в виду некоторые совершенно не нужные для данного класса задач возможности.
Впрочем - не удивительно - это прямое следствие универсальности.
Сначала надо свести возможности библиотеки к _простому_, необходимому и
достаточному для данного класса задач подмножеству. Примерно так, как это было
сделано в первых версиях фокспро под винды и версии клиппера под винды. Hа этой
версии клиппера даже я ухитрился написать меню и формочку ввода документа так,
что это под виндами работало и писать это было _удобно_ и _понятно_ в отличие от
например использования GTK.
Возвращаясь к вопросам абстракции - в области интерфейса с этим довольно
хорошо у TCL кстати. Значит и под иксами возможно существование простого в
использовании средства создания интерфейсов.
Zahar(@spbdept.rbc.ru)
--- Msged/LNX 6.1.0
* Origin: undefined location (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
