|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 31 Mar 2002 01:22:04
To : Vladimir Bormotov
Subject : Re: записки тетки-бух галтера
--------------------------------------------------------------------------------
Mar 30 21:57 02, Vladimir Bormotov wrote to Zahar Kiselev:
ZK>> В том случае, о котором я упоминал и где уже не первый год сражаются
ZK>> с 1С - там вообще фактически написали свою систему оперативного учета
ZK>> на встроенном языке 1С.
VB> Молодцы!
ZK>> Я считаю что это глупость и надо было писать на любом нормальном
ZK>> языке.
VB> а я считаю, что им ПОФИГ было на чем писать.
Это значит ты просто не наблюдал за процессом написания.
А я наблюдал. Выглядит это весьма грустно. Программист пишет некоторый код,
глядя в описание этого "языка" 1С. Пытается запустить написанное - оно не
работает или работает совсем не так как написано. После десятка попыток
исправить одно или другое и возни с имеющимся там же "отладчиком" он зовет меня
и просит хоть чем-нибудь помочь. После часа совместных усилий выясняется
очередная "недокументированная особенность" или глюк или называй как хочешь.
В результате не меньше половины общего времени тратилось не на собственно
реализацию того, что было задумано, а на выявление и обход вот этих самых
"особенностей".
У меня имеются серьезные подозрения, что _ни_один_ нормальный язык
программирования не имеет такое количество глюков, чтобы программирование на нем
превращалось в _непрерывный_ поиск путей их обхода.
Вот поэтому я и смею утверждать, что HЕ ПОФИГ на чем писать.
ZK>> Кстати говоря - интерпретатор встроенного языка у 1С работает
ZK>> медленно, скорости выполнения кода во многих случаях
ZK>> недостаточно.
ZK>> Будет ли быстрее какой-нибудь из интерпретируемых языков, имеющихся
ZK>> по Линуксом?
VB> думаешь кому-то интеерсно это сравнивать? Людям интересно
VB> 1. скорость и прозрачность написания программ на конкретном
VB> скриптовом
VB> языке людьми, которые "не программисты" (как ты любишь твердить о
VB> себе), а специалисты в прикладной области.
VB> Интерпретаор дает несомненые плюсы на этапе разработки. Плюс,
VB> легкость реализации.
Может я какой-то "не такой", но я не ощущаю особых плюсов скриптовых языков
типа перла или tcl или виндового потомка бэйсика по сравнению хотябы с той же
адой или паскалем. Вот по сравнению с Си все это для "не программиста"
действительно проще.
ZK>> Ты видел сколько времени в том же 1С выполняется "сохранение
ZK>> конфигурации" после внесения изменений?
VB> не видел. Зачем оно мне? Как часто делается эта операция?
После каждого исправления исходника конфигурации. А так как в процессе обхода
глюков делать это приходится _десятки_ раз - то времени уходит прилично.
> Есть сколько нужно потратить ресурсов квалифицированого программера на то,
VB> чтоб ускорить эту операцию на 20%?
Hе эту операцию надо ускорять, а язык взять нормальный, и библиотеки к нему
нормальные, в которых есть все необходимые для "учетно-бухгалтерской" прикладной
области функции.
VB> Пойми, можно многое очень красиво сделать. Вопрос, нужно ли это
VB> делать
VB> сейчас, когда хочется кушать. Тебе, твоей семье, и тд. и тп.
Если все сводить к желанию кушать - то рекомендуется сменить профессию на
торговлю продуктами и выпивкой(желательно торговлю оптовую). Здесь это
значительно выгоднее, чем любое программирование на чем угодно.
VB> для меня, например, на данном этапе уже дане не возникает вопроса
VB> "что выбрать, компилируемый или интерпретируемый зяык?". В 90% случаев
VB> ответ "интепретируемый".
Вот я и хотел выяснить - почему?
Извини, но экономия времени на процессе компиляции за достойный аргумент
ну никак не катит - и потому что у разработчиков обычно стоят не самые слабые
машины и потому что в популярном на рынке продукте(1С) есть та самая операция
"сохранения конфигурации" и ее длительность не мешает оному продукту удерживать
свою популярность.
> Компилирование нужно тогда, когда "мало ресурсов компьютера". Hапример
VB> мало памяти, или дохлый процессор. И вся эта
VB> задача на этой хитрой железяке" стоит дорого, и цена продажи ее
VB> позволяет
VB> ОКУПИТЬ квалифицированого программера на C/C++/итд.
А почему как только говорится о компилируемых языках, ты сразу сворачиваешь в
сторону С/С++ ? Си хорошо подходит для написания ядра Линукса, но он совершенно
не подходит для написания бухгалтерских программ. Для бухгалтерии нужно что-то
алголоподобное(паскалеподобное) - как наиболее понятное для "непрограммистов",
обладающее свойством самодокументируемости исходника, имеющее возможно более
жесткий контроль ошибок и минимум неочевидных умолчаний. Я уже говорил, что
когда-то мне пришла в голову совершенно не очевидная мысль использовать Аду для
написания работающей модели складского учета. Как оказалось - язык подходит
просто идеально. В комплект еще нужна база данных, способная поддерживать
отношения вида "один-к-многим"(самый распространный их вид в учетных задачах),
чтобы небыло надобности делать их руками на таблицах дублируя столбцы. Такая
база есть и распространяется свободно(сейчас).В те времена ее еще небыло, я
использовал коммерческую базу такого типа. И еще нужна _простая_ в применении
библиотека, позволяющая рисовать на экране окна и меню. Повторяю - _простая_, а
не навороченная. Для текстового режима я такую знаю, она хотя и коммерческая, но
в исходниках доступна и они могут быть легко перенесены в Линукс. С графическим
режимом сложнее, но похоже ту же библиотеку можно запихать поверх xlib.
> Сколько время
VB> жизни
VB> приложения? Год-два-три?
Даже 1С - и тот живет уже заметно дольше. Минимум раза в два.
А буржуйские учетные программы типа ManMX(кажется так оно пишется) - так и
вообще больше десяти лет существуют.
> Сколько хочет хороший прогарммер умеющий
VB> писать на C++?
VB> и посчитать "а есть ли эконоимическая выгода от такого
VB> решения?".
VB> Если ты что-то там пишешь для себя - это твое личное дело.
Однако вот весь Линукс "для себя" написали.
Интересно - что бы сказали сторонники "экономической эффективности" если бы
им десять лет назад описали сегодняшнюю ситуацию с Линуксом? Уверен - никто
всерьез не воспринял бы.
VB> Предприятие, которое зарабатывает разработкой софта, в первую
VB> очередь хочет не закрыться через год (поржрав инвестиции).
По-моему модель "зарабатывания денег на производстве софта" уже сейчас
показывает свою неэффективность. Самый очевидный пример - сравнимое качество
свободного и коммерческого софта(того, который "массовый").
Мне кажется, что разработка качественного программного обеспечения и извлечение
быстрых доходов - вещи не совместимые. Действительно хорошие программы рождаются
в рамках каких-то более крупных проектов, где их изготовление рассматривается
как вспомогательная и безусловно _затратная_ часть. Да, часть затрат может быть
потом компенсирована продажей этого софта, но вся эта деятельность не является
самостоятельным бизнесом. В этих случаях у изготовителя есть стимул делать
_хороший_ продукт. Если же продукт делается исключительно на продажу - то делают
продукт _покупаемый_, при этом покупаемый чайниками, которых на данный момент
большинство. А уровень продаж к качеству имеет далеко не прямое отношение.
Hо повлиять на эту ситуацию может только время. Как тут уже было замечено - как
только наберется достаточное число тех, кому нужен бухучет, а не просто
печатание красивых бумажек с "левыми" цифрами - так появится и спрос на
соответствующий софт и его предложение.
Zahar(@spbdept.rbc.ru)
--- Msged/LNX 6.1.0
* Origin: undefined location (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
