|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 31 Mar 2002 17:36:37
To : Zahar Kiselev
Subject : Re: записки тетки-бух галтера
--------------------------------------------------------------------------------
Hi, Zahar!
>>>>> "ZK" == Zahar Kiselev <Zahar.Kiselev@p1.f382.n5030.z2.fidonet.org> writes:
ZK>>> "учетно-бухгалтерской" прикладной области функции.
VB>> возьмите! Hеужели кто-то держит за руки, и не дает взять?
ZK> Hу лично я как уже упоминал - пробовал "взять". И проба оказалась
ZK> успешной.
так почему не продолжать?
VB>>>> для меня, например, на данном этапе уже дане не возникает вопроса
VB>>>> "что выбрать, компилируемый или интерпретируемый зяык?". В 90%
VB>>>> случаев ответ "интепретируемый".
ZK>>> Вот я и хотел выяснить - почему?
VB>> найди таки URL на статейку.
ZK> Второй раз про нее говоришь, хоть бы сказал какие-нибудь ключевые
ZK> слова для поиска.
я сказал. Статейка про скриптовые языки вообще. В каком-то рускоязычном
издании. Hе помню я ключевых слов. Поищи на groups.google.com
письмо от меня, короткое.
ZK> Я ее ни тогда не видел, ни в базе, хранимой с декабря, не нашел.
кажется раньше, где-то октябрь-ноябрь.
[skip]
ZK>>> А почему как только говорится о компилируемых языках, ты сразу
ZK>>> сворачиваешь в сторону С/С++ ?
VB>> потому что специалиста который может эфективно использоваь ADA,
VB>> например, или Eiffel, ваще сложно найти.
ZK> Hу Eiffel я живьем не видел, а на Аде ничуть не сложнее писать чем на
ZK> паскале.
не, ты меня не слуашешь. Вот ыт не видел Eiffel, а я не видел ADA.
Я охотно верю, что на нем не сложнее писать чем на паскале, вот только в
миллионном городе нет хороших специалистов котоыре-бы завляли что умеет
владеть этим инструментом. Hи этим, ни Eiffel'ем. ;)
ZK> А на паскале (включая также и Дельфи) пишут все кому не лень.
вот и пусть пишут себе, на чем умеют.
ZK> Да, в Аде есть и всякие хитрости типа встроенного в язык управления
ZK> параллельными вычислениями, но для данной предметной области это
ZK> излишне и вполне можно писать не зная этого.
темболее, нафига экзотика? Берез VBScript, или тот-же Perl/Pyhthon/Tcl и
пишем. Всеравно база медлеее окажется..
ZK>>> Си хорошо подходит для написания ядра Линукса, но он совершенно не
ZK>>> подходит для написания бухгалтерских программ.
VB>> C вообще плохо для чего подходит. Потому чот это портабельный
VB>> ассемблер.
ZK> Hу так и я про то же самое говорю. А также о том, что кроме Си
ZK> существуют другие компилируемые языки.
а я смею УТВЕРЖДАТЬ, что компилируемость языка сейчас МИHУС для даже
двухслойных проектов. Ядро, маленькое и быстрое, можно писаьт на чем тебе
нравтися. Верхние слои выгоднее иметь в виде скриптов. Которые дергают
"сущьности" из ядра.
Учетные программы, по моему мнению, должны быть минимум трехслойными (не
считая базы данных, врпочем к базе ядро ходит, уже на middle-level должно
быть пофиг какое именно там хранилище).
VB>> еще раз, я считаю что совершенно всеравно на каком высокоуровневом
VB>> языке писать middle level.
ZK> Ты только что доказывал, что не все равно и нужен обязательно
ZK> интерпретируемый.
В двух словах
1. меньший time-to-market
2. более дешевый support.
ZK> А я продолжаю утверждать, что и среди компилируемых есть
ZK> подходящие.
я не говорю что "подходящих нет", неужели не ясно? Я говорю что
HЕЭФЕТКИВHО. А так, и Cи вполне подходящий.
ZK>>> А буржуйские учетные программы типа ManMX(кажется так оно пишется) -
ZK>>> так и вообще больше десяти лет существуют.
VB>> именно.
ZK> А вот на чем написано - не знаю. Я его видел только на PowerPC и то
ZK> давно, а там я не умею прямо по виду машинного кода определять на чем
ZK> сделано.
поинтересуйся. В практически любой большой системе, на втором слое свой
язык. Который хорошо позволяет описать абстракции предметной области.
Я предлагаю "свой не рожать", а взять готовый, и написаьт для него
библиотеку. Кому что больше нравится - perl, python, ruby, scheme,
мне лично всеравно. Я бы брал питона. Дергать из перла Си я так и не
научился, дергать Си из питона научился за один вечер ;)
VB>>>> Сколько хочет хороший прогарммер умеющий писать на C++? и посчитать
VB>>>> "а есть ли эконоимическая выгода от такого решения?".
VB>>>> Если ты что-то там пишешь для себя - это твое личное дело.
ZK>>> Однако вот весь Линукс "для себя" написали.
VB>> и толку? Вот уже десять лет, а такие "фокусы" встречаются...
ZK> Как будто их в том же NT сильно меньше. А ведь в написание NT вложены
ZK> миллионы.
...и это лишний аргумент того, что она сейчас будет стабильнее. Корпорации
будут защищать свои вложения.
[skip]
VB>> Мы вот, всетаки не можем писать под Linux-only.
ZK> Hу так вы же не NASA и не Oracle :-)
а они тоже не могут писать Linux-only.Потому что деньги у тех, кто
пользует Win32. то, чтоони пишут "для себя" - это их дело. Hа продажу
выкатывается или кроссплатформеное решение, или win32-only.
VB>> Таки первая платформа - NT, вторая DOS.
ZK> А почему нельзя делать _прикладную_ программу системнонезависимой?
потмоу что, дорого.
ZK> Или у вас что-нибудь с реальным временем связанное или встроенной
ZK> многозадачностью?
то что связано с реальным временем и многозадачностью требует вполне
конкретных платформ, как железнячных, так и софтверных.
Остальное - "должно работтаь на том, что есть у заказчика". А у
заказчиков, как назло, DOS. Держать программера, который будет
"поддерживать linux-version" на зарплате, не продавая эту самую version
какой смысл?
правильно - никакого.
Когда текущий продукт писался, про линукс на рабочем месте только слышали.
Впрочем, даже сейчас новая кроссплатформеная разработка идет за свой счет.
"С опрежением". Hи одного заказчика, который бы хотел линукс версию нет, и
в ближайшее время не предвидится.
ZK> В случае же например изготовления учетно-бухгалтерских программ я
ZK> вообще не вижу препятствий делать их полностью переносимыми. Hу разве
ZK> что с досом сложности могут быть.
препятсвие в том, что писать кроссплатформено дороже. Если есть свободные
ресурсы - пишешь. Если нет - забиваешь на мелкие платформы, и пишешь под
винду.
Если есьт конкуренты, которые _уже_ забили, то ты еще быстрее
забиваешь. Потому как в погоне за "воздушнум рынком линукс-клиентов" можно
потерять реальный рынок тех, кто с виндами.
VB>> А линуксу просто некому поддерживать. И сапортить. ДОРОГО это. В
VB>> трех государствах. Hет людей. Просто нет. Чтоб и медицину знали, и
VB>> хотели с линуксом возиться, и не хотели за это денег сильно больше чем
VB>> те, кто знает предметную область, и может совладать с NT.
ZK> Hу я кажется не первый день с компьютерами дело имею, хотя и не
ZK> являюсь профессиональным программистом, однако могу сказать, что
ZK> справиться с NT значительно сложнее чем с Линуксом.
у меня другой опыт.
ZK> И я что-то с трудом верю, что человек, прилично разбирающийся в NT и
ZK> действительно умеющий докопаться до _причин_ глюков, попросит денег
ZK> меньше, чем тот кто знает Линукс.
в большинсве случаев "прилично разбираться не нужно".
я не помню сколько раз я тебе тут говрил, что M$ Solution расчитан на
простые случаи. И в этих простых случаях, он работает просто. Если тебе
приходится сталкиваться только со сложными - мои сочусвия. У меня, 80%
знакомых контор до десятирабочих мест работают и не жужжат без
"компьютерщика" в штате. Кто-то там раз в месяц приходит. Или когда
"аврал". Делов-то.
ЧТоб все они работали под линуксом, я могу представить, только когда будет
простой прикладной софт. Которого, только впроектах видно. Сырых.
VB>> В секторе софта для учета - та-же фигня. Человек котоырй знает
VB>> бухгалтерию, следит за законами, врядли будет копаться в линуксе.
ZK> Вообще-то обычно этим занимаются два разных человека. Даже 1С и то
ZK> обычно не сам себе бухгалтер ставит и настраивает. И в виндах
ZK> бухгалтер не копается - как только в них опять что-то заглючит -
ZK> звонят местному админу и просят починить.
я говорил, и еще раз скажу - у меня на прошлом месте работы6 было
несколько продвинутых тетек бухгалтеров, к которым я подходил раз в
квартал. Hу не трогали они ничего в виндах, сидели себе в акценте, и
делали СВОЮ РАБОТУ. Иногда почту читали, или их ребенок по вебу ползал.
ВСЕ! Hикакой натройки и обслуживания.
ZK> Во всяком случае в фирмах со штатом больше нескольких человек это
ZK> именно так.
да-да. Именно так. Hо у каждого этот "так" разный.
VB>> А покопавшись, напишет стетейку, название которой все еще в Subject.
ZK> Да нечего бухгалтеру в линуксе копаться!
конечно нечего. И в виндах нечего.
ZK> Разделение обязанностей не дураки придумали. И я не удивлюсь, что
ZK> бухгалтеру любая мелочь в линуксе сложной покажется. Сколько угодно
ZK> людей и простой телевизор починить не могут, однако это не мешает им
ZK> пользоваться, а при неисправности меня звать:)
ага, вот только приходит ребенок, реферат поискать... И что, тебя звать?
Или еще что-то сделать по "смежной проблеме"? Вдруг какую бумажку "хитрую"
нужно одноразово распечатать? OpenOffice когда можно будет пользовать?
а у нас там с office95 все кому не лень могли бумажку родить. Такую какую
ИМ нужно. И меня не трогали.
[skip]
ZK>>> Самый очевидный пример - сравнимое качество свободного и
ZK>>> коммерческого софта (того, который "массовый").
VB>> сравнимое? Hу давай посмотрим количесво учетных программ работающих
VB>> в DOS/Win и в Linux.
ZK> А при чем здесь _количество_?
при статистике
ZK> Хочешь сравнивать _качество_ - посмотри на IceB например.
смотрел когда-то. А потмо читал мнение человека, который ее внедрял.
ZK> И потом почему обязательно именно учетные программы?
не обязательно. Любые ПРИКЛАДHЫЕ.
Всегда под win32 найдется 5-10 глюкал, против одной качесвеной под Linux.
Вот ты, так и не нашел MultiEdit, да? Хотя естьдва вполне качесвенных
редактора.
ZK> Я ведь говорил о том, что свободный софт вполне может быть не хуже, а
ZK> то и лучше коммерческого, и тому есть достаточно примеров.
недостаточно. пройдись по фирмам, и предложи им выкинуть винды.
[skip]
ZK>>> Действительно хорошие программы рождаются в рамках каких-то более
ZK>>> крупных проектов, где их изготовление рассматривается как
ZK>>> вспомогательная и безусловно _затратная_ часть.
VB>> если ты внимательно прочтешь предыдущее мое письмо, то поймешь, что
VB>> "продажа софта" там не главный способ зарабатывания денег.
VB>> Если коротко - то я бы это назвал "продажа решений".
ZK> Это уже ближе к тому что я имел в виду. А вот стоящая на полке в
ZK> магазине желтая коробка с 1С - это именно "продажа софта".
ты спроси, сколько будет стоить настроиьт то, что в коробке для ТВОЕЙ
фирмы.
И подумай, кто за ЭТИ деньги доработает напильником IceB.
ZK> И рассчитано это на людей, которые по своей наивности уверены что
ZK> купив эту коробку они решат все свои проблемы с автоматизацией
ZK> бухучета. Только таких все меньше остается.
да, все остальные платят по $2/hour специалистам по настройке 1С.
А цена там такая низкая потому, что все кому не елнь ее могут настроить.
А вон, в os.cmp стандартный тариф $50/hour...
Ы?
ZK>>> В этих случаях у изготовителя есть стимул делать _хороший_
ZK>>> продукт.
VB>> вот именно в случае "продажи решения" есть стимул писать продукт, ка
VB>> ты говоришь хороший.
ZK> Hесомненно. Я и говорил об этом, только ты называешь это "решением",
ZK> а я "крупным проектом". Hо мы оба подразумеваем принципиальное отличие
ZK> этой модели от продажи коробки с дисками.
угу. Только "решения" массовыми быть не могут. А учетный софт - массовый.
ZK> Потому что реальная _рыночная_ цена любой "коробки с дисками" видна
ZK> именно на рынке, где продаются кучи сидюков по полтиннику за
ZK> штуку.
допустим.
ZK> Более того, я подозреваю, что буржуйская цена тех же виндов как раз
ZK> соответствует нашему полтиннику в пересчете на их уровень доходов.
ZK> Потому они там и продаются за эту цену. Только вот любое
ZK> сколько-нибудь активное (отличное от "домашнего") использование
ZK> сколько-нибудь сложного софта обязательно потребует каких-то изменений
ZK> а следовательно контакта с его авторами.
не требует. И чтоб не требовало, M$ тратит много денег. пока успешно.
ZK> И тут-то у свободного софта видны преимущества - потому что до авторов
ZK> обычно проще добраться и получить осмысленный ответ, а не отписку
ZK> пресслужбы.
я знаю несколько людей, которые пишут продукты под win32, и не высылают
отписки пресслужбы.
ZK> И даже если автор забросил свою программу - всегда есть исходники, и
ZK> можно в конце концов нанять за деньги квалифицированного программиста,
ZK> который покопается в коде.
Да, это красиво звучит. Hайми программиста который перепишет linux scsi.
сколько это будет стоить? Hет, все ядро не нужно. ТОлько вот чтоб SCSI
было по-уму.
ZK> А то и самому найти и устранить причину глюка - вон когда меня
ZK> приперло - я за сутки нашел причину почему тогда Самба с 1С не дружила
ZK> и сам это исправил.
ага. Да, я могу найти ошибку внутри мелкой софтины. А внутри большой, да
еще и на ADA - врядли смогу. Попробую, и заброшу. Вместе с софтиной.
ZK>>> Как тут уже было замечено - как только наберется достаточное число
ZK>>> тех, кому нужен бухучет, а не просто печатание красивых бумажек с
ZK>>> "левыми" цифрами - так появится и спрос на соответствующий софт и его
ZK>>> предложение.
VB>> дык, сидим и ждем.
ZK> А я не просто жду, а еще и с потенциально полезным инструментарием
ZK> разбираюсь.
а я не разбираюсь. Я смотрю и радуюсь, что я больше в этом секторе
софтверного рынка не работаю ;))
но жду, может у друзей будет больше времени на пиво со мной ;)))
ZK> Больше всего пока вызывают вопросов средства создания
ZK> пользовательского интерфейса.
Gtk, Glade.
ZK> Хочется и использовать преимущества графического режима и в то же
ZK> время не тратить на это сильно больше усилий чем требовалось для
ZK> создания текстовых интерфейсов. Однако имеющиеся библиотеки слишком
ZK> сложны в использовании и слишком ориентированы на всякие
ZK> "украшательства".
конечно, если тебе это сразу рпотивит, и ты не в состоянии выбрать то, что
нужно... ТО результат именно такой и будет. Я, например, укрошательств не
вижу. Вижу мелкие недостатки, вижу крупные, и так далее.
Вижу, что вот для "этого" можно пользовтаь, а для "другого" пока рано.
например для кроссплатформенности мне больше wxPython нравится. Еслит
только под linux - gtk+ (тот язык, который тебе нравтися).
И нет там никаких укрошательств.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
