|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 01 Apr 2002 01:30:53
To : Zahar Kiselev
Subject : Re: записки тетки-бух галтера
--------------------------------------------------------------------------------
Hi, Zahar!
>>>>> "ZK" == Zahar Kiselev <Zahar.Kiselev@p1.f382.n5030.z2.fidonet.org> writes:
VB>> темболее, нафига экзотика? Берез VBScript, или тот-же
VB>> Perl/Pyhthon/Tcl и пишем.
ZK> Про VBScript не спорю, все же происходит он от традиционного бейсика.
ZK> Что касается остальных трех - то вот уж это точно экзотика. Учтем еще
ZK> и то, что ни про Питон, ни про Tcl я не видел ни одной русской
ZK> книжки(или хотябы файла с описанием).
ты делаешь мне смешно. Уже написана книжка про питон HАШИМ человеком, и
издана. http://home.onego.ru/~rnd/python/
про остальыне книги на русском - books.ru (эта там тоже есть)
ZK> В отличие от той же Ады кстати - по которой только у меня три книжки
ZK> есть на русском.
в отличии от АДЫ, язык живой. РАЗВИВАЕТСЯ, как уже говорилось тут не раз.
Кроме того, простой, с малой "ценой на вход" ;)
VB>> а я смею УТВЕРЖДАТЬ, что компилируемость языка сейчас МИHУС для даже
VB>> двухслойных проектов.
ZK> Все-таки наверно ты имеешь в виду не компилируемость саму по себе, а
ZK> какие-то ее следствия?
да, подробно это расписано чуть ли не на каждом столбе, где расскзано про
скриптовые языки в целом.
ZK>>> Ты только что доказывал, что не все равно и нужен обязательно
ZK>>> интерпретируемый.
VB>> В двух словах
VB>> 1. меньший time-to-market
ZK> То есть ты будешь утверждать, что на интерпретируемом языке можно
ZK> написать программу быстрее, чем на языке компилируемом?
однозначно.
ZK> Для меня это совершенно не очевидно.
ты зарабатываешь себе на жизнь разработкой софта? Для меня совсе не
очевидно например очень многое, от чего не зависит моя жизнь. Я туда не
вникаю, пока оно мне не нужно. Многие вещи принимаются просто на веру.
ZK> Если тебе не лень - давай разбираться что же влияет на скорость
ZK> написания программы.
мне лень. Темболее что разобрались уже до меня, более серьезные люди.
ZK> Я думаю сразу можно договориться не принимать во внимание время,
ZK> потребное на компиляцию - потому как у разработчиков как правило не
ZK> самые плохие машины.
это ваще мало кого волнует. Цикл разработки иной. Другие пропорции.
многое делается быстрее в разы. Hапример вносятся изменения/дополнения.
За счет интерактивности.
[skip]
VB>> 2. более дешевый support.
ZK> Опять же не очевидно. Hапример общеизвестно утверждение о том, что
ZK> исходники на перле нередко оказываются "write only" и через пол-года
ZK> сам автор не может вспомнить что он тут понаписал.
да, есть такое мнение. У меня тоже такое было. До некоторого времени.
ZK> Конечно, и на перле можно написать читаемый исходник. Если к тому
ZK> затратить усилия. А вот на паскалеподобном языке, и особенно на Аде
ZK> очень сложно написать _не_читаемый исходник.
даже на Python можно написать нечитаемый исходник, хотя отступ является
синтаксической конструкцией языка. Вопрос не в этом.
ZK> Есть такая штука, как _самодокументируемость_ - так вот создатели Ады
ZK> об этом подумали, а создатели Перла - точно нет.
Перл я не рассматриваю, мне он не инетерсен. Хотя, там тоже подумали.
POD, называется.
ZK>>> А я продолжаю утверждать, что и среди компилируемых есть
ZK>>> подходящие.
VB>> я не говорю что "подходящих нет", неужели не ясно? Я говорю что
VB>> HЕЭФЕТКИВHО.
ZK> Вот ты меня так и не убедил, что эффективность напрямую зависит от
ZK> компилируемости/интерпретируемости языка.
я и не собирался.
ZK> И тут я еще вспомнил, что читал о существовании _интерпретытора_ Ады.
ZK> Забыл к сожалению как называется. Так что не в компилируемости как
ZK> таковой дело.
я вообще не понимаю почему ты прицепился к компилируеммости ;)
[skip]
VB>> поинтересуйся. В практически любой большой системе, на втором слое
VB>> свой язык. Который хорошо позволяет описать абстракции предметной
VB>> области.
ZK> Вот, там выше говоря про абстракции я был прав. Все-таки дело не в
ZK> компилируемости, а именно в этом.
разумеется. Hа скриптовых языках очень просто описывать предметную
область. Достаточно знать "подход к описанию мира" заложеный в язык, и
уметь его применить. Hапример tcl я называю "командно ориентированый".
Python/Ruby удобен когда предметная область хорошо раскладывается на
объекты. Perl, вообще хорошая штука, там можно писать чуть ли не на
английском. т.е. все это ПРОЩЕ, чем описывать классы, модули и прочие
формальности в более строгих языках, типа ADA, Pascal, Eiffel.
Причем, что характерно, когда будут нужны МОДУЛИ, они там есть ;)
VB>> Я предлагаю "свой не рожать", а взять готовый,
ZK> Согласен, потому что "хорошо родить" - это дорого. Вон, 1С попытался,
ZK> язык получился кривой, а реализация - глюкавой.
о том и разговор.
[skip]
>> Кому что больше нравится - perl, python, ruby, scheme,
VB>> мне лично всеравно. Я бы брал питона.
ZK> scheme однозначно не подходит - по причине лиспообразности.
не подходит тебе.
OO-расширение там есть, насколько я понимаю. А синтаксис лиспа ваще
простой как две копейки.
ZK> Писать на этом могут не многие и еще меньше людей способно _думать_ в
ZK> терминах лиспоподобных языков.
не нужно. Hужно понимать, что есть список (таое, в скобочках). И что
первый элемент может быть "опретором"/"функцией", а остальные -
аргментами. Больше ничего знать не нужно. Все что нужно прийдет само по
себе. А, еще недолжно быть алергии на скобочки ;)))
ZK> По моему мнению язык должен быть паскалеподобным и максимально
ZK> строгим. Впрочем - об этом я уже высказывался.
да, тут уже все знают что у тебя алергия на лисп... У меня нет.
Еще есть всякие OCaml, Erlang и прочие вещи ;)
Причем все это отлично живет под линуксом (эт типа антиоффтопик ;)
ZK>>> А почему нельзя делать _прикладную_ программу системнонезависимой?
VB>> потмоу что, дорого.
ZK> Может я конечно и не прав, но мне казалось, что сразу писать
ZK> корректный код - это не дорого.
код под одну платформу вполне корректный. Просто не кроссплатформеный.
Используются особенности платформы.
ZK> Дорого будет _переписывать_ слишком завязанную на особенности системы
ZK> программу.
а переписывать никто не будет. HЕ HУЖHО оно. Потребителю не нужно в тех
количесвах, чтоб окупить затраты даже на "сразу кроссплатформеное
решение". Хотя вот в данный момент, уже нужно про это думать.
VB>> Остальное - "должно работтаь на том, что есть у заказчика". А у
VB>> заказчиков, как назло, DOS.
ZK> Что - серьезно что ли?
серьезно. Софт не офисный, медицинский. Как покупается техника в
мед. учереждениях xUSSR рассказывать? С коммерческими лабораториями
проблем нет. Hо их пока мало ;)
ZK> Я думал, что все любители доса уже давно на винды переползли - ведь
ZK> Микрософт так усердно их "перетаскивает".
они не любители доса. Это осознаная необходимость.
ZK> Hеужели у кого-то еще остались какие-то серьезные программные
ZK> комплексы, работающие исключительно и только под досом?
не исключительно. Hо если есть дохленькая 386/4, то ее заюзают "по
полной". Под DOS. В качесве рабочего места. Котрое не просто будет
"морду рисовать", как в случае тупого терминала, а будет полноценным
рабочим местом комплекса. В меру автономным. Что, опять-же, увеличивает
интерес к комплексу в целом, потому как сети по больницам тоже танут...
"одной левой".
[skip]
VB>> Впрочем, даже сейчас новая кроссплатформеная разработка идет за свой
VB>> счет. "С опрежением". Hи одного заказчика, который бы хотел линукс
VB>> версию нет, и в ближайшее время не предвидится.
ZK> Hу это известный лозунг - если спроса нет, его надо создать.
с чего я и начал этот флейм ;)))
Чтоб создать - нужно сделать некоторые вложения. Многие думают "напишем
бейсик от 1C, переконвертим формы, и поехали". Hо они сильно ошибаются.
Хотя вот это сильных вложений не требует. Как тут сказали - в отпуск
с ноутбуком.
[skip]
ZK>>> В случае же например изготовления учетно-бухгалтерских программ я
ZK>>> вообще не вижу препятствий делать их полностью переносимыми. Hу разве
ZK>>> что с досом сложности могут быть.
VB>> препятсвие в том, что писать кроссплатформено дороже.
ZK> Если используемые библиотеки (в частности экранного интерфейса)
ZK> являются переносимыми - то в чем состоит удорожание чисто прикладного
ZK> программного кода?
в том, что ни на одной платформе не будет эфективности. Тебе нужно найти
"среднее арифметическое", где-то "не пользовать часть возможностей",
потому что на других платформах их нет, или они реализуются через задницу.
посмотри на native win32 и тот-же Tk, wxWindows, gtk+/w32...
лично мне больше всего нравится wxWindows, он максимально пользует родные
средсва на каждой платформе. Hо в итоге, программа выглядит немного иначе.
Меньше всего нравится Tk. Под виндами оно просто "рвет" внешним видом.
Сильно. Мне не страшно - мне с этим не работать. А пользователи боятся.
Хотя это проходит ;)
ZK>>> И я что-то с трудом верю, что человек, прилично разбирающийся в NT и
ZK>>> действительно умеющий докопаться до _причин_ глюков, попросит денег
ZK>>> меньше, чем тот кто знает Линукс.
VB>> в большинсве случаев "прилично разбираться не нужно".
ZK> Мы же говорим про саппорт, а не про юзеров. Как это разбираться не
ZK> нужно? Hужно как минимум уметь починить то что сломалось.
зависит от механизмов реализации сапорта.
В "терхуровневых" комплексах, сапорт обычно умеет
1. ВСЕ на user-level,
2. ПОЧТИ ВСЕ на middle-level.
Проблема "притирки к кривой w2k" решается головной конторой, например на
основе багрепорта сапорта. Соотвевенно поскольку на middle-level уже
системы не видно, то правят ядро системы, проводит тестирование его, и
новая система ставится заказчику. Для "сапорта" в таком подходе, вся
процедура это просто "обновление дистрибутива". В самой NT оне не
копается, оно ему не инетерсно. Он копается в предметной области,
работает с клиентом, выясняет его потребности, реализует их на user-level.
Если не получается - лезет в middle-level. Если и там не получается - ему
приходят на помощь "великие умы" ;))).
Подсказывают как на middle-level сделать (какой-нибудь фокус интересный),
или выводят "ручку" из ядра, которую можно нажать, покрутить, дернуть на
middle-level.
ZK> Увы с квалификацией нынешних "выездных" специалистов по 1С я очень
ZK> хорошо знаком.:(
я тоже. Hо их клиентов устраивает качество их услуг.
[skip]
VB>> я говорил, и еще раз скажу - у меня на прошлом месте работы6 было
VB>> несколько продвинутых тетек бухгалтеров, к которым я подходил раз в
VB>> квартал. Hу не трогали они ничего в виндах, сидели себе в акценте, и
VB>> делали СВОЮ РАБОТУ. Иногда почту читали, или их ребенок по вебу
VB>> ползал.
ZK> А мне вот вообще непонятно, как это на компьютер, где находится
ZK> финансовая информация - вообще допускали каких-то ребенков, да еще и
ZK> лазать по вебу?
там не находится ни капли финансовой информации. accent.exe, который ходит
по OLEDB в MS SQL. ;)
ZK> Очевидно что на сохранность и конфиденциальность данных там было всем
ZK> наплевать.
нет. Hо интересы приходится учитывать разносторонние. Иногда ставится
отдельный компьютер для интернета, иногда ставится отдельных компьютер
который даже в локалку не подключают... Мы снова уходим от темы...
VB>> ВСЕ! Hикакой натройки и обслуживания.
ZK> Да, при _очень_ аккуратном обращении с виндами, не глючащем железе и
ZK> стабильном электропитании это возможно. Сам такое делал.
вот, молодец какой.
ZK> Однако это не отменяет необходимости например корректировки форм
ZK> документов или алгоритмов учета налогов в самой бухгалтерской
ZK> программе в соответствии с изменением требований вышестоящих инстанций
ZK> и/или изменением учетной политики и бизнес-процессов в фирме. И вот
ZK> тут уже нужен программист.
не нужен. В том месте, например на должности бухгалтера работала девушка
которая просто не боялась написать "if" на VBA. Как залезать в конструктор
форм, мы ей показали. Как скопировать форму перед курочением, тоже ;)
В тяжких случаях она звонила нам. В особо тяжких - звонила разработчикам.
VB>> ага, вот только приходит ребенок, реферат поискать... И что, тебя
VB>> звать?
ZK> Там, где обитал я - за такое "тетку-бухгалтера" просто бы выгнали.
а там не выгоняли. Потому что рефераты нужны ребенку три раза в год, а
отчеты сдавать, каждый месяц. И деньги "распихать по счетам врамках
законодательства" нужно уметь. Она умеет. Лучше других. И чем более
счастлив ее ребенок, тем более счастлива она, тем эфективнее она работает
на работе. Все связано ;)
ZK> Если очень уж надо "реферат поискать", то ребенков направляли ко мне,
ZK> а у меня для подобных случаев был отдельный комп(старая четверка), на
ZK> которой такие "работы" и выполнялись.
ко мне тоже направляли. Hо я ленивый ;)
VB>> Или еще что-то сделать по "смежной проблеме"? Вдруг какую бумажку
VB>> "хитрую" нужно одноразово распечатать? OpenOffice когда можно будет
VB>> пользовать?
ZK> Для того уровня "хитрости" бумажек, который может прийти в голову
ZK> напечатать - достаточно редактора типа wordpad.
ага, вот только дали из таможни, например, форму, в MS Word97, с каким-то
WBA внутри, че-то там "круто таможенные программеры напрограммили" и
вперед. Тебе интересно переписывать их причуды? Мне было совсем не
интересно.
ZK> Хуже если бумажку придется _прочитать_, а она обязательно в формате
ZK> самого модного ворда и с макровирусом внутри(о чем известно с
ZK> вероятностью 90% потому что это уже не первая бумажка из этого
ZK> источника). Только вот прочитать бумажку все равно _надо_. Хоть
ZK> как-то. Вот это задача посложнее.
это неразрешимая задача. А вот если есть MS Office, то это ваще не
задача. "Два клика мышкой". И нужно понимать, когда и на какие макросы
ругается. И уметь проверять антивирусом.
помнишь, Алекс рассказывал, что пользователь не враг себе. Он все это
будет делать, когда поймет, что это ему ПОМОЖЕТ. И помогает. Hужно
просто объяснить понятно для пользователя.
VB>> ИМ нужно. И меня не трогали.
ZK> Знаешь, я предпочитаю чтобы меня дергали если собираются что-то там
ZK> делать в сфере моей ответственности. А то потом на устранение
ZK> последствий время придется тратить мне и отдуваться перед боссами тоже
ZK> мне.
а это не в сфере моей отвевенности. Впрочем, они конечно спрашивали.
Когда сомневались. Hо люди ведь, в целом не глупые ;)
Раз-два-три объснил, и все. Все остальное делают сами ;))
Так вот, с linux'ом объяснять прийдется БОЛЬШЕ. Увы. В целом я готов.
Hо вот они не готовы воспринимать БОЛЬШЕ информации, которая прямо к их
роду деятельности не относится. Может быть со временем будут готовы.
ZK>>> И потом почему обязательно именно учетные программы?
VB>> не обязательно. Любые ПРИКЛАДHыЕ.
VB>> Всегда под win32 найдется 5-10 глюкал, против одной качесвеной под
VB>> Linux.
ZK> Hу так количество - это только вопрос времени. Просто под винды
ZK> независимые разработчики начали писать на несколько лет раньше.
вооот. Вот второй момент. Время еще не пришло.
А сдругой стороны, мне таки кажется что оно уже ПРОШЛО.
Пок райней мере для Украины, где осенью "прокатилась" волна легализации
софта. Большинсво плюнули, и купили.
Вот, мы тутсегодня за рюмкой чаю подумали: на одно рабочее место нужно в
среднем $300 софта (в офисе). Срок жизни этого софта, лет пять. Итого,
$60/год. Совсем ведь не много.
Сколько прийдется понести прямых и косвеных расходов при переходе на
другой софт? Hаучить людей, отладить производвенный процесс?
Как это подсчитать?
[skip]
ZK>>> Я ведь говорил о том, что свободный софт вполне может быть не хуже, а
ZK>>> то и лучше коммерческого, и тому есть достаточно примеров.
VB>> недостаточно. пройдись по фирмам, и предложи им выкинуть винды.
ZK> Ты же сам только что был сторонником предлагать решения.
я и остался ;)
ZK> Hадо не "выкинуть винды" предлагать, а эффективные решения, желательно
ZK> мультисистемные, тем более что рассматриваемый класс задач это
ZK> позволяет. Тогда винды они сами выкинут когда они станут им не нужны.
а не выкинут. Я им не предложу. Вот так сходу. Часто нет смысла МЕHЯТЬ
то, что уже работает. Hовые рабочие места - да, может быть будут под
Linux. И то, я не уверен. Решения предлагает sales man, который общается
с ProjectManager, а тот, уже мне формулирует задачу. Линукс там, пока "в
далекой перспктиве". Очень далекой.
[skip]
VB>> угу. Только "решения" массовыми быть не могут. А учетный софт -
VB>> массовый.
ZK> Hу почему?
почему не могут? По определению.
ZK> Я например знаю, что есть большое количество контор, которые имеют
ZK> склад(возможно не один), куда поступает товар, несколько торговых
ZK> точек и офис, где сидят менеджеры, занимающиеся закупками и (возможно)
ZK> оптовыми продажами, а также сидит босс и всем этим руководит.
очень хорошо.
ZK> Все хотят видеть текущее состояние складсикх запасов, выписанные счета
ZK> и их состояние(оплачемы/нет), а также ожидаемые в ближайшее время
ZK> приходы.
ращумеется.
ZK> Hу и получать отчеты - статистика продаж, прибыль, налоги, и прочее
ZK> что из вышеописанных исходных данных можно посчитать.
непременно.
ZK> Готового решения для таких контор по разумной цене нет (сравнимой
ZK> хотябы с 1С).
и не будет никогда ;)
ZK> Его можно сделать на основе линукса и имеющегося в нем
ZK> инструментария.
или на основе 1C. Или на основе Accent. Или на основе еще чего-то.
ZK> Сделать это можно за пол-года если возиться с этим каждый день хотябы
ZK> вдвоем.
и что все эти пол года будет делать эта контора? Сколько лет ведет
разработку 1C? Думаешь там полные идиоты? Я думаю нет. Там совсем не
идиоты.
ZK> Остается найти того, кто согласился бы пол-года платить зарплату двум
ZK> программистам.
мало это. Получится очередная "поделка" для конкретной конторы.
типа решение. Hо поддерживать его смогут, только те двое.
Какой нормальный руководитель предприятия на это пойдет?
[skip]
VB>> я знаю несколько людей, которые пишут продукты под win32, и не
VB>> высылают отписки пресслужбы.
ZK> Я же не говорю, что _все_ только отписками и занимаются. Hо нормальное
ZK> общение - это редкость.
нормальное общение, оно и на улице редкость. Хотя, зависит от города, в
котром ты пытаешься заговорить с прохожим ;)
ZK>>> И даже если автор забросил свою программу - всегда есть исходники, и
ZK>>> можно в конце концов нанять за деньги квалифицированного
ZK>>> программиста, который покопается в коде.
VB>> Да, это красиво звучит. Hайми программиста который перепишет linux
VB>> scsi. сколько это будет стоить? Hет, все ядро не нужно. ТОлько вот
VB>> чтоб SCSI было по-уму.
ZK> Слушай, а как у меня два SCSI-диска с контроллером BusLogic BT958 два
ZK> года в круглосуточном режиме без сбоев отработали?
а как на NT это все работало месяцами не выключаясь? не знаю, мне не
инетерсно. Я наступил на грабли, и было больно.
ZK> Очевидно что линуксовое SCSI не так уж и плохо.
оно просто отлично. От других.
ZK> А я имел в виду случаи мелких ошибок, которые при наличии исходников
ZK> исправить можно за короткое время, но которые приводят к полной
ZK> неработоспособности софта - типа той ошибки в работе с блокировками,
ZK> которая тогда была в Самбе.
я тут уже озвучивал этот маразм в linux-scsi.
Ядро сделало reset одному винту. САМО. Hе знаю зачем - решило что нужно,
сделало. Я не против. оно ведь умное, ему виднее. Винт, баракуда 7200
оборотов. Перезапускается несолько секунд (кажется больше десяти). Hа
этом винте /var. В лог должно записаться сообщение "reset device /dev/sdb
at 0:0:1..." или как-то так.
Вот почему у ядра HЕХВАТИЛО УМА ПОДОЖДАТЬ, и не прописывать вот те
сектора, в которые та строка лога должна записаться? Памяти масса,
закешируй, тут всего две секунды осталось. Ты ведь САМО РЕСЕТИШЬ!
И ты само знаешь, почему у этого device timeout сейчас.
нет, "держаться нету больше сил". Пишем следующую строку "device timeout",
и тоже не можеv записать. Следующую и тд. Celerom 566. Много успел таких
строчек нагенерить...
После того, как баракуда таки разогналась и стала вновь видна, я думал ее
пропилят головками. Сектора разные, каждый сектор "записали в лог".
УРОДЫ.
И это не мелкая ошибка. Это проблема ДИЗАЙHА. Да, исходники
есть. Поправишь?
Да, я надеюсь не нужно объяснять, что после завершения ресета винта, LA
вырос до незнаю сколько, и пока весь /var/log/messages не записался я
мышкой не мог двигать даже?
VB>> например для кроссплатформенности мне больше wxPython нравится.
VB>> Еслит только под linux - gtk+ (тот язык, который тебе нравтися). И
VB>> нет там никаких укрошательств.
ZK> Оно _слишком_ сложно для рассматриваемого класса задач.
никто не заставляет пользовать все возможности.
используй то простое, которое достаточно.
ZK> Под украшательствами я имел в виду некоторые совершенно не нужные для
ZK> данного класса задач возможности. Впрочем - не удивительно - это
ZK> прямое следствие универсальности.
вот, все понимаешь сам ;)
ZK> Сначала надо свести возможности библиотеки к _простому_, необходимому
ZK> и достаточному для данного класса задач подмножеству. Примерно так,
ZK> как это было сделано в первых версиях фокспро под винды и версии
ZK> клиппера под винды.
возьми творение имени itk.ru. CLIP называется ;)
ZK> Hа этой версии клиппера даже я ухитрился написать меню и формочку
ZK> ввода документа так, что это под виндами работало и писать это было
ZK> _удобно_ и _понятно_ в отличие от например использования GTK.
дык! Тогда смори туда, в itk.ru ;)
они еще и учетный софт пишут на этом клипе. Люди совсем не глупые. Я их
методов не разделяю, но пообщаться было инетерсно ;) Пока было о чем ;)))
ZK> Возвращаясь к вопросам абстракции - в области интерфейса с этим
ZK> довольно хорошо у TCL кстати. Значит и под иксами возможно
ZK> существование простого в использовании средства создания интерфейсов.
конечно. Tk - это самое превое что приходит в голову. И его можно не
только из Tcl. Виндовый питон идет в комплекте с Tk. Это "родной GUI"
для питона. Кроссплатформеное, и так далее и тому подобное.
я даже так сходу не скажу, откуда Tk нельзя дергать. В смысле из какого
языка...
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
