позволю себе аргументированно вам возразить (очередное сравнение с 1С)

[SolNik]

Цитата:

Сообщение от brahma

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



Например, QuickBooks. Я уж не знаю на чем эта самописка написана, но вроде как стандарт де-факто для бухгалтерских программ в США и Канаде.


Факты из жизни опровергают это утверждение. Масса продуктов и технологий получили широкое распространение, а уже потом под них подгонялись стандарты. Также есть примеры мертворожденных стандартов.



Думаете выкрали исходники Exel'я из Редмонда?

Цитата:

Сообщение от brahma

Ошибаетесь.

Цитата:

Сообщение от Сисой

В УПП прримерно 3700 таблиц.

Не уверен что в 1С с ее ORM-ом корректно оперировать физическими таблицами в БД. Как я писал выше, для анализа сложности системы можно сравнивать количество и связи между классами-сущностями. В Аксапте ими являются объекты метаданных типа таблица. В 1С - справочники, документы, планы счетов, регистры...Ну про таблицы я написал навскидку, что пришло в голову...По функционалу тут уже не раз пытались сделать battlecard, но они явно не отличались объективностью, ввиду заинтересованности обеих сторон ... По-моему опыту, с чем я сталкивался и там и там - планирование потребностей и ценообразование (не в смысле расчета цен а в смысле их настроек) в Акс гораздо навороченей.

[Reaper]

Щас нам начнут про плохую нормализацию БД долбить...

[Raven Melancholic]

Цитата:

Сообщение от Reaper

Щас нам начнут про плохую нормализацию БД долбить...

С чего бы вдруг? По отношению к 7.7 это было бы справедливо (как хранились периодические реквизиты, отборы, документы напоминать, думаю, не нужно). В восьмерке с этим все в порядке.
С точки зрения выхода на зарубежные рынки, на мой взгляд, проблема 1С в том, что для каждого их этих рынков 1С делает свою конфигурацию, а не общую, с возможностью настройки под конкретную страну (отставание тех же конфигураций для Украины от аналогичных Российских конфигураций заметно). Хотя, если смотреть на появление так называемого "управляемого приложения", что-то у 1С в этом отношении намечается.

[Lemming]

Цитата:

Сообщение от kuntashov

А по поводу ООП... Если вы адепт этого подхода, то вас наверняка уже задолбали фанаты хаскела, скалы и прочей функциональщины, разве нет?

[off]Scala гибридный язык, там с ООП все более чем в порядке.[/off] А что касается Х++, то все его объектно-ориентированные преимущества существенно теряются из-за практически полного отсутствием документации по основным прикладным модулям. А в локализации в некоторых случаях это особенно бросается в глаза, кто разбирался, например, с RLedgerSheet* или копался в коде с магическим заклинанием ANVA inventory reports тот поймет о чем я

upd: А еще всегда веселит как тут на форуме многие любят вспоминать про паттерны, ООП и прочие эфемерные понятия. Или я один такой "везучий", или те товарищи, которые про это рассуждают, редко копаются в коде соседей по кабинету, да и вообще в чужом коде написанном не в стенах микрософт. Потому как там, картинка резко меняется...

[SolNik]

Цитата:

Сообщение от Lemming

А что касается Х++, то все его объектно-ориентированные преимущества существенно теряются из-за практически полного отсутствием документации по основным прикладным модулям.

Если вы про документацию к коду, то хочу заметить, что одним из принципов ООП является написание самодокументируемого кода. Ну и помимо самого ООП весь BP направлен на это. А по базовым классам типа InventUpdate или LedgerVoucher документация есть.

Цитата:

Сообщение от Lemming

А в локализации в некоторых случаях это особенно бросается в глаза, кто разбирался, например, с RLedgerSheet*

А что, нормальный класс, не иделаьный конечно, но мы на проектах часто делаем от него наследников для реализации оборотки по банку и кассе. Хороший пример реализации паттернов Polymorphism, Low coupling, High cohesion и разделения логики и представления. "Вы просто не умеете их готовить"

Цитата:

Сообщение от Lemming

upd: А еще всегда веселит как тут на форуме многие любят вспоминать про паттерны, ООП и прочие эфемерные понятия. Или я один такой "везучий", или те товарищи, которые про это рассуждают, редко копаются в коде соседей по кабинету, да и вообще в чужом коде написанном не в стенах микрософт. Потому как там, картинка резко меняется...

Можно интимный вопрос? Вы работали(работаете) когда-нибудь у партнера? В скольких проектах вы участвовали?...Мы на своих проектах (компания-партнер) четко следуем методологии и всегда есть выделенный Senior Developer, который жестко пресекает всякие антипаттерны и smell code. И эта практика в большинстве случаев продолжает поддерживаться клиентами в своих командах.

