Здравствуйте, Cyberax, Вы писали:
C>И является замечательным источником ошибок на больших проектах, особенно C>тех, которые пишут неквалифицированные программисты....
Программирование это вообще источник ошибок. В форумах, мэйллистах и news группах подобные дискуссии обычно оканчиваются тем, что люди соглашаются на следующем:
1) Статическая проверка типов увеличивает количество ошибок, пойманное до тестирования.
2) Статическая типизация позволяет генерировать более эффективный код.
3) Последствия отсутствия статической проверки типов а ассемблере, FORTH, и С гораздо хуже, чем в языках Smalltalk, JScript и Python. Ошибки типизации в С обыкновенно ведут к повреждению памяти, что невозможно в перечисленных языках — они проверяют типы в рантайме.
4) Часть людей считает, что явная аннотация типов является неотемлемой и критичной частью их подхода к программированию, и что время, потраченное на это, окупается сокращением времени отладки, тестирования, и сопровождения.
5) При этом, другие люди уверены в том, что аннотации типов замусоривают код и делают программы менее гибкими, что удлинняет фазу прототипирования и затруднят экcперименты.
Также, неплохо иметь в виду, что:
1) Определение типов возможно без аннотации типов (пример — система типов Хиндли-Милнера, которая гарантирует определение типа из контекста). Такая техника называется type inference, и применяется во многих, как статически, так и динамически типизированных языках, в частности, в JScript.NET.
2) Также, многие динамически типизированные языки разрешают явную аннотацию типов. Как например JScript.NET.
3) Вышеперечисленное позволяет динамически типизированным языкам, вопреки распространенному мнению, достигать высокой производительности сравнимой с С# и Java а также выявлять ошибки типизации до тестирования (но не обязательно во время компиляции — часто это делается отдельными тулзами).
4) Динамическая типизация не более опасна, чем явное использование динамического приведения типов в языках Java и C#. Техника программирования, подразумевающая использование QueryInterface (в COM) и вообще динамических запросов интерфейсов (в Java и C#) не имеет такой "убийственной" репутации, как динамическая типизация, хотя совершенно ей эквивалентна. На самом деле тот же С# позволяет писать динамически типизированный код, только он будет выглядеть более громоздко. У вас используется тип Object? Вы запрашиваете у объекта интерфейс? Поздравляю, ваш код динамически типизирован.
5) Процесс разработки с применением динамически типизированных языков существенно отличается от такового для статически типизированных. Он в гораздо большей степени итеративен и ориентирован на прототипирование — естественно, в нем находят отражение сильные стороны динамически типизированных языков. В силу отличий процессов разработки ответ на вопрос о качестве не так однозначен. Поясню.
Цена исправления дефекта в среднем тем больше, чем больше прошло времени с его внесения до его обнаружения (по данным Carnegi-Mellon SEI). Таким образом, у нас ошибки типизации находятся позже, и возрастает цена их исправления. Однако, благодаря большей ориентированности цикла разработки на прототипирование, раньше находятся алгоритмические дефекты и дефекты дизайна (которые всегда стоят дороже ошибок типизации), и их исправление будет стоить дешевле. На деле эти два фактора нивелируют друг друга, что подтверждает...
6) ...практика написания больших систем на динамически типизированных языках без применения статических проверок типов. Она показывает, что наличие динамической типизации не влияет заметным образом на количество ошибок в конечной системе, и такие ошибки не являются критическим фактором при разработке. В частности, метрики Ericsson по закрытым проектам (среди которых есть проекты размером до 2.5 миллионов строк) показывают, что средняя плотность дефектов на тысячу строк кода в динамически типизированных языках (Erlang) практически не отличается от таковой для статически типизированных языков (Java, C++, PLEX).
Хао. Я все сказал. ИМХО, повода для флейма нет. Мне, например, все понятно .
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Надо написать такую, есть выбор между C++ (производительность) и C# (простота разработки).
C++ — даже не думай об этом.
МЗ>Нюанс в том, что эта erp — по сути "конструктор" (наподобии 1С или Axapta). Если брать С++ то надо писать парсер маппирования данных, новую компонентную систему (COM/CORBA не подходит). Рвусь писать на .Net — так как это там всё гораздо проще, но вот его производительность и прожорливость меня останавливает.
Забей. Во первых, языки дотнета довольно шустры, посмотри тесты. На численных расчетах они на равных с С++.
К тому же, все равно твоя еэрпя упрется в базу данных, это не численные методы. Это во вторых. Если ты запустишь профайлер на 1С-коде (там очень тормозной интерпретатор), ты сможешь сам увидеть раскладку 90/10%. Да и вообще, такая раскладка имеет место быть в большинстве правильно написанных приложений БД. Это если говорить о двухзвенке.
В случае трехзвенки — утечки памяти и крэши на серваке (где цена ошибки гораздо выше) — неприятная штука. Совсем небольшой минус от сборщика мусора (не более 5% от времени полезной работы сервака) того стоит, чтобы на него плюнуть, не говоря о том, что ты просто его не заметишь. К тому же, аллокатор дотнета работает в целом лучше, чем стандартный плюсовый . Бояться надо другого. Большие boxed массивы маленьких объектов — в этом проблема (решаемая), а не в сборщике мусора.
Поэтому не парься, пиши все на шарпах, а в качастве языка программируемой бизнес-логики возьми JScript.NET — это динамически типизированный язык с аннотацией типов — то, что доктор прописал.
МЗ>зы. Я буду писать в комманде (я главный архитектор), у меня есть как С++ программисты, так и C# программисты. Бяков утечек памяти/крахов указателей я от С++ не жду.
А это как раз не проблема. Ты с компонентной моделью и скриптингом гораздо больше натрахаешься.
Если это коммерческий проект, то я бы посоветовал разработать свой язык (для бизнес логики разумеется, а не для написания ядра ). Тем более для системы-конструктора. Я тоже пишу подобную систему, и считаю что практически невозможно реализовать качественный конструктор, наподобие 1С без своего встроенного языка.
Здравствуйте, Максим Зелински, Вы писали:
МЗ>>>Я же вроде писал , что пока будем использовать C# для логики, а потом прикрутим язык предметной области.
S>>1) Покажите мне прикладного разработчика (внедренца), который сможет подключить свой любимый язык в ваш фреймворк. МЗ>Если ему дать хороший фреймворк, с хорошей документацией и с примерами, то почему он не сможет? Во всяком случаи он может "купить" какой-нибудь встроенный язык
Он просто не захочет тратить на это свое время. С какой стати? Ему нужен один единственный язык, с хорошей заточкой под предметную область.
МЗ> Не понравиться — напишет свой
Ошибаетесь. Если вы ему такой язык не дадите, он просто обратится к другому производителю, который предоставит ему такой язык. Так же, как если ему вся ваша система не понравится, то он не начнет писать свою, а купит другую. Потому что писать языки и системы — это ваша работа, а не его, и он за это платит. Впрочем, бизнес расставит все по своим местам.
S>>Сами вначале мучались. Сначала хотели на Delphi, потом на встроееной в Oracle Java, потом на Java Script и т.д. Плюнули, вобщем, и потратили пол-года на свой язык. МЗ>У нас то же был такой опыт (стоит отметить, что проектная документация со всякими ТТ писалась больше года), мы прошли от полностью встроенного языка до концепции "зоопарка", как вы выразились.
При этом сами предпочитаете писать на одном-единственном C#, а не на зоопарке. А ваш пользователь должен будет:
1) Знать С#, чтобы разбираться в ваших типовых решениях — вы их собрались писать на С#.
2) Знать (зачем-то) отдельный язык, на котором вы хотите, чтобы он писал бизнес логику.
А если ему все это не понравится (а мне, как бывшему внедренцу, это уже сильно не нравится. Уверен, что не понравится и другим), вы предлагаете ему создать до кучи третий, свой собственный язык. Смотрите, вам виднее.
Здравствуйте, Максим Зелински, Вы писали:
МЗ>>>Если ему дать хороший фреймворк, с хорошей документацией и с примерами, то почему он не сможет? Во всяком случаи он может "купить" какой-нибудь встроенный язык G>>Он просто не захочет тратить на это свое время. С какой стати? Ему нужен один единственный язык, с хорошей заточкой под предметную область. МЗ>Не захочет?, не надо! Берет и качает "бесплатный" Только вот проблема, если язык у системы один и вшит намертво, как быть с "хорошей заточкой под предметную область"?
Этот единственный язык должен ее иметь. Вот и вся проблема. Не захочет — ничего качать не будет. Обратится к другому производителю. С какой стати трахаться с вашим фреймворком, что-то качать, докручивать, доделывать, если ваши конкуренты все сделали по уму — так, что этим заниматься не надо?
МЗ>>> Не понравиться — напишет свой G>>Ошибаетесь. Если вы ему такой язык не дадите, он просто обратится к другому производителю, который предоставит ему такой язык. Так же, как если ему вся ваша система не понравится, то он не начнет писать свою, а купит другую. Потому что писать языки и системы — это ваша работа, а не его, и он за это платит. Впрочем, бизнес расставит все по своим местам. МЗ>Хм. Вообще есть два типа конторок "внедренцев" (да простят меня их представители): лавочки, которые берут какой-нибудь ТР и просто устанавливают на все компьютеры клиента (короче, не дальше инсталла и создания конфигураций пользователей). Да, им всякие навороты не нужны. А есть и более серьезные конторы: которые пишут эти самые ТР. Вот им то и понравиться наш "зоопарк", так как они могут написать "свой" язык, который в точности отражает предметную область (то есть максимально под нёё заточен). Если хотят быть просто разработчиками ТП, и не заморачиваться с языками (я признаю, тут конечно нужны специалисты для создания хорошего языка), могут заказать такой язык у другого разработчика (разделение производства, аутсортинг) или воспользоваться "стандартным" бесплатным. Мы просто не привязываем всех к нашему "стандартному" языку, если у внедренца есть желания написать свой язык предметной области, мы его поможем, предоставив удобные функции замены стандартного.
Вы вылетите в трубу к чертовой матери с таким подходом к внедренцам. Я за вас, ей богу, переживаю. Объясните мне как внедренцу. С какой стати я буду заказывать свой язык для вашего фреймворка (недецким образом умножая проектные риски, и тратя бабло непонятно на что), если у вашего конкурента я смогу взять все то, что мне надо — дешевле? Да, это мне обойдется дешевле, так как нормальный язык со средой и фреймворком будет растиражирован вашим конкурентом, а не сделан персонально под меня. Это влияет на стоимость моего решения, понимаете? Для нескольких десятков рабочих мест я лучше выберу 1С — мне это сократит сроки разработки вдвое без всякой трахотни со своими языками. В конце концов, чем писать свой язык и разбираться в вашем фреймворке, дешевле запрограммить все на VB под MS SQL. Подумайте об этом — в том, что 1С держит 98% рынка есть не только маркетинговые, но и технологические причины.
G>>При этом сами предпочитаете писать на одном-единственном C#, а не на зоопарке. МЗ>Это "шпилька"? Боже упаси, если придется что-то дописывать на С++.
Это констатация факта. Вам, почему-то, так проще. И мне тоже. и все остальным.
G>>А ваш пользователь должен будет: МЗ>Пользователь? Вы наверное имели ввиду "внедренца" или разработчика ТР?
Внедренца, конечно. Респект за конструктивную позицию — другие бы с говном съели.
G>>1) Знать С#, чтобы разбираться в ваших типовых решениях — вы их собрались писать на С#. МЗ>Если он захочет на нём писать. Мы же не связываем ему руки?
Связываете, в том все и дело. Вы типовухи собрались писать на C# — тьем самым вы вынуждаете внедренца знать C#, чтобы разбираться в них и адаптировать ваши типовухи.
G>>2) Знать (зачем-то) отдельный язык, на котором вы хотите, чтобы он писал бизнес логику. МЗ>Вы наверное меня не правильно поняли. Хочешь писать на С# — пиши только на нём. Хочешь писать на языке с 1C like синтаксисом — пиши на нём и только, тогда система будет просто напоминать "расширенную" 1С 8.0 или Axapta, знание C# в последнем случае не нужно.
Понял прекрасно. Знать C# надо будет обязательно, так как ваши типовые решения будут написаны на нем, это вы понимаете? Все, вы уже подняли порог профессионализма для внедренца. Добавления всех остальных — более простых языков — не помогут.
G>>А если ему все это не понравится (а мне, как бывшему внедренцу, это уже сильно не нравится. Уверен, что не понравится и другим), вы предлагаете ему создать до кучи третий, свой собственный язык. Смотрите, вам виднее. МЗ>Кстати, мне очень важны ваши замечания раз вы бывший внедренец. МЗ>Детально расписываю, какой есть выбор у разработчика ТР (подпольная кличка "внедренец"): МЗ> МЗ>Он может писать ТР на любом языке .Net платформы. МЗ>Этот выбор "максимально" производителен (всё же есть такие ТР, где нужна повешенная производительность, согласитесь, с интерпретируемыми языками это сложно). Мы предоставляем удобный фреймворк для такого решения.
Вы уже расчитываете на "внедренца", знакомого с платформой .net. Сильно сужаете рынок, ИМХО. Большинство .NET программеров напишет все с нуля, им ваш фреймворк не нужен.
МЗ>Он может "купить" или "заказать" язык предметной области. МЗ>Хотите не заморачиваться с C# языком? Пожалуйста, вот вам бесплатный типизированный язык с высокой абстракцией. МЗ>Хотите расширяемости своего ТР конечными "внедренцами"? Закажите язык, который наиболее полно будет подходить для вашей предметной области.
Этого вообще никогда никто делать не будет. Причины я озвучил.
МЗ>Комбинация всего этого.
Сомнительно. Хотите проверить реальность ваших планов? Придумайте success story, где все это реально имеет значение.
МЗ>Тут действительно винегрет. Но есть сценарии: бизнес логика на C#, а бизнес правила на своём языке. МЗ>
Здравствуйте, Максим Зелински, Вы писали:
МЗ>зы. Я буду писать в комманде (я главный архитектор), у меня есть как С++ программисты, так и C# программисты. Бяков утечек памяти/крахов указателей я от С++ не жду.
А зря. Из-за таких нежданчиков на моей памяти сроки проектов вырастали в разы.
G>>Да не перживай ты так . "Виртуальные" модули совершенно эквивалентны по выразимтельной силе ООП — как врач тебе говорю. Просто не вводится лишнее понятие, и все .
G>>"Глобальные переменные" модуля будут переменными класса. "Экземпляр модуля"(класса) создается, например, через СоздатьОбъект. К нему через точку вызываются определенные там функции. "Глобальные переменные" доступны как члены контекста через точку. И все дела. Теперь добавляешь только ключевое слово extends (расширить существующий модуль) — и вот тебе наследование.
G>>Чем это лучше классов? Тем, что документы, элементы справочников — уже сейчас фактически являются "виртуальными" модулями. "Отчет" — это модуль с визуальной формой. Надо добавить "свободный" модуль без формы (что делается на халяву) — и вуаля. Не усложняя языка ты получаешь свое ООП, спокойно обходясь без понятия класса.
S> В этом плане я с тобой полность согласен. И это достаточно удобно. В принципе язык 1С меня полностью устраивает. S>Просто у него есть недостатки S> 1. Из- за отсутствия типизации отсутствует подсказа через току (интелсиленсе или как его)
Ну это эстетство S> 2. Из — за отсутсвия типизации ошибка может выявиться через несколь лет.
Зато можешь наслаждаться полиморфными функциями, не забивая голову шаблонами и женериками. И существенно меньше будет болеть голова по поводу разработки объектной модели.
S> 3. Скорость.
Надо добавить необязательную аннотацию типов, так, как это сделано в JScript.NET (после определения переменной опционально ":тип"). И все будет в порядке.
S> Хотелось бы иметь такой язык, что бы совмешал в сете как статическую типизацию так и позднее связывание.
JScript.NET S> Вот смотрю я на питон и облизываюсь. А как у него там со статической типизацией????
Плохо .
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, Serginio1, Вы писали:
S>> Несмотря на выпуск 8 ки основная масса сидит на 7.7 причем на связке дбф+ терминальные сессии.
R3>У нас народ сидит на 7.7 sql без терминала. Всё упирается в железо — не дают его. И так думаю не только у нас, но и у многих контор с урезанным бюджетом.
Если рассматривать применение терминальных сессий, то эконмия на клиентах существенная, т.к. вкладываешься только в сервер и мониторы для клиентов. Клиентское железо может быть сколь угодно старым, вплоть до бездисковых станций с загрузкой по сети (достаточно много линуксовских малых по объему клиентов). Так, что с учетом сервера цена клиентского места в 300 $ не столь существенна (если конецно не экономить на мониторе).
Подключение торгового оборудования тоже не проблема. (порты хорошо мапятся)
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Максим Зелински, Вы писали:
S>>Тем более для системы-конструктора. Я тоже пишу подобную систему, и считаю что практически невозможно реализовать качественный конструктор, наподобие 1С без своего встроенного языка. МЗ>Ну вот тут я бы поспорил. C# можно использовать для написания бизнес логики, и мы планируем, что типовые решения из-за скорости будут написаны именно на нём.
В базу вы упретесь, в базу и компоненты фреймворка. Как сделаете что-нибудь работающее, померяйте профайлером, сами увидите, если не верите.
Теперь о том, что ИМХО важно на самом деле. Скорость языка для написания типовых решений не важна, важнее другое — нужна легкость поддержки (низкая цена внесения изменений), концептуальная простота языка (только необходимый минимум изобразительных возможностей), а также максимальная заточка языка с фреймворком под предметную область. Последнее самое важное — концептуальная пропасть между средствами языка/фреймворка и предметной областью должна по возможности отсутствовать.
Напишете типовые решения на С# — тем самым не добьетесь ничего, кроме того, что существенно поднимете порог квалификации специалиста по внедрению и цену внедрения. Ведь предполагается, что в типовые решения могут вносится изменения, так?
МЗ>Встроенный язык мы не будет делать не в коем случае, мы не хотим, чтобы пользователь потом страдал, если ему язык не нравиться. Вместо этого мы предоставим разработчикам фреймворк для подключения любого языка. Тем самым мы можем добавить хоть эмулятор языка 1C, хоть басика
Это разумно. Но заметным образом на ваши продажи не повлияет, ИМХО — воспользуются этой возможностью единицы. Впрочем, я не знаю предполагаемую среднюю цену внедрения для вашей системы и описания предполагаемого клиента (с оценкой объема рынка). Это бы все прояснило.
Здравствуйте, Real 3L0, Вы писали:
R3>Тогда, в чем необходимость существования вашего продукта?
Странный вопрос . Наверное деньги хотим заработать А что вас смущает?
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Я же вроде писал , что пока будем использовать C# для логики, а потом прикрутим язык предметной области.
Извините не заметил.
МЗ>Вместо этого мы предоставим разработчикам фреймворк для подключения любого языка. Тем самым мы можем добавить хоть эмулятор языка 1C, хоть басика
1) Покажите мне прикладного разработчика (внедренца), который сможет подключить свой любимый язык в ваш фреймворк.
Я не знаю, но под нормальной системой-конструктор я понимаю хотя бы следующее:
— исходники прикладных программ хранятся на сервере в базе, так же как и остальные метаданные.
— откомпилированные программы (байт-код) хранятся там же и загружаются безо всяких временных файлов.
— отслеживаются зависимости между модулями (с автоматической перекомпиляцией зависимых модулей).
— есть возможность остановить выполнение программы в любой момент.
Ни один из известных мне языков/компиляторов не выполняет в достаточной степени эти требования.
Даже готовые скриптовые компоненты такого не поддерживают.
2) Я согласен с Gaperton про "концептуальную пропасть", потому что язык должен быть как можно более заточен под предметную область. Вот, например, для обычной системы управления предприятием необходимы:
— втроенные типы данных (и операции с ними), которые дают возможность работы с SQL NULL
— втроенные запросы, на уровне синтаксиса языка, а не как библиотека. Должны работать с объектами системы, а не напрямую с таблицами бд, так как:
— должна быть абстракция уровня данных, т.е. объекты предметной области и объявляться они должны достаточно просто, а не генерится тулзой в кучу непонятного кода (как, например, в Delphi ECO).
— и т.д.
3) Про скорость я так же согласен с Gaperton. Скорость байт-кодного интерпретатора более чем достаточна, тем более, что на встроенном языке будут выполняться только прикладные программы, а они работают с использованием системных сервисов, которые могут быть реализованы на более низкоуровневом языке.
4) Про наличие нескольких языков: это большое зло, ибо нефиг устраивать зоопарк. Наоборот нужно стремится к стандартизации средств, идей и концепций, и навязывать не столь квалифицированным прикладным разработчикам заранее продуманные решения.
Сами вначале мучались. Сначала хотели на Delphi, потом на встроееной в Oracle Java, потом на Java Script и т.д. Плюнули, вобщем, и потратили пол-года на свой язык.
Вот смотрю я на 1С. И вижу следующую ситуацию.
Несмотря на выпуск 8 ки основная масса сидит на 7.7 причем на связке дбф+ терминальные сессии.
Скорости хватает, конфигураций полно, да и тех возможностей языка вполне хватает.
С другой стороны должен подойти MBS.
Так или иначе все упрется в БД и конфигурации + цена разработки (или грамотно разработанные типовые но с достаточно простыми подгонкой под свои потребности, и смотря на эволюцию конфигураций 1С дело это не столь быстрое)
Гиблое это дело ИМХО, но нужное. В любом случае выбирать то особо не из чего Net (учитывая его развитие и применение в ОС и БД (ЮКОН)) или Ява опять же по этим причинам
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, Максим Зелински, Вы писали:
S>>Вот смотрю я на 1С. И вижу следующую ситуацию. S>> Несмотря на выпуск 8 ки основная масса сидит на 7.7 причем на связке дбф+ терминальные сессии. МЗ>Это смотря где. В мелких конторах — да. Ну например информационную систему просто на 7.7 не напишешь Потом там БОЛЬШИЕ дыры в безопасности Всё же всё, что было до 8, "бухгалтерский" софт. ИМХО.
Для автоматизации небольших предприятий (30 клиентов + распределенные ИБ), там на самом деле есть все, что называется громким имение ERP, или несложно их до этого уровня доделать (вплоть от написания с нуля)
S>> С другой стороны должен подойти MBS. МЗ>Microsoft Business Solutions? Так он уже рядом. Axapta.
Не совсем то. Основное это объектный код на сервере, и таких вот ситуаций http://www.rsdn.ru/Forum/Message.aspx?mid=952244&only=1
огромное количество. И никакие трехзвенки здесь особо не помогут. Есть надежды на Юкон с SP на Net S>> Так или иначе все упрется в БД и конфигурации + цена разработки (или грамотно разработанные типовые но с достаточно простыми подгонкой под свои потребности, и смотря на эволюцию конфигураций 1С дело это не столь быстрое) МЗ>Не буду спорить. S>> Гиблое это дело ИМХО, но нужное. В любом случае выбирать то особо не из чего Net (учитывая его развитие и применение в ОС и БД (ЮКОН)) или Ява опять же по этим причинам МЗ>Не могли бы вы расставить знаки препинания. Просто не могу понять логику последнего предложения
Опять же исходя из того, что в ближайшем будущем все SP будут писаться на манагед языках (Net,Java) выбирать особо не из чего. За Явой IBM,Оракул за Net мы знаем все. Причем применеиее терминальных сессий как Sun так и на M$ наводит на мысль выполнение всег кода на сервере.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Если это небольшая фирма — пожалуйста, у нас будет язык с 1C like синтаксисом (бесплатно). Не понравиться — напишет свой
Во первых, работать с вашим языком (даже 1С like) надо учится, чего не надо делать с 1С.
Во вторых, я нашим 1С-никам кидал шутку: Перед прочтением взвести таймер
Здравствуйте, Максим Зелински, Вы писали:
МЗ>А что, язык 1С впитывается с молоком матери?
Я про то, что это самый простой язык, но люди, его использующие на самом деле не настоящие программисты и => создать свой язык для них будет не простой задачей.
МЗ>Не открывается у меня
На чём сейчас пишут erp (незнаю, какой подобрать нормальный термин, программы управления предприятием)? Действительно ли производительность erp систем уже отошла на второй план, а на первый: функциональность + расширяемость?
Надо написать такую, есть выбор между C++ (производительность) и C# (простота разработки).
Нюанс в том, что эта erp — по сути "конструктор" (наподобии 1С или Axapta). Если брать С++ то надо писать парсер маппирования данных, новую компонентную систему (COM/CORBA не подходит). Рвусь писать на .Net — так как это там всё гораздо проще, но вот его производительность и прожорливость меня останавливает.
зы. Я буду писать в комманде (я главный архитектор), у меня есть как С++ программисты, так и C# программисты. Бяков утечек памяти/крахов указателей я от С++ не жду.
11.01.05 10:38: Перенесено из 'Философия программирования'
Здравствуйте, AndrewVK, Вы писали:
AVK>А зря. Из-за таких нежданчиков на моей памяти сроки проектов вырастали в разы.
Это уже 4 мой проект с этими ребятами (хотя сейчас я может буду работать с C#). Там QA настолько жестокий, что аж искры летят
Так что мне выбрать? Можно ли смериться с гипотетической потерей производительности C#?
Здравствуйте, AndrewVK, Вы писали:
AVK>Мы смирились. Тем более что производительность обычно не в процессор упирается.
В память?
А вобще, какие сейчас "мировые" тенденции в области erp софта? В смысле языков.
Здравствуйте, Максим Зелински, Вы писали:
AVK>>Мы смирились. Тем более что производительность обычно не в процессор упирается. МЗ>В память?
В БД.
МЗ>А вобще, какие сейчас "мировые" тенденции в области erp софта? В смысле языков.
Если говорить об относительно свежем софте, то Java. О .NET пока говорить рановато, но о создании платформ на нем в России объявили несколько крупных контор.
Здравствуйте, AndrewVK, Вы писали:
AVK>но о создании платформ на нем в России объявили несколько крупных контор.
Извените, что использую вас за места гугля, но я первый раз это слышу, не могли бы вы написать кто они?
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Так что мне выбрать? Можно ли смериться с гипотетической потерей производительности C#?
При грамоном использовании дотнета и наличии достаточного количества памяти, и естественно, при условии что в одном из случаев вы не сделаете каких-нибудь глупостей... можно ожидать потерю в скорости до 1.1-1.5 раз. Если высвободившееся время пустить на оптимизацию алгоритмов и поиск более грамотных проектных решений, то... ну, думаю ты понял.
Ну, и главное! От С++ как средства оптимизации отказыватьс совершенно не нужно. Если вы обнаружите узкие места которые, по вашему мнению, могут быть устранены реализацией узких мест на С++, то спокойно переисывайте их на нем и смотрите что получилось.
Скорсоть MC++ практически идентична анменеджед VC той же версии.
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Согласен со всем сказанным. Но...
G>Поэтому не парься, пиши все на шарпах, а в качастве языка программируемой бизнес-логики возьми JScript.NET — это динамически типизированный язык с аннотацией типов — то, что доктор прописал.
Практика показывает, что в реальной системе гораздо большее влияние на производительность оказывают такие вещи, как архитектура системы, оптимальность запросов к СУБД, сама СУБД. На фоне всего этого падение производительности от managed кода C# ничтожна. А вот GUI на С#/WinForms может здорово тормозить здорово, по сравнению с MFC/VCL.
G>В случае трехзвенки — утечки памяти и крэши на серваке (где цена ошибки гораздо выше) — неприятная штука. Совсем небольшой минус от сборщика мусора (не более 5% от времени полезной работы сервака)
Хм.. Я вот поглядывал process explorer'ом — он часто показывает время GC посущественнее — процентов 20 бывает, а в пике — и того больше. Это все на глаз, конечно, так что несерьезно.
G>Поэтому не парься, пиши все на шарпах, а в качастве языка программируемой бизнес-логики возьми JScript.NET — это динамически типизированный язык с аннотацией типов — то, что доктор прописал.
Я тут подумал, а что мешает организовать программируемую бизнес-логику на С#. Вроде особых проблем не вижу (только плюсы).
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Gaperton, Вы писали:
G>>Поэтому не парься, пиши все на шарпах, а в качастве языка программируемой бизнес-логики возьми JScript.NET — это динамически типизированный язык с аннотацией типов — то, что доктор прописал. GZ>Я тут подумал, а что мешает организовать программируемую бизнес-логику на С#. Вроде особых проблем не вижу (только плюсы).
Ее можно организовать вообще на чем угодно, принципиальных проблем нет.
Первое. Динамическая типизация избавит вас от необходимости делать приведения типов "вниз" по иерархии наследования и запрашивать интерфейсы, что (в ряде случаев) очень положительно сказывается на том, как выглядит пользовательский код.
Второе (менее очевидное) — динамически типизированный язык в качестве языка бизнес логики дает больше свободы при разработке объектной модели.
Для простых объектных моделей разницы между С# и JScript.NET как языков бизнес-логики действительно не будет (как и каких-либо плюсов от использования С# — JScript.NET язык с аннотицаей типов), а столнетесь со сложными — сами поймете, когда и где вам поможет динамическая типизация.
Здравствуйте, Igor Trofimov, Вы писали:
G>>В случае трехзвенки — утечки памяти и крэши на серваке (где цена ошибки гораздо выше) — неприятная штука. Совсем небольшой минус от сборщика мусора (не более 5% от времени полезной работы сервака)
iT>Хм.. Я вот поглядывал process explorer'ом — он часто показывает время GC посущественнее — процентов 20 бывает, а в пике — и того больше. Это все на глаз, конечно, так что несерьезно.
Это в пике, это не считается.
iT>А ваши 5% — откуда померяны/прочитаны?
Из статей о современных GC, сейчас уже не помню где именно. Кажется, такие цифры приводились для GC под С++ (там вообще пессемистическая схема — все проверяется на "живой" указатель. Тормозить должно больше чем с метаинформацией).
В принципе, не составит труда написать приложение которое загрузит GC по самое не балуйся, если поставить себе такую задачу специально. А можно постараться вообще память выделять по минимуму и реюзать все что возможно (как делают программисты под J2ME, чтобы не нагружать GC). Так что цифры условные, все конечно зависит от приложения.
Здравствуйте, Igor Trofimov, Вы писали:
G>>В случае трехзвенки — утечки памяти и крэши на серваке (где цена ошибки гораздо выше) — неприятная штука. Совсем небольшой минус от сборщика мусора (не более 5% от времени полезной работы сервака)
iT>Хм.. Я вот поглядывал process explorer'ом — он часто показывает время GC посущественнее — процентов 20 бывает, а в пике — и того больше. Это все на глаз, конечно, так что несерьезно.
Хм, а сколько времени занимала бы в тех же случаях "ручная" аллокация-деаллокация, вот что интересно . Она же тоже не бесплатна. Надо бы и это принять во внимание, по хорошему, а не просто смотреть время GC.
iT>А ваши 5% — откуда померяны/прочитаны?
В этом свете данные о 5% оверхэде для плюсовых сборщиков наиболее корректны — это как раз замеряно сравнением с "ручной сборкой" на тех же программах. Что проблематично сделать в случае дотнета.
Кстати, удивительное рядом. В статьях о GC также иногда пишут как о чем-то само-собой разумеющемся, что сборка мусора на основе подсчета ссылок менее эффективна, чем анализ графа зависимостей (mark-and-sweep и stop-and-copy). Несколько раз встречал.
Gaperton пишет:
> Кстати, удивительное рядом. В статьях о GC также иногда пишут как о > чем-то само-собой разумеющемся, что сборка мусора на основе подсчета > ссылок *менее *эффективна, чем анализ графа зависимостей > (mark-and-sweep и stop-and-copy). Несколько раз встречал.
Так и есть, в подавляющем большинстве случаев. Так как в многотредных
приложениях каждое присваивание refconted-ссылки будет требовать
блокировки ДВУХ мьютексов.
Здравствуйте, Gaperton, Вы писали:
G>Второе (менее очевидное) — динамически типизированный язык в качестве языка бизнес логики дает больше свободы при разработке объектной модели.
Какие-же преимущества он дает? Возможность использование системы менее квалифицированными программистами?
Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>Второе (менее очевидное) — динамически типизированный язык в качестве языка бизнес логики дает больше свободы при разработке объектной модели.
S>Какие-же преимущества он дает? Возможность использование системы менее квалифицированными программистами?
Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>Второе (менее очевидное) — динамически типизированный язык в качестве языка бизнес логики дает больше свободы при разработке объектной модели. S>Какие-же преимущества он дает? Возможность использование системы менее квалифицированными программистами?
Динамическая типизация заметно упрощает дизайн, что, с одной стороны, снижает требования к квалификации программиста, с другой, освобождает квалифицированного от размышлений, не связанных на прямую с прикладной областью. На каких-то задачах это более заметно, на каких-то не заметно вовсе — примеры привести сложно.
Если посмотреть внимательно, то вы заметите, что в строго типизированных языках наследование применяется в частности и для того, чтобы обеспечить некоторые свойства динамической типизации. Конкретнее, речь идет о полиморфных переменных, которые могут хранить значения разных типов (эти типы должны быть увязаны в иерархию наследования, и иметь общего предка), и полиморфных вызовах функций (которые аргументом принимают полиморфные переменные). Объект, для которого вызывается метод, также является его (неявным) аргументом.
При этом, разрабатывая объектную модель для строго типизированного языка вы думаете не только о прикладном смысле классов, но также вынуждены думать о том, как организовать полиморфизм. В случае динамически типизированных языков вы об этом не думаете.
Gaperton пишет:
> G>>Второе (менее очевидное) — динамически типизированный язык в > качестве языка бизнес логики дает больше свободы при разработке > объектной модели. > S>Какие-же преимущества он дает? Возможность использование системы > менее квалифицированными программистами? > Динамическая типизация заметно упрощает дизайн, что, с одной стороны, > снижает требования к квалификации программиста, с другой, освобождает > квалифицированного от размышлений, не связанных на прямую с прикладной > областью.
И является замечательным источником ошибок на больших проектах, особенно
тех, которые пишут неквалифицированные программисты....
Здравствуйте, Cyberax, Вы писали:
C>Gaperton пишет:
>> Кстати, удивительное рядом. В статьях о GC также иногда пишут как о >> чем-то само-собой разумеющемся, что сборка мусора на основе подсчета >> ссылок *менее *эффективна, чем анализ графа зависимостей >> (mark-and-sweep и stop-and-copy). Несколько раз встречал.
C>Так и есть, в подавляющем большинстве случаев. Так как в многотредных C>приложениях каждое присваивание refconted-ссылки будет требовать C>блокировки ДВУХ мьютексов.
А я верю . Даже в однопоточном случае необходимо постоянно дергать счетчик при каждом присваивании. GC же в среднем будет пробегаться по каждому из объектов реже.
Здравствуйте, GlebZ, Вы писали:
G>>Поэтому не парься, пиши все на шарпах, а в качастве языка программируемой бизнес-логики возьми JScript.NET — это динамически типизированный язык с аннотацией типов — то, что доктор прописал. GZ>Я тут подумал, а что мешает организовать программируемую бизнес-логику на С#. Вроде особых проблем не вижу (только плюсы).
Кстати, мы так и делаем . На первых порах, во всяком случае, потом, наверное, прикрутим интерпретаторы для языков предметной области.
GZ>С уважением, Gleb.
Здравствуйте, VladD2, Вы писали:
VD>При грамоном использовании дотнета и наличии достаточного количества памяти, и естественно, при условии что в одном из случаев вы не сделаете каких-нибудь глупостей... можно ожидать потерю в скорости до 1.1-1.5 раз. Если высвободившееся время пустить на оптимизацию алгоритмов и поиск более грамотных проектных решений, то... ну, думаю ты понял.
Я всё же выбрал дотНет, и вот почему:
да, наши замеры показали, что просев скорости от 1.1 до 1.6 (замеряли фреймворк 1.1), когда пересели на фреймворк 2.0 просев был от 1.1 до 1.4. Это всё не очень страшно, главное что наша производительность увеличилась. Особенно мои программисты балдеют от IL, настоящей компонентности (нет больше всяких IDL для Кома, геморроя со статическими переменными в разных модулях, загроможденности кода), атрибутов. Я даже более детально стал поучивать C#, чтоб не отстать Честно сознаюсь, я "фанат" C++, до того как я вплотную познакомился с C# я его считал "языком для дурачков", теперь я так не считаю. Во всяком случаи в моей области (создание ПО управления предприятием (erp, scm, crm)) — это правильный выбор, так как в C# есть всё, что может "облегчить" жизнь (сначала я планировал делать систему на С++, в планах стояло написать свою компонентную модель, поддержку атрибутов и т.д.).
VD>Ну, и главное! От С++ как средства оптимизации отказыватьс совершенно не нужно. Если вы обнаружите узкие места которые, по вашему мнению, могут быть устранены реализацией узких мест на С++, то спокойно переисывайте их на нем и смотрите что получилось.
Хех, надеюсь, что таких мест будет крайне мало. Очень приятно, что у C# есть нормальная система интеропа, в отличии от Java.
VD>Скорсоть MC++ практически идентична анменеджед VC той же версии.
MC++ — уродец
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Максим Зелински, Вы писали:
МЗ>>Надо написать такую, есть выбор между C++ (производительность) и C# (простота разработки). G>C++ — даже не думай об этом.
Уже не думаю...
G>Забей. Во первых, языки дотнета довольно шустры, посмотри тесты. На численных расчетах они на равных с С++.
Хотя просев есть Но я уверен, что MS это исправит.
G>В случае трехзвенки — утечки памяти и крэши на серваке (где цена ошибки гораздо выше) — неприятная штука. Совсем небольшой минус от сборщика мусора (не более 5% от времени полезной работы сервака) того стоит, чтобы на него плюнуть, не говоря о том, что ты просто его не заметишь. К тому же, аллокатор дотнета работает в целом лучше, чем стандартный плюсовый . Бояться надо другого. Большие boxed массивы маленьких объектов — в этом проблема (решаемая), а не в сборщике мусора.
Перешли на фреймворк 2.0. Боксинга вроде больше нет и хорошо.
G>Поэтому не парься, пиши все на шарпах, а в качастве языка программируемой бизнес-логики возьми JScript.NET — это динамически типизированный язык с аннотацией типов — то, что доктор прописал.
Для БО на первых порах будем использовать сам C#, потом прикрутим интерпретатор языка предметной области.
G>А это как раз не проблема. Ты с компонентной моделью и скриптингом гораздо больше натрахаешься.
Да, скриптинг прикрутить к объектам (при чем не изменяя их!) как два пальца об асфальт
Здравствуйте, Максим Зелински, Вы писали:
G>>А это как раз не проблема. Ты с компонентной моделью и скриптингом гораздо больше натрахаешься. МЗ>Да, скриптинг прикрутить к объектам (при чем не изменяя их!) как два пальца об асфальт
Ну, не все так радужно . Ты уже в курсе, что нельзя выгружать отдельные сборки? Что выружать можно только домен целиком? Если вы собираетесь разрешить замену кода на работающей системе, это может стать проблемой — налетите на междоменную передачу данных, а это небыстро.
Причем, при выгрузке домена происходит memory leak, что в ряде случаев тоже может стать проблемой. Не знаю, поправили ли это во второй версии фреймворка.
Далее, в версиях фреймворка <2.0 приложение-отладчик должен быть unmanaged (это вообще пипец). Правда, в 2.0 это обещали поправить.
G>Причем, при выгрузке домена происходит memory leak, что в ряде случаев тоже может стать проблемой. Не знаю, поправили ли это во второй версии фреймворка.
Memory leak возникает, если загружать каждый раз разные сборки (!). Случай довольно специфический, но иногда это чудовищные грабли. Это значит, в частности, что пользуясь платформой .NET не так просто написать Web-browser с поддержкой JavaScript.
Далее, приятная новость осени прошлого года. Microsoft прекратил разработку продукта Visual Studio for Applications .NET. Продукта не будет. Всем сожалеющим об этом рекомендуется кастомизировать "взрослую" Visual Studio .NET. Надеялись использовать VSA? Хренушки.
Короче, если нужен полноценный скриптинг во всех позах, Java — лучший выбор, чем .NET. Почему так:
1) Единица загрузки — класс (не сборка).
2) Неиспользуемые классы удаляются GC (в дот нет вы можете выгрузить только домен целиком, обязаны делать это вручную, и это в некоторых случаях дает memory leak)
3) Плюс к этому, написав свой ClassLoader, вы полностью контроллируете политику загрузки и выгрузки классов.
4) Для JVM есть большое количество готовых скриптовых языков и решений.
Здравствуйте, Real 3L0, Вы писали:
МЗ>>Нюанс в том, что эта erp — по сути "конструктор" (наподобии 1С или Axapta).
R3>Интересно. R3>Пишите на своё/определенное предприятие? R3>Почему отказались от существующих решений?
Если бы писали под своё предприятие, то не заторачивались с "конструктором" (а именно, писать свой бизнес фреймворк дело не из простых). Это коробочный софт.
Здравствуйте, Gaperton, Вы писали:
МЗ>>Да, скриптинг прикрутить к объектам (при чем не изменяя их!) как два пальца об асфальт G>Ну, не все так радужно . Ты уже в курсе, что нельзя выгружать отдельные сборки? Что выружать можно только домен целиком? Если вы собираетесь разрешить замену кода на работающей системе, это может стать проблемой — налетите на междоменную передачу данных, а это небыстро.
Ну это детали, можно сделать полу интерпретированную надстройку (компилиться в свой байт код и потом интерпретируется), конечно Reflection.Emit использовать с существующими ограничениями (на выгрузку сборок) пока не будем. Но когда продукт выйдет на финальную стадию (а языки предметных областей будут разрабатываться после выхода финальной версии), подоспеет и второй фреймворк, где это вроде обещали исправить.
Здравствуйте, Gaperton, Вы писали:
G>Далее, приятная новость осени прошлого года. Microsoft прекратил разработку продукта Visual Studio for Applications .NET. Продукта не будет. Всем сожалеющим об этом рекомендуется кастомизировать "взрослую" Visual Studio .NET. Надеялись использовать VSA? Хренушки.
Да, обидно, но жить можно.
G>Короче, если нужен полноценный скриптинг во всех позах, Java — лучший выбор, чем .NET. Почему так:
Мы к Java приценивались, но пришлось отказаться, так как там нет "атрибутов", которые очень нам нужны.
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Если бы писали под своё предприятие, то не заторачивались с "конструктором" (а именно, писать свой бизнес фреймворк дело не из простых). Это коробочный софт.
Тогда, в чем необходимость существования вашего продукта?
Здравствуйте, Real 3L0, Вы писали:
R3>Т.е. в продажах не сомневаетесь?
Конечно сомневаемся, это наш "первенец" в области бизнес софта. Во всяком случаи наш софт будет выделяться на фоне остальных конструкторов, таких как 1С, Axapta, Sap R/3, своими "уникальными" возможностями. К сожалению, я не вправе (пока во всяком случае) их раскрывать, могу только сказать, что у нас трёх звённая архитектура, мы очень много времени уделили разработке подходов к "проверке" данных, поступающих от клиентов, наша система объединяет лучшие свойства онлайн (безопасность данных на уровне логики) и оффлайн подхода (возможность работы в автономном режиме), так что нам вроде как есть что предложить рынку.
Здравствуйте, stalcer, Вы писали:
S>Если это коммерческий проект, то я бы посоветовал разработать свой язык (для бизнес логики разумеется, а не для написания ядра ).
Я же вроде писал , что пока будем использовать C# для логики, а потом прикрутим язык предметной области.
S>Тем более для системы-конструктора. Я тоже пишу подобную систему, и считаю что практически невозможно реализовать качественный конструктор, наподобие 1С без своего встроенного языка.
Ну вот тут я бы поспорил. C# можно использовать для написания бизнес логики, и мы планируем, что типовые решения из-за скорости будут написаны именно на нём. Встроенный язык мы не будет делать не в коем случае, мы не хотим, чтобы пользователь потом страдал, если ему язык не нравиться. Вместо этого мы предоставим разработчикам фреймворк для подключения любого языка. Тем самым мы можем добавить хоть эмулятор языка 1C, хоть басика
Здравствуйте, Gaperton, Вы писали:
G>В базу вы упретесь, в базу и компоненты фреймворка. Как сделаете что-нибудь работающее, померяйте профайлером, сами увидите, если не верите.
Не буду спорить. Просто идея с возможностью реализации бизнес логики на C# (или любом .Net совместимом языке), нам показалась хорошей. Я же не отрицал, что поддержки встроенных языков не будет.
G>Теперь о том, что ИМХО важно на самом деле. Скорость языка для написания типовых решений не важна, важнее другое — нужна легкость поддержки (низкая цена внесения изменений), концептуальная простота языка (только необходимый минимум изобразительных возможностей), а также максимальная заточка языка с фреймворком под предметную область. Последнее самое важное — концептуальная пропасть между средствами языка/фреймворка и предметной областью должна по возможности отсутствовать.
Я вроде уже писал, что мы будем предоставлять фреймворк для создания таких языков. Я прекрасно это понимаю.
G>Напишете типовые решения на С# — тем самым не добьетесь ничего, кроме того, что существенно поднимете порог квалификации специалиста по внедрению и цену внедрения. Ведь предполагается, что в типовые решения могут вносится изменения, так?
Это зависит от политики "внедренца". Поддержка языков предметной области есть. Он может либо писать на C# (Basic.Net, любой .Net совместимый язык), либо использовать какой-нибудь язык предметной области (планируем их распространять отдельно), либо написать свой, если проект большой.
G>Это разумно. Но заметным образом на ваши продажи не повлияет, ИМХО — воспользуются этой возможностью единицы. Впрочем, я не знаю предполагаемую среднюю цену внедрения для вашей системы и описания предполагаемого клиента (с оценкой объема рынка). Это бы все прояснило.
Почему "единицы"? Я не очень понимаю, в чем плох подход с заменой встроенного языка? Разработчик подсистемы бизнес правил может написать свой язык, наподобие:
if( price > 1000 )
priceDrop = 0.1
а для предметной области использовать что-то наподобие X++? Наоборот, вариантов очень много, система становиться гораздо «гибче» при внедрении, чем завязывание на одном встроенном языке.
"Цена" внедрения для нашего софта будет меньше, чем у конкурентов это точно. Благодаря гибкости настроек, гибкости расширения и т.д.
Рынок: весь диапазон, от мала до велика. В конструкторе заложено очень сильное масштабирования для крупного бизнеса, но он тем не менее не такой "тяжелый" для понимания, для малого/среднего решение можно написать. В основном конечно ориентируемся на средний бизнес.
Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, Максим Зелински, Вы писали:
МЗ>>Я же вроде писал , что пока будем использовать C# для логики, а потом прикрутим язык предметной области.
S>Извините не заметил.
Да ладно, не страшно
S>1) Покажите мне прикладного разработчика (внедренца), который сможет подключить свой любимый язык в ваш фреймворк.
Если ему дать хороший фреймворк, с хорошей документацией и с примерами, то почему он не сможет? Во всяком случаи он может "купить" какой-нибудь встроенный язык
S>Я не знаю, но под нормальной системой-конструктор я понимаю хотя бы следующее: S> — исходники прикладных программ хранятся на сервере в базе, так же как и остальные метаданные.
Это верно как для .Net сборок, так и для языков предметной области. S> — откомпилированные программы (байт-код) хранятся там же и загружаются безо всяких временных файлов.
Это верно как для .Net сборок, так и для языков предметной области. S> — отслеживаются зависимости между модулями (с автоматической перекомпиляцией зависимых модулей).
Это верно как для .Net сборок, так и для языков предметной области. S> — есть возможность остановить выполнение программы в любой момент.
А это зачем? "Не за что", у нас нет даже такого сценария! Если обновляется БО (в частности, изменяется его схема), то если не написан "адаптер", система для старых записей использует старый объект. Для C# объектов мы используем возможности .Net фреймворка.
S>Ни один из известных мне языков/компиляторов не выполняет в достаточной степени эти требования.
Может быть расширите ваши требования? Так как под них попадает модули хоть на C++ языке.
S>2) Я согласен с Gaperton про "концептуальную пропасть", потому что язык должен быть как можно более заточен под предметную область. Вот, например, для обычной системы управления предприятием необходимы: S> — втроенные типы данных (и операции с ними), которые дают возможность работы с SQL NULL S> — втроенные запросы, на уровне синтаксиса языка, а не как библиотека. Должны работать с объектами системы, а не напрямую с таблицами бд, так как: S> — должна быть абстракция уровня данных, т.е. объекты предметной области и объявляться они должны достаточно просто, а не генерится тулзой в кучу непонятного кода (как, например, в Delphi ECO). S> — и т.д.
Это всё есть для .Net языков в нашем фреймворке БО "улучшаются" (code enchanced) при добавлении к системе (система смотрит атрибуты и генерирует IL кода, что-то наподобие O/R Mapping'а, в частности FastObject'а)..
S>4) Про наличие нескольких языков: это большое зло, ибо нефиг устраивать зоопарк. Наоборот нужно стремится к стандартизации средств, идей и концепций, и навязывать не столь квалифицированным прикладным разработчикам заранее продуманные решения.
Я с этим в корне не согласен. Так же с этим заявлением наверное не согласна корпорация Microsoft (посмотрите, в .Net'е не один язык). Зло — это когда язык вшит в систему. Достаточно посмотреть как "коряво" добавляется объектная надстройка (классы) в языке 1С сторонними разработчиками. В моей случаи разработчик может использовать C# язык (да любой .Net язык) — чем не стандартное средство? Может "купить" язык, может написать язык. Всё может. Если это небольшая фирма — пожалуйста, у нас будет язык с 1C like синтаксисом (бесплатно). Не понравиться — напишет свой
S>Сами вначале мучались. Сначала хотели на Delphi, потом на встроееной в Oracle Java, потом на Java Script и т.д. Плюнули, вобщем, и потратили пол-года на свой язык.
У нас то же был такой опыт (стоит отметить, что проектная документация со всякими ТТ писалась больше года), мы прошли от полностью встроенного языка до концепции "зоопарка", как вы выразились.
S>
Аналогично
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Максим Зелински, Вы писали:
S>Вот смотрю я на 1С. И вижу следующую ситуацию. S> Несмотря на выпуск 8 ки основная масса сидит на 7.7 причем на связке дбф+ терминальные сессии.
Это смотря где. В мелких конторах — да. Ну например информационную систему просто на 7.7 не напишешь Потом там БОЛЬШИЕ дыры в безопасности Всё же всё, что было до 8, "бухгалтерский" софт. ИМХО.
S> С другой стороны должен подойти MBS.
Microsoft Business Solutions? Так он уже рядом. Axapta. S> Так или иначе все упрется в БД и конфигурации + цена разработки (или грамотно разработанные типовые но с достаточно простыми подгонкой под свои потребности, и смотря на эволюцию конфигураций 1С дело это не столь быстрое)
Не буду спорить. S> Гиблое это дело ИМХО, но нужное. В любом случае выбирать то особо не из чего Net (учитывая его развитие и применение в ОС и БД (ЮКОН)) или Ява опять же по этим причинам
Не могли бы вы расставить знаки препинания. Просто не могу понять логику последнего предложения
Здравствуйте, Gaperton, Вы писали:
G>2) Неиспользуемые классы удаляются GC (в дот нет вы можете выгрузить только домен целиком, обязаны делать это вручную, и это в некоторых случаях дает memory leak)
В CompactFramework-е GC может удалять из памяти скомпилированный (jitted) код.
Здравствуйте, Gaperton, Вы писали:
S>>>1) Покажите мне прикладного разработчика (внедренца), который сможет подключить свой любимый язык в ваш фреймворк. МЗ>>Если ему дать хороший фреймворк, с хорошей документацией и с примерами, то почему он не сможет? Во всяком случаи он может "купить" какой-нибудь встроенный язык G>Он просто не захочет тратить на это свое время. С какой стати? Ему нужен один единственный язык, с хорошей заточкой под предметную область.
Не захочет?, не надо! Берет и качает "бесплатный" Только вот проблема, если язык у системы один и вшит намертво, как быть с "хорошей заточкой под предметную область"?
МЗ>> Не понравиться — напишет свой G>Ошибаетесь. Если вы ему такой язык не дадите, он просто обратится к другому производителю, который предоставит ему такой язык. Так же, как если ему вся ваша система не понравится, то он не начнет писать свою, а купит другую. Потому что писать языки и системы — это ваша работа, а не его, и он за это платит. Впрочем, бизнес расставит все по своим местам.
Хм. Вообще есть два типа конторок "внедренцев" (да простят меня их представители): лавочки, которые берут какой-нибудь ТР и просто устанавливают на все компьютеры клиента (короче, не дальше инсталла и создания конфигураций пользователей). Да, им всякие навороты не нужны. А есть и более серьезные конторы: которые пишут эти самые ТР. Вот им то и понравиться наш "зоопарк", так как они могут написать "свой" язык, который в точности отражает предметную область (то есть максимально под нёё заточен). Если хотят быть просто разработчиками ТП, и не заморачиваться с языками (я признаю, тут конечно нужны специалисты для создания хорошего языка), могут заказать такой язык у другого разработчика (разделение производства, аутсортинг) или воспользоваться "стандартным" бесплатным. Мы просто не привязываем всех к нашему "стандартному" языку, если у внедренца есть желания написать свой язык предметной области, мы его поможем, предоставив удобные функции замены стандартного.
S>>>Сами вначале мучались. Сначала хотели на Delphi, потом на встроееной в Oracle Java, потом на Java Script и т.д. Плюнули, вобщем, и потратили пол-года на свой язык. МЗ>>У нас то же был такой опыт (стоит отметить, что проектная документация со всякими ТТ писалась больше года), мы прошли от полностью встроенного языка до концепции "зоопарка", как вы выразились. G>При этом сами предпочитаете писать на одном-единственном C#, а не на зоопарке.
Это "шпилька"? Боже упаси, если придется что-то дописывать на С++. G>А ваш пользователь должен будет:
Пользователь? Вы наверное имели ввиду "внедренца" или разработчика ТР? G>1) Знать С#, чтобы разбираться в ваших типовых решениях — вы их собрались писать на С#.
Если он захочет на нём писать. Мы же не связываем ему руки? G>2) Знать (зачем-то) отдельный язык, на котором вы хотите, чтобы он писал бизнес логику.
Вы наверное меня не правильно поняли. Хочешь писать на С# — пиши только на нём. Хочешь писать на языке с 1C like синтаксисом — пиши на нём и только, тогда система будет просто напоминать "расширенную" 1С 8.0 или Axapta, знание C# в последнем случае не нужно. G>А если ему все это не понравится (а мне, как бывшему внедренцу, это уже сильно не нравится. Уверен, что не понравится и другим), вы предлагаете ему создать до кучи третий, свой собственный язык. Смотрите, вам виднее.
Кстати, мне очень важны ваши замечания раз вы бывший внедренец.
Детально расписываю, какой есть выбор у разработчика ТР (подпольная кличка "внедренец"): Он может писать ТР на любом языке .Net платформы.
Этот выбор "максимально" производителен (всё же есть такие ТР, где нужна повешенная производительность, согласитесь, с интерпретируемыми языками это сложно). Мы предоставляем удобный фреймворк для такого решения.
Он может "купить" или "заказать" язык предметной области.
Хотите не заморачиваться с C# языком? Пожалуйста, вот вам бесплатный типизированный язык с высокой абстракцией.
Хотите расширяемости своего ТР конечными "внедренцами"? Закажите язык, который наиболее полно будет подходить для вашей предметной области.
Комбинация всего этого.
Тут действительно винегрет. Но есть сценарии: бизнес логика на C#, а бизнес правила на своём языке.
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Может быть расширите ваши требования? Так как под них попадает модули хоть на C++ языке.
Ладно согласен, .Net здесь вообщем подходит. Но меня терзает такое смутное предчуствие, что вот упретесь вы в какую-нибудь проблему, а поменять-то никак. А так взял немного подправил компилятор/VM и все дела. Но это сугубое imho.
МЗ>Это всё есть для .Net языков в нашем фреймворке БО "улучшаются" (code enchanced) при добавлении к системе (система смотрит атрибуты и генерирует IL кода, что-то наподобие O/R Mapping'а, в частности FastObject'а)..
В смысе, текст препроцессится или байт код меняется? Потому-что кроме функциональности необходим именно удобный синтаксис. В препроцессор я не верю. Только если его сложность будет сопоставима со сложностью компилятора. Только тогда проще написать сам компилятор.
МЗ>У нас то же был такой опыт (стоит отметить, что проектная документация со всякими ТТ писалась больше года), мы прошли от полностью встроенного языка до концепции "зоопарка", как вы выразились.
Странно . Многие системы имеют свой единственный встроенный язык. А нетовские языки — это фишка MS для завоевывания популярности нета. Они же исковерканные, например, Java она же не такая как настоящая.
Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, Максим Зелински, Вы писали:
МЗ>>Может быть расширите ваши требования? Так как под них попадает модули хоть на C++ языке.
S>Ладно согласен, .Net здесь вообщем подходит. Но меня терзает такое смутное предчуствие, что вот упретесь вы в какую-нибудь проблему, а поменять-то никак. А так взял немного подправил компилятор/VM и все дела. Но это сугубое imho.
Вы о разработке системы или ТР? Если мы не сможем реализовать удобный фреймворк, то мы оставим только вариант с интерпретируемыми языками. Еще раз повторюсь, в нашей системе можно писать как на C#, так и на любом интерпретируемом языке.
S>В смысе, текст препроцессится или байт код меняется? Потому что кроме функциональности необходим именно удобный синтаксис. В препроцессор я не верю. Только если его сложность будет сопоставима со сложностью компилятора. Только тогда проще написать сам компилятор.
Байт код естественно. Никаких препроцессоров кода!
S>Странно . Многие системы имеют свой единственный встроенный язык. А нетовские языки — это фишка MS для завоевывания популярности нета. Они же исковерканные, например, Java она же не такая как настоящая.
Многие системы разрабатывались в дремучие 90. Многие системы — не конструкторы. Рынок развивается, нужно выводить "принципиально" новые продукты.
Здравствуйте, Serginio1, Вы писали:
S> Несмотря на выпуск 8 ки основная масса сидит на 7.7 причем на связке дбф+ терминальные сессии.
У нас народ сидит на 7.7 sql без терминала. Всё упирается в железо — не дают его. И так думаю не только у нас, но и у многих контор с урезанным бюджетом.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, AndrewVK, Вы писали:
AVK>>Ну навскидку Парус , Галактика, МС . Дальше ищи сам. Можешь поглядет на вакансии в форуме job.offers
L>+ Компас
О да..... Компас ЭТА КРУТА!!!
В прошлом году подходил к ним на выставке, что говорю вы можете о ней, что в нех крутого?
У нас все почти также хорошо как в 1С, но есть уникальная фича — программа конфигурирования показывает имена файлов для таблиц.
Чем это круче и какие это дает преимущества, так и не понял, как не старался выспроситью
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Вы о разработке системы или ТР?
Все что я писал — только о разработке конфигураций (не ядра), ножет и не только типовых.
МЗ>Если мы не сможем реализовать удобный фреймворк, то мы оставим только вариант с интерпретируемыми языками.
МЗ>Байт код естественно. Никаких препроцессоров кода!
Тогда и синтаксиса удобного не сможете сделать. Ну и не будете, как я понял.
И ваша стандартная конфигурация (вы ведь сами-то собираетесь писать ТП) будет нечитаемой.
МЗ>Многие системы разрабатывались в дремучие 90. Многие системы — не конструкторы. Рынок развивается, нужно выводить "принципиально" новые продукты.
Продукты и сейчас развиваются. Только проблемы несколько другие: повышение производительности (в основном не языка) или вот здесь
G>>Короче, если нужен полноценный скриптинг во всех позах, Java — лучший выбор, чем .NET. Почему так: МЗ>Мы к Java приценивались, но пришлось отказаться, так как там нет "атрибутов", которые очень нам нужны.
как это нет ??? а в JDK1.5 ??
Здравствуйте, stalcer, Вы писали:
МЗ>>Байт код естественно. Никаких препроцессоров кода! S>Тогда и синтаксиса удобного не сможете сделать. Ну и не будете, как я понял.
Ну почему не будет? Атрибуты .Net — очень удобная штука в плане расширяемости синтаксиса.
Вот типовой объект на C#
[BusinessObject]
class Payment
{
[secured] public bool Payment()
{
...
}
[stored] private int nOrder;
}
Всё! Больше ничего писать не надо.
S>И ваша стандартная конфигурация (вы ведь сами-то собираетесь писать ТП) будет нечитаемой.
Что значит "нечитаемой"? Я пока не знаю, что там думают маркетологи, может быть наши ТР буду в исходниках поставляться.
S>Продукты и сейчас развиваются. Только проблемы несколько другие: повышение производительности (в основном не языка) или вот здесь
Здравствуйте, Real 3L0, Вы писали:
МЗ>>Если это небольшая фирма — пожалуйста, у нас будет язык с 1C like синтаксисом (бесплатно). Не понравиться — напишет свой R3>Во первых, работать с вашим языком (даже 1С like) надо учится, чего не надо делать с 1С.
А что, язык 1С впитывается с молоком матери? Я язык 1С усвоил буквально за 30 мин. Я просто не понял, тогда что, по вашему надо брать за основу язык 1С? Во первых он убогий, нет объектной абстракции, а как эту абстракцию прикручивали сторонние люди я вообще молчу.
R3>Во вторых, я нашим 1С-никам кидал шутку: Перед прочтением взвести таймер
Здравствуйте, Denis_TST, Вы писали:
D_T>Здравствуйте, Максим Зелински, Вы писали:
G>>>Короче, если нужен полноценный скриптинг во всех позах, Java — лучший выбор, чем .NET. Почему так: МЗ>>Мы к Java приценивались, но пришлось отказаться, так как там нет "атрибутов", которые очень нам нужны. D_T>как это нет ??? а в JDK1.5 ??
Не уж то замыленный глаз проглядел (просто явовщиков у нас нет, вот сишников и шарповцов навалом )? Щас понесусь смотреть!
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Максим Зелински, Вы писали:
МЗ>>>>Если ему дать хороший фреймворк, с хорошей документацией и с примерами, то почему он не сможет? Во всяком случаи он может "купить" какой-нибудь встроенный язык G>>>Он просто не захочет тратить на это свое время. С какой стати? Ему нужен один единственный язык, с хорошей заточкой под предметную область. МЗ>>Не захочет?, не надо! Берет и качает "бесплатный" Только вот проблема, если язык у системы один и вшит намертво, как быть с "хорошей заточкой под предметную область"? G>Этот единственный язык должен ее иметь. Вот и вся проблема.
Может мы думаем по разному? Как может вшитый в систему язык охватывать предметную область всех "внедренцев"? G>Не захочет — ничего качать не будет. Обратится к другому производителю. С какой стати трахаться с вашим фреймворком, что-то качать, докручивать, доделывать, если ваши конкуренты все сделали по уму — так, что этим заниматься не надо?
Ничего "докручивать" и "доделывать" не надо будет, только "качать" или расширять (если надо). Вы смешиваете понятие "гибкости" и "траха". "Гибкая" система != "корявая" система.
МЗ>>Хм. Вообще есть два типа конторок "внедренцев" (да простят меня их представители): лавочки, которые берут какой-нибудь ТР и просто устанавливают на все компьютеры клиента (короче, не дальше инсталла и создания конфигураций пользователей). Да, им всякие навороты не нужны. А есть и более серьезные конторы: которые пишут эти самые ТР. Вот им то и понравиться наш "зоопарк", так как они могут написать "свой" язык, который в точности отражает предметную область (то есть максимально под нёё заточен). Если хотят быть просто разработчиками ТП, и не заморачиваться с языками (я признаю, тут конечно нужны специалисты для создания хорошего языка), могут заказать такой язык у другого разработчика (разделение производства, аутсортинг) или воспользоваться "стандартным" бесплатным. Мы просто не привязываем всех к нашему "стандартному" языку, если у внедренца есть желания написать свой язык предметной области, мы его поможем, предоставив удобные функции замены стандартного. G>Вы вылетите в трубу к чертовой матери с таким подходом к внедренцам. Я за вас, ей богу, переживаю. Объясните мне как внедренцу. С какой стати я буду заказывать свой язык для вашего фреймворка (недецким образом умножая проектные риски, и тратя бабло непонятно на что), если у вашего конкурента я смогу взять все то, что мне надо — дешевле?
Надеюсь, "заказ" языка вы рассматриваете как вариант? "С какой стати" — это зависит от сценария. Поверьте, есть ситуации (это проявляется на огромных проектах), когда лучше разработать такой язык, который наиболее точно отражает предметную область, и потом уже на нём писать ТР. Пример: язык для бизнес правил, язык для деловых процессов.
G>Да, это мне обойдется дешевле, так как нормальный язык со средой и фреймворком будет растиражирован вашим конкурентом, а не сделан персонально под меня. Это влияет на стоимость моего решения, понимаете?
Опять таки: разработка своего языка — это всего лишь один из вариантов! Вы можете не "трахаться", а скачать бесплатный (ну хорошо, представьте, что он идет в поставке с системой) язык.
G>Для нескольких десятков рабочих мест я лучше выберу 1С — мне это сократит сроки разработки вдвое без всякой трахотни со своими языками. В конце концов, чем писать свой язык и разбираться в вашем фреймворке, дешевле запрограммить все на VB под MS SQL.
Берем и пользуемся стандартным языком (походит на 1С но с объектами). G>Подумайте об этом — в том, что 1С держит 98% рынка есть не только маркетинговые, но и технологические причины.
Не хочу перекатываться в флейм из-за "технологических" причин лидерства 1С. Имхо, это не так.
G>>>При этом сами предпочитаете писать на одном-единственном C#, а не на зоопарке. МЗ>>Это "шпилька"? Боже упаси, если придется что-то дописывать на С++. G>Это констатация факта. Вам, почему-то, так проще. И мне тоже. и все остальным.
Я не понимаю, хотите писать на предметном языке, пишите только на нём, вам не надо будет знать C# или фреймворк .Net. Да, так проще, и наша система это поддерживает.
G>>>А ваш пользователь должен будет: МЗ>>Пользователь? Вы наверное имели ввиду "внедренца" или разработчика ТР? G>Внедренца, конечно. Респект за конструктивную позицию — другие бы с говном съели.
G>>>1) Знать С#, чтобы разбираться в ваших типовых решениях — вы их собрались писать на С#. МЗ>>Если он захочет на нём писать. Мы же не связываем ему руки? G>Связываете, в том все и дело. Вы типовухи собрались писать на C# — тьем самым вы вынуждаете внедренца знать C#, чтобы разбираться в них и адаптировать ваши типовухи.
Ааа, теперь понятно. Да, тут конечно проблема, ТР могут быть написаны на разных языках, это конечно усложняет адаптацию. Хотя, если языки сделаны под предметную область ТР — это нивелирует недостатки "зоопарка", а на больших ТР это выливается в плюсы. Что же касается C# и наших типовух. Мы будем их писать на первых порах, чтобы систему проверить, и внедрять будем мы сами. ТР от сторонних производителей наверное будут на стандартном языке. Конечно для внедренцов, которым попадется решение на C#, придётся попотеть. Да это проблема, я её признаю.
G>>>2) Знать (зачем-то) отдельный язык, на котором вы хотите, чтобы он писал бизнес логику. МЗ>>Вы наверное меня не правильно поняли. Хочешь писать на С# — пиши только на нём. Хочешь писать на языке с 1C like синтаксисом — пиши на нём и только, тогда система будет просто напоминать "расширенную" 1С 8.0 или Axapta, знание C# в последнем случае не нужно. G>Понял прекрасно. Знать C# надо будет обязательно, так как ваши типовые решения будут написаны на нем, это вы понимаете? Все, вы уже подняли порог профессионализма для внедренца. Добавления всех остальных — более простых языков — не помогут.
Вы наверное не правильно поняли ситуацию с "нашими" ТР на C# (наверное, я сам виноват, что раньше это не написал). Мы будем писать ТР только на первых порах и только на C# для тестирования фреймворка. Дальше мы передадим эстафету сторонним разработчикам, которые, скорее всего, будут писать "настоящие" ТР на стандартном или каком другом языке.
G>>>А если ему все это не понравится (а мне, как бывшему внедренцу, это уже сильно не нравится. Уверен, что не понравится и другим), вы предлагаете ему создать до кучи третий, свой собственный язык. Смотрите, вам виднее. МЗ>>Кстати, мне очень важны ваши замечания раз вы бывший внедренец. МЗ>>Детально расписываю, какой есть выбор у разработчика ТР (подпольная кличка "внедренец"): МЗ>>[list=1] МЗ>>Он может писать ТР на любом языке .Net платформы. МЗ>>Этот выбор "максимально" производителен (всё же есть такие ТР, где нужна повешенная производительность, согласитесь, с интерпретируемыми языками это сложно). Мы предоставляем удобный фреймворк для такого решения. G>Вы уже расчитываете на "внедренца", знакомого с платформой .net. Сильно сужаете рынок, ИМХО. Большинство .NET программеров напишет все с нуля, им ваш фреймворк не нужен.
Ну это вариант. "Большинство" вряд ли хочет открыто работать с транзакциями, версионностью, отображениями данных на бд, да много с чем.
МЗ>>Он может "купить" или "заказать" язык предметной области. МЗ>>Хотите не заморачиваться с C# языком? Пожалуйста, вот вам бесплатный типизированный язык с высокой абстракцией. МЗ>>Хотите расширяемости своего ТР конечными "внедренцами"? Закажите язык, который наиболее полно будет подходить для вашей предметной области. G>Этого вообще никогда никто делать не будет. Причины я озвучил.
Я их понял.
МЗ>>Комбинация всего этого. G>Сомнительно. Хотите проверить реальность ваших планов? Придумайте success story, где все это реально имеет значение.
У нас есть база для обкатки: большое рекламное агентство (там больше 100+ клиентов). Обкатаем, напишем.
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Вот типовой объект на C# МЗ><skipped>...
Все это хорошо, пока пока концептуальные понятия в C# похожи на понятия вашей предметной области.
А вот, например запрос на SQL (или другом языке запросов) также красиво вы не напишете, и тем более синтаксис его во время компиляции не проверите, а значит и не сможете поставить правильно зависимости между объектами конфигурации (т.е. при изменении таблицы или справочника у вас не произойдет автоматической перекомпиляции модуля программы, в которой из этого справочника делается запрос).
А можно было-бы сделать примерно так:
void p()
{
int name = "Вася";
#oql x = select * from Firm.Customer c where c.Name == :name;
while (x.Next())
{
string name = x.Name;
//...
}
}
И безо всяких лишних объявлений или приведений типов. Все скомпилируется, проверится. Красиво и удобно. Подсветку синтаксиса самого запроса можно организовать и т.д.
Другой пример:
Песть у нас имеются следующие бизнес объекты: Department и Customer. Customer работает в одном из Department. То есть существет связь один ко многим.
Связь, с точки зрения прикладного программиста, это следующее:
— она двухстороняя, т.е. навигация от обоих объектов
— если мы изменяем связь при помощи методов одного из объектов, то изменения сами собой видны и в другом
Если говорить про удобства, то оба этих пункта система должна делать автоматически.
Так объявляем:
persistent class Customer
{
public persistent string Name // Это хранимое свойство, с переопределяемым set.
{
set {
if (value == "aaa")
throw new InvalidNameException();
_name = value;
}
}
public persistent string Address;
}
persistent class Department
{
public manytoone Customer Children inverse Parent;
}
Так используем:
void p()
{
Department d = GetSome();
Department d2 = GetSome2();
Customer.List children = d.Children; // Мы не объявляли типа Customer.List
// Он объявляется автоматически.
Customer cust = children[0]; // Мы не приводим от Object к Customer,
// т.к. Customer.List и так работает с
// типом Customer.
/* И самое веселое */
cust.Parent = d2; // Мы не объявляли свойства Parent в классе Customer,
// но оно видно, если видно объявление класса Department.
// Более того, если Customer и Department находятся в разных
// ассемблях (модулях компиляции), то зависимость есть только
// от Department к Customer, но не наоборот.
}
Ну и как вы все это (а реально и многое другое) сделаете на C# без очень сложного препроцессора.
Здравствуйте, stalcer, Вы писали:
S>А вот, например запрос на SQL (или другом языке запросов) также красиво вы не напишете, и тем более синтаксис его во время компиляции не проверите,
Мы используем что-то вроде паттерна "интерпретатор". Щас запрошу у наших программистов пример написания. Вроде там все типобезопастно.
S>а значит и не сможете поставить правильно зависимости между объектами конфигурации (т.е. при изменении таблицы или справочника у вас не произойдет автоматической перекомпиляции модуля программы, в которой из этого справочника делается запрос).
У нас используется отображения данных с/на БД. При изменении таблицы иди справочника никаких перекомпиляций/изменений кода не надо.
<skip> S>Если говорить про удобства, то оба этих пункта система должна делать автоматически.
Всё это у нас строится автоматически (и свойства добавляются для двунаправленной связи).
S>Ну и как вы все это (а реально и многое другое) сделаете на C# без очень сложного препроцессора.
Единственное, что невозможно переварить, это
#oql x = select * from Firm.Customer c where c.Name == :name;
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Мы используем что-то вроде паттерна "интерпретатор". Щас запрошу у наших программистов пример написания. Вроде там все типобезопастно.
Жду.
МЗ>Всё это у нас строится автоматически (и свойства добавляются для двунаправленной связи).
Про двунаправленные связи можно подробнее?
Как добавляется обратное свойство, как добавляется поле для хранения значения обратного свойства?
И в целом когда вы делаете преобразование байт-кода, в момент компиляции, в момент загрузки в run-time или еще когда?
И КАК после добавления обратного свойства у вас не получается циклических зависимостей между ассемблями.
А можно пример кода объявления объектов с двунаправленной ассоциацией?
Общаясь с 1С более 8 лет, и немного зная об организации хранения данных и построения своей объектной надстройки над БД http://1c.proclub.ru/modules/mydownloads/personal.php?cid=115&lid=2019
хотелбы иметь поддержку в языках
1. Поддержка метакласоов, т.к. нужна наследуемая и перекрываемая информация о класса,в том числе и с быстрым доступом из экземпляра класса. Type не дает специфической информации, а атрибуты так или иначе придется кэшировать и доступ к ним не тривиален.
Подобное есть в Delphi.Net
Так или иначе придется создавать свою иерархию классов с продуманным базовым, от которого и плясать.
2. Наряду со статической типизацией, обязательно нужно и позднее связывание (динамическая типизация). Т.к.
будет достаточно полей с неопределенным типом (никуда от них не деться). В том числе и при обработке произвольных запросов.
Все это в принципе возможно расширяя существующие, но в том виде, что они представляют на данный момент, они до этих требований не дотягивают.
Опять же это только мое видение.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, stalcer, Вы писали:
МЗ>>Мы используем что-то вроде паттерна "интерпретатор". Щас запрошу у наших программистов пример написания. Вроде там все типобезопастно. S>Жду.
Нет, оказывается не типобезопастно
Вульгарно так:
Ваш код:
select * from Firm.Customer c where c.Name == :name;
Что у нас.
Это если через классы:
string Vasyja = "Вася"
Customer customer = Customer.FindByField("Name", Vasyja);
Это если через хранилище:
string Vasyja = "Вася"
QueryObject query = new QueryObject(Customer);
query.AddCriteria(new EqualField("Name", Vasyja);
Конечно в вашем случаи всё красиво.
МЗ>>Всё это у нас строится автоматически (и свойства добавляются для двунаправленной связи). S>Про двунаправленные связи можно подробнее? S>Как добавляется обратное свойство, как добавляется поле для хранения значения обратного свойства?
Методом вставки IL'а в сборку. S>И в целом когда вы делаете преобразование байт-кода, в момент компиляции, в момент загрузки в run-time или еще когда?
Байт код можно втравливать отдельной программой (соответственно интегрируется в IDE), либо сбоку положить в папку системы, тогда она сама её подхватит и проапргрейдит. S>И КАК после добавления обратного свойства у вас не получается циклических зависимостей между ассемблями.
Вот получилось. К сожалению, все празднуют "старый новый год" (как говорится, дай бог день, а мы праздник мы придумаем). Дополнительная информация не раньше завтра S>А можно пример кода объявления объектов с двунаправленной ассоциацией?
Если только потерпите до завтра. У меня нет точного синтаксиса определения.
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Вульгарно так: МЗ>
МЗ>Ваш код:
МЗ>select * from Firm.Customer c where c.Name == :name;
МЗ>Что у нас.
МЗ>Это если через классы:
МЗ>string Vasyja = "Вася"
МЗ>Customer customer = Customer.FindByField("Name", Vasyja);
МЗ>Это если через хранилище:
МЗ>string Vasyja = "Вася"
МЗ>QueryObject query = new QueryObject(Customer);
МЗ>query.AddCriteria(new EqualField("Name", Vasyja);
МЗ>
МЗ>Конечно в вашем случаи всё красиво.
Понятно.
S>>И КАК после добавления обратного свойства у вас не получается циклических зависимостей между ассемблями. МЗ>Вот получилось.
Это по прежнему интересно.
МЗ>К сожалению, все празднуют "старый новый год" (как говорится, дай бог день, а мы праздник мы придумаем).
S>>А можно пример кода объявления объектов с двунаправленной ассоциацией? МЗ>Если только потерпите до завтра. У меня нет точного синтаксиса определения.
И это тоже.
И еще, какую степень свободы имеет программист при разработке конфигурации. Отслеживает ли система целостность конфигурации в режиме реального времени на протяжении всего процесса разработки и использования её. Ну как 1С или Oracle (то есть фиг вы удалите таблицу, если на нее есть внешний ключ).
И производятся ли все манипуляции с конфигурацией через ваше IDE (например, создание таблиц в бд, их последующее изменение при изменении структуры бизнес объектов) с соблюдением всех ограничений опять же в режиме реального времени.
Разрешает ли система подгрузить в run-time сборку с объявленными бизнес объектами, если реальная структура бд не соответствует изменным объявлениям бизнес объектов.
И т.п.
МЗ>>Ваш код:
МЗ>>select * from Firm.Customer c where c.Name == :name;
МЗ>>Что у нас.
МЗ>>Это если через классы:
МЗ>>string Vasyja = "Вася"
МЗ>>Customer customer = Customer.FindByField("Name", Vasyja);
МЗ>>Это если через хранилище:
МЗ>>string Vasyja = "Вася"
МЗ>>QueryObject query = new QueryObject(Customer);
МЗ>>query.AddCriteria(new EqualField("Name", Vasyja);
МЗ>>
МЗ>>Конечно в вашем случаи всё красиво. S>Понятно.
Кстати, самое смешное, что и в языке 1С запрос не проверяется на стадии компиляции
МЗ>>Вот получилось. S>Это по прежнему интересно.
Я не могу всё расписать, так как я не занимался объектным отображением (да вообще, я не кодил систему, я её разрабатывал), как только ключевые специалисты отрезвеют или хотя бы начнут подходит к телефонам я всё напишу
МЗ>>Если только потерпите до завтра. У меня нет точного синтаксиса определения. S>И это тоже.
Обязательно.
S>И еще, какую степень свободы имеет программист при разработке конфигурации. Отслеживает ли система целостность конфигурации в режиме реального времени на протяжении всего процесса разработки и использования её. Ну как 1С или Oracle (то есть фиг вы удалите таблицу, если на нее есть внешний ключ).
В планах у нас add-in'ы для VS.Net IDE (да и для других .Net IDE, таких как C#Builder), которые будут помогать писать код (это для C# конфигураций). Для языков предметной области мы буде сами писать IDE. Так что ответ, да, отслеживает. Можно конечно работать и без IDE (что мы и делаем в текущий момент), тогда ничего не отслеживается в реальном времени (отслеживание возникает, когда система запускается с конфигурацией). S>И производятся ли все манипуляции с конфигурацией через ваше IDE (например, создание таблиц в бд, их последующее изменение при изменении структуры бизнес объектов) с соблюдением всех ограничений опять же в режиме реального времени.
Да. S>Разрешает ли система подгрузить в run-time сборку с объявленными бизнес объектами, если реальная структура бд не соответствует изменным объявлениям бизнес объектов.
Есть несколько вариантов: Объект был зарегистрирован в общей схеме БО, но изменился (подправили структуру без лишних телодвижений).
Тогда если существуют старые сохраненные записи БО в базе, то система работает со старой версией (если те старые объекты где-нибудь используются). Новые экземпляры используют новую версию БО.
Объект был зарегистрирован в общей схеме БО, но изменился (разработчик написал сценарий миграции).
В данном случаи все старые объекты пропускаются через сценарий и полностью заменяются новыми версиями.
Объект должен быть отображен на существующие таблицы.
Разработчик пишет функции отображения.S>И т.п.
Задавайте вопросы, буду отвечать, и ждать критики
Здравствуйте, Максим Зелински, Вы писали:
МЗ>А что, язык 1С впитывается с молоком матери? Я язык 1С усвоил буквально за 30 мин. Я просто не понял, тогда что, по вашему надо брать за основу язык 1С? Во первых он убогий, нет объектной абстракции, а как эту абстракцию прикручивали сторонние люди я вообще молчу.
Он не убогий, а простой. В мире существует много языков, которые не имеют объектной абстракции, и ничего.
Во вторых, благодаря динамической типизации реальной необходимости в отдельной "объектной абстракции" для этого языка нет. "Подклассы" и "общие базовые классы" документов и справочников реализуются глобальными функциями, получающие аргументом контекст бизнес-объекта (парадокс. объектной абстракции нет, а контекст, или "this" у объектов есть). Что, вообще-то, не только не проигрывает, но и, в руках понимающего человека, превосходит по гибкости наследование.
Также, это существенно понижает порог необходимых знаний и умений для начинающих — это огромный плюс языка, сделано специально. Язык и среда специально спроектированы так, чтобы с этим мог разобраться бухгалтер. И разбираются — многие внедренческие фирмы предпочитают набирать людей с экономическим образованием и обучать их программированию. И не надо кривить рожу, в работе внедренца знание и понимание предметной области как минимум на столько же важно, как и программерские навыки.
Единственное, что портит язык 1С — это непродуманная модульная система. Достаточно явно ввести понятие свободного модуля, и "виртуального" модуля (у которого есть Контекст и экземпляры) — и будет вообще песня. А классы там нафиг не нужны.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Максим Зелински, Вы писали:
МЗ>>А что, язык 1С впитывается с молоком матери? Я язык 1С усвоил буквально за 30 мин. Я просто не понял, тогда что, по вашему надо брать за основу язык 1С? Во первых он убогий, нет объектной абстракции, а как эту абстракцию прикручивали сторонние люди я вообще молчу.
Суть не в языке. И поверь мне кто утвердждает что за 30 минуут понял всю суть 1С, я отнесусь с огромным скептицизмом. Не понимания сути (структуры бд, свяхей итд) нельзя говорить об абсолютном.
G>Он не убогий, а простой. В мире существует много языков, которые не имеют объектной абстракции, и ничего. G>Во вторых, благодаря динамической типизации реальной необходимости в отдельной "объектной абстракции" для этого языка нет. "Подклассы" и "общие базовые классы" документов и справочников реализуются глобальными функциями, получающие аргументом контекст бизнес-объекта (парадокс. объектной абстракции нет, а контекст, или "this" у объектов есть). Что, вообще-то, не только не проигрывает, но и, в руках понимающего человека, превосходит по гибкости наследование.
G>Также, это существенно понижает порог необходимых знаний и умений для начинающих — это огромный плюс языка, сделано специально. Язык и среда специально спроектированы так, чтобы с этим мог разобраться бухгалтер. И разбираются — многие внедренческие фирмы предпочитают набирать людей с экономическим образованием и обучать их программированию. И не надо кривить рожу, в работе внедренца знание и понимание предметной области как минимум на столько же важно, как и программерские навыки.
Вот здесь я с Gaperton абсолютно не согласен. Грамотному человеку гораздо легче разобраться с некой предметной областью, чем буху с программированием (правда есть такие индивидумы, но поверь мне от них нужно держаться поодаль).
G>Единственное, что портит язык 1С — это непродуманная модульная система. Достаточно явно ввести понятие свободного модуля, и "виртуального" модуля (у которого есть Контекст и экземпляры) — и будет вообще песня. А классы там нафиг не нужны.
Кому как. Может я зажравшийся 1С ник. Но к сожалению популярность и отсутствие должной квалификации у большинства 1С ников подтверждают твои слова. Возможно ты прв на все 100. Но от этого легче не становится
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, Максим Зелински, Вы писали:
МЗ>>>А что, язык 1С впитывается с молоком матери? Я язык 1С усвоил буквально за 30 мин. Я просто не понял, тогда что, по вашему надо брать за основу язык 1С? Во первых он убогий, нет объектной абстракции, а как эту абстракцию прикручивали сторонние люди я вообще молчу. S>Суть не в языке. И поверь мне кто утвердждает что за 30 минуут понял всю суть 1С, я отнесусь с огромным скептицизмом. Не понимания сути (структуры бд, свяхей итд) нельзя говорить об абсолютном.
Согласен совершенно.
G>>Также, это существенно понижает порог необходимых знаний и умений для начинающих — это огромный плюс языка, сделано специально. Язык и среда специально спроектированы так, чтобы с этим мог разобраться бухгалтер. И разбираются — многие внедренческие фирмы предпочитают набирать людей с экономическим образованием и обучать их программированию. И не надо кривить рожу, в работе внедренца знание и понимание предметной области как минимум на столько же важно, как и программерские навыки.
S> Вот здесь я с Gaperton абсолютно не согласен. Грамотному человеку гораздо легче разобраться с некой предметной областью, чем буху с программированием (правда есть такие индивидумы, но поверь мне от них нужно держаться поодаль).
Не вижу повода верить, так как сам в этом бизнесе работал, и встречал весьма способных бухов с программированием. Как и совершенно деревянных программеров с бухгалтерией. "Бух" тоже может быть умницей и грамотным человеком — ему в каком-то смысле проще — он, в отличии от тупого программера, не уверен в своем превосходстве и исключительности априори.
И здесь я сказал только факты — я знаю, что 1С всегда разрабатывался с закладкой на обучение бухгалетеров настройке (говорил об этом с младшим Нуралиевым — Сергеем лично), и я знаю точно, что по крайней мере Контимекс (торговая марка "Все Для Главбуха", если слышали о них — был знаком с их директором лично, ребята умницы) набирал аудиторов и бухгалтеров и делал из них спецов по внедрению. Они считали, что так лучше, а эти парни знают, что делают. Они затеяли продавать настроенную систему в дополнение к консалтинговым и аудиторским услугам. Профессиональные программеры у них, естественно, тоже были.
G>>Единственное, что портит язык 1С — это непродуманная модульная система. Достаточно явно ввести понятие свободного модуля, и "виртуального" модуля (у которого есть Контекст и экземпляры) — и будет вообще песня. А классы там нафиг не нужны. S> Кому как. Может я зажравшийся 1С ник. Но к сожалению популярность и отсутствие должной квалификации у большинства 1С ников подтверждают твои слова. Возможно ты прв на все 100. Но от этого легче не становится
Да не перживай ты так . "Виртуальные" модули совершенно эквивалентны по выразимтельной силе ООП — как врач тебе говорю. Просто не вводится лишнее понятие, и все .
"Глобальные переменные" модуля будут переменными класса. "Экземпляр модуля"(класса) создается, например, через СоздатьОбъект. К нему через точку вызываются определенные там функции. "Глобальные переменные" доступны как члены контекста через точку. И все дела. Теперь добавляешь только ключевое слово extends (расширить существующий модуль) — и вот тебе наследование.
Чем это лучше классов? Тем, что документы, элементы справочников — уже сейчас фактически являются "виртуальными" модулями. "Отчет" — это модуль с визуальной формой. Надо добавить "свободный" модуль без формы (что делается на халяву) — и вуаля. Не усложняя языка ты получаешь свое ООП, спокойно обходясь без понятия класса.
Здравствуйте, Gaperton, Вы писали: G>Не вижу повода верить, так как сам в этом бизнесе работал, и встречал весьма способных бухов с программированием. Как и совершенно деревянных программеров с бухгалтерией. "Бух" тоже может быть умницей и грамотным человеком — ему в каком-то смысле проще — он, в отличии от тупого программера, не уверен в своем превосходстве и исключительности априори.
G>И здесь я сказал только факты — я знаю, что 1С всегда разрабатывался с закладкой на обучение бухгалетеров настройке (говорил об этом с младшим Нуралиевым — Сергеем лично), и я знаю точно, что по крайней мере Контимекс (торговая марка "Все Для Главбуха", если слышали о них — был знаком с их директором лично, ребята умницы) набирал аудиторов и бухгалтеров и делал из них спецов по внедрению. Они считали, что так лучше, а эти парни знают, что делают. Они затеяли продавать настроенную систему в дополнение к консалтинговым и аудиторским услугам. Профессиональные программеры у них, естественно, тоже были.
Всегда считал и считаю программирование как инструмент для достижения некой цели. Поэтому любому буху нужно владеть программирование как и математическим аппаратом. Другое дело, что в основной массе бухи женщины (причем не всегда с высшим образованием) и иногда им самим приходится разъяснять принципы бухгалтерии.
Вот когда была 6 ка там бухпм, что то делать было проще. G>>>Единственное, что портит язык 1С — это непродуманная модульная система. Достаточно явно ввести понятие свободного модуля, и "виртуального" модуля (у которого есть Контекст и экземпляры) — и будет вообще песня. А классы там нафиг не нужны. S>> Кому как. Может я зажравшийся 1С ник. Но к сожалению популярность и отсутствие должной квалификации у большинства 1С ников подтверждают твои слова. Возможно ты прв на все 100. Но от этого легче не становится G>Да не перживай ты так . "Виртуальные" модули совершенно эквивалентны по выразимтельной силе ООП — как врач тебе говорю. Просто не вводится лишнее понятие, и все .
G>"Глобальные переменные" модуля будут переменными класса. "Экземпляр модуля"(класса) создается, например, через СоздатьОбъект. К нему через точку вызываются определенные там функции. "Глобальные переменные" доступны как члены контекста через точку. И все дела. Теперь добавляешь только ключевое слово extends (расширить существующий модуль) — и вот тебе наследование.
G>Чем это лучше классов? Тем, что документы, элементы справочников — уже сейчас фактически являются "виртуальными" модулями. "Отчет" — это модуль с визуальной формой. Надо добавить "свободный" модуль без формы (что делается на халяву) — и вуаля. Не усложняя языка ты получаешь свое ООП, спокойно обходясь без понятия класса.
В этом плане я с тобой полность согласен. И это достаточно удобно. В принципе язык 1С меня полностью устраивает.
Просто у него есть недостатки
1. Из- за отсутствия типизации отсутствует подсказа через току (интелсиленсе или как его)
2. Из — за отсутсвия типизации ошибка может выявиться через несколь лет.
3. Скорость.
Хотелось бы иметь такой язык, что бы совмешал в сете как статическую типизацию так и позднее связывание.
Вот смотрю я на питон и облизываюсь. А как у него там со статической типизацией????
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Gaperton, Вы писали:
G>Далее, приятная новость осени прошлого года. Microsoft прекратил разработку продукта Visual Studio for Applications .NET. Продукта не будет. Всем сожалеющим об этом рекомендуется кастомизировать "взрослую" Visual Studio .NET.
И правильно.
G>2) Неиспользуемые классы удаляются GC (в дот нет вы можете выгрузить только домен целиком, обязаны делать это вручную, и это в некоторых случаях дает memory leak)
На самом деле нет никакой необходимости выгружать сборки. Замена кода операция нечастая, а сборки много места не занимают. Можно к примеру делать как в ASP.NET — грохать основной домен по достижению определенного количества загрузок.
G>3) Плюс к этому, написав свой ClassLoader, вы полностью контроллируете политику загрузки и выгрузки классов.
Да собственно и на .NET такое возможно. Есть событие AssemblyResolve, есть соответствующие интерфейсы с внешней стороны CLR Host.
.
, что пока будем использовать C# для логики, а потом прикрутим язык предметной области.
Только вот проблема, если язык у системы один и вшит намертво, как быть с "хорошей заточкой под предметную область"?
