Здравствуйте, AndrewVK, Вы писали:

S>>Вот, о профессиональном уровне программистов я и говорил. Нечего на язык пенять, коли руки кривы.
AVK>Батенька, программисты есть именно такие какие они есть.

Честно, Andrew, не все программисты криворуки. Далеко не все.

AVK>Если для разработки системы нужна команда состоящая целиком из очень квалифицированных профессионалов, то стоимость такой системы возрастет в разы, вероятность успешного завершения снизиться и вобще непонятно откуда брать такую команду.

Интересно, а что если она уже есть?

AVK>Если с языком способны работать только очень дорогие специалисты, то это проблема именно языка.

А не находишь, что дороговизна оправдывается потребительскими качествами продукта? Тихо, тихо, я знаю, что нередко это повышение оказывается потенциальным, но всё-таки?

[offtopic on]
Знаешь, что забавно: где-то год или около того назад я как раз говорил о снижении стоимости работы программиста при переходе на более простой и эффективный [ нужное вписать ]. Хех, похоже, что я был прав. Притом огорчает, что это снижение есть следствие объективно меньшей добавленной им стоимости. И ещё забавно то, с каким упорством это самое снижение добавленной стоимости отстаивается, в частности, тобой (не сочти за личный наезд, плиз). Или я чего-то не понимаю? Или просто "одеяло" этой самой добавленной стоимости перетаскивается со специалистов на менеджеров, а специалисты заменяются просто "вменяемыми и хорошими людьми"? Я несколько утрирую, но, ИМХО, очень похоже на истину и если так, то that's a largest trouble в недалёком будущем.
[offtopic off]

AVK>>>Да оне и без сборщиков мусора ленятся следить за памятью.
S>>Во всяком случае в плюсы не ограничивают возможности программиста в этом направлении.
AVK>Ну да, вот только GC там реализовать нормальный так и не удалось.

Мда. Спецам он не нужен (почти), а для ммм... их противоположностей и язык BAT-файлов — магия.

AVK>>>Зачем говорить о каких то гипотетическизх ситуациях, если скорость разработки была и будет одним из самых важных факторов?
S>>Ну далеко не всегда.
AVK>Так практически всегда.

У всех свои ситуации. ИМХО, не стоит здесь обобщать.

Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>Батенька, программисты есть именно такие какие они есть.

ГВ>Честно, Andrew, не все программисты криворуки. Далеко не все.

Но к сожалению значительная их часть.

ГВ>Интересно, а что если она уже есть?

Я такого еще не видел. Во всех командах которые видел всегда есть часть менее профессиональных программеров, которые занимаются менее сложной работой.

AVK>>Если с языком способны работать только очень дорогие специалисты, то это проблема именно языка.

ГВ>А не находишь, что дороговизна оправдывается потребительскими качествами продукта?

Не нахожу. В массе своей потребительские качества проектов на нативных компиляторах хуже из-за большего количества багов, особенно приводящих к краху программы.

ГВ>Знаешь, что забавно: где-то год или около того назад я как раз говорил о снижении стоимости работы программиста при переходе на более простой и эффективный [ нужное вписать ]. Хех, похоже, что я был прав.

Да это собственно не было новостью даже 10 лет назад, иначе чем оправдано существование скриптовых примитивныхх языков?

ГВ> Притом огорчает, что это снижение есть следствие объективно меньшей добавленной им стоимости.

Ну если считать за добавленную стоимость количество ручного труда то да. А если полезный функционал то нет.

AVK>>Ну да, вот только GC там реализовать нормальный так и не удалось.

ГВ>Мда. Спецам он не нужен (почти),

Ну да, а я наверное не спец, поскольку мне он нужен.

S>>>Ну далеко не всегда.
AVK>>Так практически всегда.

ГВ>У всех свои ситуации. ИМХО, не стоит здесь обобщать.

Хорошо, приведи пример когда при разработке классической ERP сроки внедрения не играли важной роли.

Здравствуйте, AndrewVK, Вы писали:

ГВ>>Интересно, а что если она уже есть?
AVK>Я такого еще не видел. Во всех командах которые видел всегда есть часть менее профессиональных программеров, которые занимаются менее сложной работой.



AVK>>>Если с языком способны работать только очень дорогие специалисты, то это проблема именно языка.
ГВ>>А не находишь, что дороговизна оправдывается потребительскими качествами продукта?
AVK>Не нахожу. В массе своей потребительские качества проектов на нативных компиляторах хуже из-за большего количества багов, особенно приводящих к краху программы.