[Lemming]

Цитата:

Сообщение от SolNik

А что, нормальный класс, не иделаьный конечно, но мы на проектах часто делаем от него наследников для реализации оборотки по банку и кассе. Хороший пример реализации паттернов Polymorphism, Low coupling, High cohesion и разделения логики и представления. "Вы просто не умеете их готовить"

ок, я понял, стало быть мне не повезло... Если у вас такая классная команда или отдельные люди, напишите пошаговый туториал как сделать свою оборотку на базе RLedgerSheet* и ваши доводы будут ясны и приняты + всячески респектированны участниками форума. Пример "как писать подобный пост/доку" очень дурацкий, но какой есть, можно его превзойти в сотни раз! А пока я вижу ваш контент только в разделе "рынок", мне сложно оценить потенциал и компетенцию вашей команды

Цитата:

Сообщение от SolNik

Можно интимный вопрос? Вы работали(работаете) когда-нибудь у партнера? В скольких проектах вы участвовали?...

Только там и работал, в разной степени ~в шести, активно в четырех.

[Logger]

Цитата:

Сообщение от Lemming

Если у вас такая классная команда или отдельные люди, напишите пошаговый туториал как сделать свою оборотку на базе RLedgerSheet* и ваши доводы будут ясны и приняты + всячески респектированны участниками форума.

А не надо этого делать.
Оборотку надо переписывать с нуля.

[konopello]

Цитата:

"Доступно и всерьез" - слоган, с которого началась маркетинговая экспансия 1С. И то, что ООП нет в языке 1С действительно намеренное решение, его исходное назначение было - описание именно бизнес-логики и именно специалистами на стыке предметной области и программирования.

честно сказать я настолько привык к ООП и насмотрелся на задачи которые решались без него (слава богу в SAP много таких примеров), мне тяжело просто это представить, или вы просто делаете просто формочки с функциональностью да и отчеты (у меня в голове не укладывается как в современном мире можно обходится без принципов OOA/OOD/OOP)

[Сисой]

Пять копеек в дискуссию (для старожилов форума эта информация ничем новым не является).
Работал я до Оптимы в компании Цефей. Там была разработана в начале века замечательная штука - Эталон. В 90-е годы это была учетная ORM на базе FoxPro (с отчетами а-ля 1С 8). При создании Windows-версии решили не мелочиться и создали мощную систему разработки, реализующую ORM в сочетании с ООП (т.е. при желании наследовались целые группы таблиц).
Язык программирования был похож по нотации на C++. СУБД: MS SQL и Oracle (но в отличие от 1С, с развитыми возможностями управления БД, использованием констрейнтов, триггеров, низкоуровневых операций с таблицами).
Казалось бы, все есть, чего еще надо? А споткнулись на простой вещи. Штат Цефея в эпоху DOS-овского Эталона состоял из специалистов, подобных 1Сникам. "Все в одном". Многие в прошлом были бухгалтерами или финдирами, т.е. консалтинг вели достаточно квалифицированно, а скриптовый язык на базе конструкций FoxPro освоить было несложно.
И вот всех начали переводить на ООП...
Через несколько лет компания практически потеряла свою долю рынка. Потому что вновь написанные решения отличались невиданной кривизной, базовые классы проектировались как бог на душу положит, производительность упала. Выяснилось, что быть одновременно хорошим аналитиком и программистом ой как нелегко (даже мне с многолетним опытом разработки на С++). Да и в самой платформе появлялись глюки из-за сложности продукта.
Пока перестраивались, пока учились, поезд ушел.
Я потом на 1С 7 перешел, долго плевался от ее куцых возможностей.
Потом 1С 8 появилась, стало легче. Но ко всем призывам внедрить полноценное ООП в платформу отношусь настороженно. Не готовы многие к нему. И похоже, не будут готовы никогда.

[Raven Melancholic]

Цитата:

Сообщение от Сисой

Пока перестраивались, пока учились, поезд ушел.

Тем не менее, судя по всему, перестроились.
Эта фирма располагается в том же бизнес центре, что и наша, этажом выше. Судя по количеству сотрудников, работают неплохо.

[Сисой]

Цитата:

Сообщение от Raven Melancholic

Тем не менее, судя по всему, перестроились.
Эта фирма располагается в том же бизнес центре, что и наша, этажом выше. Судя по количеству сотрудников, работают неплохо.

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

[SolNik]

Цитата:

Сообщение от Сисой

Пять копеек в дискуссию (для старожилов форума эта информация ничем новым не является).
Работал я до Оптимы в компании Цефей. Там была разработана в начале века замечательная штука - Эталон. В 90-е годы это была учетная ORM на базе FoxPro (с отчетами а-ля 1С 8). При создании Windows-версии решили не мелочиться и создали мощную систему разработки, реализующую ORM в сочетании с ООП (т.е. при желании наследовались целые группы таблиц).
Язык программирования был похож по нотации на C++. СУБД: MS SQL и Oracle (но в отличие от 1С, с развитыми возможностями управления БД, использованием констрейнтов, триггеров, низкоуровневых операций с таблицами).
Казалось бы, все есть, чего еще надо? А споткнулись на простой вещи. Штат Цефея в эпоху DOS-овского Эталона состоял из специалистов, подобных 1Сникам. "Все в одном". Многие в прошлом были бухгалтерами или финдирами, т.е. консалтинг вели достаточно квалифицированно, а скриптовый язык на базе конструкций FoxPro освоить было несложно.
И вот всех начали переводить на ООП...
Через несколько лет компания практически потеряла свою долю рынка. Потому что вновь написанные решения отличались невиданной кривизной, базовые классы проектировались как бог на душу положит, производительность упала. Выяснилось, что быть одновременно хорошим аналитиком и программистом ой как нелегко (даже мне с многолетним опытом разработки на С++). Да и в самой платформе появлялись глюки из-за сложности продукта.
Пока перестраивались, пока учились, поезд ушел.
Я потом на 1С 7 перешел, долго плевался от ее куцых возможностей.
Потом 1С 8 появилась, стало легче. Но ко всем призывам внедрить полноценное ООП в платформу отношусь настороженно. Не готовы многие к нему. И похоже, не будут готовы никогда.

Слуушайте, ну вы сами прекрасно знаете, что качество, гибкость, простота и тому подобные св-ва продукта - это малая доля в его успехе...Нуралиев - гениальный маркетолог, бизнесмен. Он сформировал идеальную среду для распространения своего продукта...Да простота модификации и доработок этого продукта тоже сыграли свою роль, но далеко не определяющую...Также я думаю и в случае с Цефеем - наличие в нем мощной среды разработки вряд ли стало решающим в его провале...
Да возьмите ту же Аксапту. Наличие ООП уж точно не является сдерживающим фактором в ее развитии.

[Mileyko]

Языки программирования 1С, X++, ABAP и другие — это прикладные языки. Их основная задача состоит в эффективной (быстрой, простой, надёжной) реализации прикладных задач. Вот вы говорите об ООП, блокировках, управлении памятью. Да, методы ООП, разумеется, позволяют повысить эффективность кода и я, работая на клиенте, использую в своих модификациях эти методы. Управление блокировками, памятью — это более низкоуровневые задачи, также как и дизайн автоматических отчётов, автоматическое расположение полей на форме. Если я хочу сделать форму, то я просто добавляю необходимые компоненты на форму и не думаю о том, куда именно мне надо поместить компонент, какие координаты для него задать — за меня это сделает MorphX.

И из текущей темы:

Цитата:

Тут правильно было отмечено, что 1Сник лучше знает НУ, чем классическое программирование или архитектуру базы данных.

Цитата:

А если задать еще более глубокий вопрос по управлению памятью. Это будет просто удар под дых.

Дело в том, можно накрутить в прикладной язык программирования методы системного языка и, например, реализовывать формы с помощью WPF, XAML, SilverLight (как я думаю это будет в AX 6.0), но тогда этот язык станет менее прикладным. Следствием этого станет то, что повысится уровень требований для программистов и появится ещё одна группа консультантов-программистов к уже существующим группам программистов и консультантов. Эта третья группа будет необходима для того, чтобы переводить задачи консультантов программистам и решать именно прикладные задачи, пока программисты делают форму на WPF. В свою очередь это приведёт к увлечению стоимости разработки. В теме «С чём связан дефицит программистов AX» была очень интересная мысль от BOAL. Я хотел бы процитировать его:

Цитата:

Вот и выходит, что с увеличением сложности Динамиксов на пути слияния в экстазе с другими технологиями и требования знаний C# и прочих исконно МСных фичей, привлекательность ее изучения падает, тк нужно слишком много всего разного знать, и оч долго учиться самому (за беспл). И ради чего? Ради зп, которую дают после 1-2 мес изучения обычных, доступных системили не ЕРП вообще?

[ibc]

Цитата:

Но ко всем призывам внедрить полноценное ООП в платформу отношусь настороженно. Не готовы многие к нему. И похоже, не будут готовы никогда.