Ну, я думаю, что дело здесь ещё и в том, что в массе своей проекты написаны "массовыми" программистами, которые, как ты уже заметил — криворуки.

ГВ>> Притом огорчает, что это снижение есть следствие объективно меньшей добавленной им стоимости.
AVK>Ну если считать за добавленную стоимость количество ручного труда то да. А если полезный функционал то нет.

Мне бы твою уверенность...

AVK>>>Ну да, вот только GC там реализовать нормальный так и не удалось.
ГВ>>Мда. Спецам он не нужен (почти),
AVK>Ну да, а я наверное не спец, поскольку мне он нужен.

Это мне не известно. Блин, прекрати наконец сводить беседу к личным наездам.

S>>>>Ну далеко не всегда.
AVK>>>Так практически всегда.
ГВ>>У всех свои ситуации. ИМХО, не стоит здесь обобщать.
AVK>Хорошо, приведи пример когда при разработке классической ERP сроки внедрения не играли важной роли.

Сроки играют важную роль до принятия решения о выборе как критерий сравнения а после того как решение принято (скажем, в пользу разработки), то они просто не должны срываться. Если пользователя заявленные сроки устраивают, то, ИМХО, можно хоть свою ОС написать, если есть желание.

А кроме того, сами по себе сроки можно несколько двигать, если разработкой/внедрением занимается, например, IT-отдел. Ну это я отчасти по своему опыту, который вполне вероятно, не может быть обобщён.

Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>Не нахожу. В массе своей потребительские качества проектов на нативных компиляторах хуже из-за большего количества багов, особенно приводящих к краху программы.

ГВ>Ну, я думаю, что дело здесь ещё и в том, что в массе своей проекты написаны "массовыми" программистами, которые, как ты уже заметил — криворуки.

Но что же получается — программисты на той же джаве в массе своей менее криворуки? Как еще можно объяснить к примеру тот факт что качество джавовских библиотек в среднем заметно выше тех же Дельфовых компонент или плюсовых либ?

AVK>>Ну да, а я наверное не спец, поскольку мне он нужен.

ГВ>Это мне не известно. Блин, прекрати наконец сводить беседу к личным наездам.

Ну а как можно на такой аргумент отвечать? Я все таки считаю себя специалистом и тем не менее пользоваться GC мне удобнее, и не потому что я без него лики пложу, а потому что во многих случаях это позволяет писать более красивые и простые алгоритмы. Я могу выделить кусок памяти внутри какой то функции и не заботиться больше о том кому этот кусок грохать, даже если его использует кто то из другого процесса.

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Не нахожу. В массе своей потребительские качества проектов на нативных компиляторах хуже из-за большего количества багов, особенно приводящих к краху программы.

ГВ>>Ну, я думаю, что дело здесь ещё и в том, что в массе своей проекты написаны "массовыми" программистами, которые, как ты уже заметил — криворуки.

AVK>Но что же получается — программисты на той же джаве в массе своей менее криворуки? Как еще можно объяснить к примеру тот факт что качество джавовских библиотек в среднем заметно выше тех же Дельфовых компонент или плюсовых либ?

Ну так тем же самым — массовостью, "массой", которая... stl, например, очень неплохая библиотека. А про Java где-то бегало исследование из серии "Java vs C++", так там пришли к выводу, что Java обеспечивает меньший разброс качества, чем C++, т.е., у неё "нижняя планка" выше, чем у C++, но и "верхняя" — ниже. Сейчас быстро не найду, но если будешь настаивать, то раскопаю вечером.

AVK>Я все таки считаю себя специалистом и тем не менее пользоваться GC мне удобнее, и не потому что я без него лики пложу, а потому что во многих случаях это позволяет писать более красивые и простые алгоритмы. Я могу выделить кусок памяти внутри какой то функции и не заботиться больше о том кому этот кусок грохать, даже если его использует кто то из другого процесса.

Ну, хозяин — барин.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ну так тем же самым — массовостью, "массой", которая... stl, например, очень неплохая библиотека. А про Java где-то бегало исследование из серии "Java vs C++", так там пришли к выводу, что Java обеспечивает меньший разброс качества, чем C++, т.е., у неё "нижняя планка" выше, чем у C++, но и "верхняя" — ниже. Сейчас быстро не найду, но если будешь настаивать, то раскопаю вечером.