Почему никогда? DELPHI в свое время любой студент 1-го курса способен был освоить!
Тут причина в другом, скорее всего!

[Lemming]

Цитата:

Сообщение от ibc

Почему никогда? DELPHI в свое время любой студент 1-го курса способен был освоить!
Тут причина в другом, скорее всего!

Ага, ту его часть которая касается процесса кинуть контрол на форму, ткнуть в свойствах на onClick и записать в этот метод бизнес логику. К ООП это никакого отношения не имеет и столь же успешно осваивается тогда в Visual Basic или Access, а сегодня в 1С. Достаточно большое количество таких программистов плохо понимает процессы, происходящие между выводом кнопки на экран и событием ее нажатия. Поскольку автор один, вся эта братия плавно перетекает в .NET. Да и вообще, насколько я помню ООП в Object Pascal муторное, Хейлсберг еще толком не понимал с кого копировать модель, так что взял что-то от С++, выдумал модификаторам новые имена и забил. Никому в Delphi это ООП не нужно, на фоне его возможностей программировать мышкой. Так что да, причина в другом

[brahma]

Цитата:

Сообщение от Lemming

Никому в Delphi это ООП не нужно, на фоне его возможностей программировать мышкой. Так что да, причина в другом

Практически вся визуальная библиотека (если не изменяет память VCL) написана на самой Delphi. И там ООП к месту. А вот программировать формочки, на мой взгляд, и правда хватит скриптового языка. Просто нет одного универсального решения на все задачи. ООП тоже нужно с умом применять и там где ему место.
А "кривое" решение можно сделать и с ООП и с без него. Для ООП, кроме паттернов, существует целая коллекция антипаттернов.

[SolNik]

Цитата:

Сообщение от Lemming

Ага, ту его часть которая касается процесса кинуть контрол на форму, ткнуть в свойствах на onClick и записать в этот метод бизнес логику. К ООП это никакого отношения не имеет и столь же успешно осваивается тогда в Visual Basic или Access, а сегодня в 1С. Достаточно большое количество таких программистов плохо понимает процессы, происходящие между выводом кнопки на экран и событием ее нажатия. Поскольку автор один, вся эта братия плавно перетекает в .NET. Да и вообще, насколько я помню ООП в Object Pascal муторное, Хейлсберг еще толком не понимал с кого копировать модель, так что взял что-то от С++, выдумал модификаторам новые имена и забил. Никому в Delphi это ООП не нужно, на фоне его возможностей программировать мышкой. Так что да, причина в другом

Я поражаюсь, с какой легкостью тут люди сводят на нет все достижения в computer science вообще и в конкретных языка\технологиях в частности...
Для справки - на Delphi написано большинство АБС в нашей стране, самый популярный в России банк-клиент написан на Delphi. Я лично проработал в продуктовой компании, занимающейся разработкой одной из самых популярных МИС в нашей стране и сейчас продолжаю вести свой проект на Delphi...не представляю как можно было бы реализовать все эти продукты без использования ООП...да и в сообществе Delphi-стов не встречал таких - "Никому в Delphi это ООП не нужно, на фоне его возможностей программировать мышкой."...
Если следовать вашей логике, ООП возможно использовать только в консольных редакторах...смешно просто...

[Lemming]

Цитата:

Сообщение от SolNik

Для справки - на Delphi написано большинство АБС в нашей стране, самый популярный в России банк-клиент написан на Delphi. Я лично проработал в продуктовой компании, занимающейся разработкой одной из самых популярных МИС в нашей стране и сейчас продолжаю вести свой проект на Delphi...

QIP забыли упомянуть Для тех кто не понимает почему в России столько legacy-кода построенного на убойной и абсурдной в глазах западного заказчика связке Delphi + Oracle. Ответ звучит банально: стоимость использования этих продуктов равняется стоимости одной болванки приобретенной на радио-рынке. Поэтому у нас в каждом овощном магазине крутится складская программа на БД Oracle с мордой написанной мышкой на Delphi. Причем сама СУБД стоит дороже, чем все то барахло, остатки которого в ней хранятся. Бесплатность, низкий порог вхождения и pascal в большинстве отечественных ВУЗов и сделали популярность этого продукта с весьма сомнительной идеологией. Ну и немого статистики по языкам, там про Delphi отдельно сказано.

[ibc]

Цитата:

Для ООП, кроме паттернов, существует целая коллекция антипаттернов.

Что бы это значило?

[MikeR]

Опять одынэсники атакуют.
Вот вы мне скажите в какой версии 1С уйдут или ушли от извращенных понятий регистра сведений и регистра накоплений?