Что-то вроде этого?

But programming in VB is like riding a kiddy bike, while programming in C++ is like driving a Formula 1 racing car — be prepared for accidents.

(с) Frequently Asked Questions (aka the MFC FAQ) by Scot Wingo

Геннадий, если не затруднит, не мог бы ты дать ссылку на эту статейку/исследование — было бы очень занятно почитать.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Мда. Спецам он не нужен (почти), а для ммм... их противоположностей и язык BAT-файлов — магия.

"В C++ нужно добавить необязательный сборщик мусора." Б. Страуструп "Дизайн и эволюция С++". Я не думаю что Страус стал бы так писать о средстве, которое не нужно (почти) пользователям языка.

Здравствуйте, alexm1202, Вы писали:

A>"В C++ нужно добавить необязательный сборщик мусора." Б. Страуструп "Дизайн и эволюция С++". Я не думаю что Страус стал бы так писать о средстве, которое не нужно (почти) пользователям языка.

Ключ — "необязательный".

DAS> Да, а такие компании как РосТлеком, Ленсвязь, Toyota, Энергомаш, Перекресток, Исток, Волгоградский Аллюминий, MTV, Marvel, Osko, Алтайагропромснаб, Гипермаркет О"Кей, Группа компаний DIXIS, ДелтаСпорт, Останкинский молочный комбинат, Первоуральский новотрубный завод, РУССО, Ригла, Техносила, Тинькофф — это я говорю про тех людей, которые выбрали Axapt'у.

Раз уж зашла речь про Аксапту. У меня есть знакомый, который работает внедренцем Аксапты. По его словам, процент успешных внедрений крайне низок. То есть народ это покупает, тратит деньги на внедрение, но реально не работает.
Не знаю, насколько это соответствует истине — за что купил, за то и продаю.
Прокомментируйте, пожалуйста.

Здравствуйте, Roman Avramov, Вы писали:

RA>Раз уж зашла речь про Аксапту. У меня есть знакомый, который работает внедренцем Аксапты. По его словам, процент успешных внедрений крайне низок.

Смотря что понимать под успешным внедрением. Внедрении ERP, как и ремонт — процес бесконечный. Он никогда не заканчивается, он лишь на время приостанавливается .
Предприятие могло не внедрить все запланированные модули, но даже то, что внедрено может поднять уровень управления на совершенно иной уровень. Предприятие может гордо заявлять, что оно внедрило ERP, но при этом это может оказаться все лишь маркетинговой уловкой.
Процент внедрения не высок. Но как правило это связано с тем,что часто внедрением занимаются те, кто не умеет это делать. Дальше эту тему разивать я не буду...
Однозначно могу сказать, что процент внедрения Axapta выше, чем например SAP, и даже я думаю выше, чем у самописных систем. Но ниже чем у 1С . Чем сложнее систему — тем больше рисков, а следовательно выше шанс ее не внедрить.

Здравствуйте, Геннадий Васильев, Вы писали:

A>>"В C++ нужно добавить необязательный сборщик мусора." Б. Страуструп "Дизайн и эволюция С++". Я не думаю что Страус стал бы так писать о средстве, которое не нужно (почти) пользователям языка.

ГВ>Ключ — "необязательный".

Так в C++ много необязательных фич. Однако каждая из них была добавлена, исходя из тех соображений, что она существенно облегчит жизнь разработчикам в том или ином классе задач (не обязательно всем, кому-то например RTTI не нужен, а большинство прекрасно обходятся без МН). И, похоже, Страуструп считает что GC тоже облегчил бы жизнь достаточно большому числу пользователей С++, чтобы его добавить в язык. Это я к тому что со словами "не нужен (почти)" ты, имхо, погорячился

Здравствуйте, alexm1202, Вы писали:

A>Здравствуйте, Геннадий Васильев, Вы писали:

A>>>"В C++ нужно добавить необязательный сборщик мусора." Б. Страуструп "Дизайн и эволюция С++". Я не думаю что Страус стал бы так писать о средстве, которое не нужно (почти) пользователям языка.

ГВ>>Ключ — "необязательный".

A>Так в C++ много необязательных фич. Однако каждая из них была добавлена, исходя из тех соображений, что она существенно облегчит жизнь разработчикам в том или ином классе задач (не обязательно всем, кому-то например RTTI не нужен, а большинство прекрасно обходятся без МН). И, похоже, Страуструп считает что GC тоже облегчил бы жизнь достаточно большому числу пользователей С++, чтобы его добавить в язык. Это я к тому что со словами "не нужен (почти)" ты, имхо, погорячился

Достали своим gc http://www.hpl.hp.com/personal/Hans_Boehm/gc/index.html — одна из многих реализаций gc на Си. Видел где-то реализацию Intel, но навскидку не нашел...

Кому надо, тот и использует.... Жизнь себе облегчает, так сказать

Тут кто-то говорил, что Scala большей частью на VB напиана.

S>Здесь вы приводите тезисы, традиционно упоминаемые при сравнении С++ и более высокоуровневых языков типа C# и Java.
S>Да, согласен, С++ более требователен к разработчику чем Java и C#, это хорошо известно. Но вместе с тем это более гибкое и более скоростное решение. Так что такой аргумент меня не убеждает. Фактически вы утверждаете что С++ не годится потому, что он сложен. Ведь согласитесь, утечки и порча памяти — это проблемы кривого кода а не плохого языка.

Ну я конечно не знаю, может у тебя сплошь одни монстры работают, но что-то не очень верится.

S>Вообще надо сказать, что начиная с определенного уровня сложности задач, такой критерий как сложность языка совершенно теряется перед сложностью алгоритма и структур данных. И в такой ситуации необходимо делать выбор, основываясь на том, какие сопутствующие технологии существуют для того или иного языка.

C++ действительно очень сложен.
Хотите того или нет, ошибок наделаете море.
Потом их придется исправлять, а это скорее всего полностью сведет на нет все благие намерения насчет оптимальности и быстродействия.
В итоге получите то же самое, но с бОльшими трудозатратами и менее управляемое (C++ — код сопровождать куда труднее, чем ту же Java или VB).

> Тут кто-то говорил, что Scala большей частью на VB напиана.

И на C++ тако же. Там много всяких модификаций.

Здравствуйте, is, Вы писали:

is>Геннадий, если не затруднит, не мог бы ты дать ссылку на эту статейку/исследование — было бы очень занятно почитать.

Блин, как назло сама ссылка затерялась. Это — не то же самое, но для начала (о том же речь):

http://www.devnewz.com/2002/0207.html

Indeed, the study showed that a well-written Java program could equal or exceed the efficiency of an average-quality C/C++ program.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Блин, как назло сама ссылка затерялась.

Если вдруг попадется на глаза, то кинь, пожалуйста.

Здравствуйте, Slick,

Расскажу как сделано у нас (было ).
Набор технологий следующий: С#, ASP.NET, IE6, SQL Server. Для шифрования (зачем оно нужно в закрытой среде — это я не понимаю), можете использовать HTTPS. COM+ можно и не использовать, пока уж очень сильно не понадобится, web farm должно хватить. IE6 мы выбрали, потому что там всяких рюшичек хватает, и потому хороший GUI можно создать. Работать это дело будет достаточно быстро, поскольку всё родное от Microsoft.

А теперь раскажу о том что планируем делать на будущее, поскольку понадобилось произвести действительно большую систему для нескольких тысяч пользователей. Всё дело будет бегать под IBM AIX и WebSphere. Будем пользовать Java, IE6, Kodo JDO, Tangosol (для распеределённых кэшей) и Sybase как БД. Ожидаемая нагрузка пара тысяч одновременно работающих пользователей, отклик системы — максимум 3 секунды. Вообщем, как построим, так расскажу справились или нет

Здравствуйте, Mishka, Вы писали:

M>А теперь раскажу о том что планируем делать на будущее, поскольку понадобилось произвести действительно большую систему для нескольких тысяч пользователей. Всё дело будет бегать под IBM AIX и WebSphere. Будем пользовать Java, IE6, Kodo JDO, Tangosol (для распеределённых кэшей) и Sybase как БД.

Если не секрет, то почему Sybase, а не DB2, которая в сочетании с AIX и WebSphere выглядела бы логично?

Здравствуйте, alexm1202, Вы писали:

A>Если не секрет, то почему Sybase, а не DB2, которая в сочетании с AIX и WebSphere выглядела бы логично?

Я тоже это спросил
Оказалось, что это политический вопрос. Предприятие, для которого мы пишем, также имеет договора с IBM и Sybase, так что они там что-то делят (деньги наверно )