Здравствуйте, Gaperton, Вы писали:
G>В базу вы упретесь, в базу и компоненты фреймворка. Как сделаете что-нибудь работающее, померяйте профайлером, сами увидите, если не верите.
Не буду спорить. Просто идея с возможностью реализации бизнес логики на C# (или любом .Net совместимом языке), нам показалась хорошей. Я же не отрицал, что поддержки встроенных языков не будет.
G>Теперь о том, что ИМХО важно на самом деле. Скорость языка для написания типовых решений не важна, важнее другое — нужна легкость поддержки (низкая цена внесения изменений), концептуальная простота языка (только необходимый минимум изобразительных возможностей), а также максимальная заточка языка с фреймворком под предметную область. Последнее самое важное — концептуальная пропасть между средствами языка/фреймворка и предметной областью должна по возможности отсутствовать.
Я вроде уже писал, что мы будем предоставлять фреймворк для создания таких языков. Я прекрасно это понимаю.
G>Напишете типовые решения на С# — тем самым не добьетесь ничего, кроме того, что существенно поднимете порог квалификации специалиста по внедрению и цену внедрения. Ведь предполагается, что в типовые решения могут вносится изменения, так?
Это зависит от политики "внедренца". Поддержка языков предметной области есть. Он может либо писать на C# (Basic.Net, любой .Net совместимый язык), либо использовать какой-нибудь язык предметной области (планируем их распространять отдельно), либо написать свой, если проект большой.
G>Это разумно. Но заметным образом на ваши продажи не повлияет, ИМХО — воспользуются этой возможностью единицы. Впрочем, я не знаю предполагаемую среднюю цену внедрения для вашей системы и описания предполагаемого клиента (с оценкой объема рынка). Это бы все прояснило.
Почему "единицы"? Я не очень понимаю, в чем плох подход с заменой встроенного языка? Разработчик подсистемы бизнес правил может написать свой язык, наподобие:
if( price > 1000 )
priceDrop = 0.1
а для предметной области использовать что-то наподобие X++? Наоборот, вариантов очень много, система становиться гораздо «гибче» при внедрении, чем завязывание на одном встроенном языке.
"Цена" внедрения для нашего софта будет меньше, чем у конкурентов это точно. Благодаря гибкости настроек, гибкости расширения и т.д.
Рынок: весь диапазон, от мала до велика. В конструкторе заложено очень сильное масштабирования для крупного бизнеса, но он тем не менее не такой "тяжелый" для понимания, для малого/среднего решение можно написать. В основном конечно ориентируемся на средний бизнес.
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Я же вроде писал , что пока будем использовать C# для логики, а потом прикрутим язык предметной области.
Извините не заметил.
МЗ>Вместо этого мы предоставим разработчикам фреймворк для подключения любого языка. Тем самым мы можем добавить хоть эмулятор языка 1C, хоть басика
1) Покажите мне прикладного разработчика (внедренца), который сможет подключить свой любимый язык в ваш фреймворк.
Я не знаю, но под нормальной системой-конструктор я понимаю хотя бы следующее:
— исходники прикладных программ хранятся на сервере в базе, так же как и остальные метаданные.
— откомпилированные программы (байт-код) хранятся там же и загружаются безо всяких временных файлов.
— отслеживаются зависимости между модулями (с автоматической перекомпиляцией зависимых модулей).
— есть возможность остановить выполнение программы в любой момент.
Ни один из известных мне языков/компиляторов не выполняет в достаточной степени эти требования.
Даже готовые скриптовые компоненты такого не поддерживают.
2) Я согласен с Gaperton про "концептуальную пропасть", потому что язык должен быть как можно более заточен под предметную область. Вот, например, для обычной системы управления предприятием необходимы:
— втроенные типы данных (и операции с ними), которые дают возможность работы с SQL NULL
— втроенные запросы, на уровне синтаксиса языка, а не как библиотека. Должны работать с объектами системы, а не напрямую с таблицами бд, так как:
— должна быть абстракция уровня данных, т.е. объекты предметной области и объявляться они должны достаточно просто, а не генерится тулзой в кучу непонятного кода (как, например, в Delphi ECO).
— и т.д.
3) Про скорость я так же согласен с Gaperton. Скорость байт-кодного интерпретатора более чем достаточна, тем более, что на встроенном языке будут выполняться только прикладные программы, а они работают с использованием системных сервисов, которые могут быть реализованы на более низкоуровневом языке.
4) Про наличие нескольких языков: это большое зло, ибо нефиг устраивать зоопарк. Наоборот нужно стремится к стандартизации средств, идей и концепций, и навязывать не столь квалифицированным прикладным разработчикам заранее продуманные решения.
Сами вначале мучались. Сначала хотели на Delphi, потом на встроееной в Oracle Java, потом на Java Script и т.д. Плюнули, вобщем, и потратили пол-года на свой язык.
Вот смотрю я на 1С. И вижу следующую ситуацию.
Несмотря на выпуск 8 ки основная масса сидит на 7.7 причем на связке дбф+ терминальные сессии.
Скорости хватает, конфигураций полно, да и тех возможностей языка вполне хватает.
С другой стороны должен подойти MBS.
Так или иначе все упрется в БД и конфигурации + цена разработки (или грамотно разработанные типовые но с достаточно простыми подгонкой под свои потребности, и смотря на эволюцию конфигураций 1С дело это не столь быстрое)
Гиблое это дело ИМХО, но нужное. В любом случае выбирать то особо не из чего Net (учитывая его развитие и применение в ОС и БД (ЮКОН)) или Ява опять же по этим причинам
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, 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) код.
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Здравствуйте, 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$ наводит на мысль выполнение всег кода на сервере.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Максим Зелински, Вы писали:
МЗ>>>Я же вроде писал , что пока будем использовать C# для логики, а потом прикрутим язык предметной области.
S>>1) Покажите мне прикладного разработчика (внедренца), который сможет подключить свой любимый язык в ваш фреймворк. МЗ>Если ему дать хороший фреймворк, с хорошей документацией и с примерами, то почему он не сможет? Во всяком случаи он может "купить" какой-нибудь встроенный язык
Он просто не захочет тратить на это свое время. С какой стати? Ему нужен один единственный язык, с хорошей заточкой под предметную область.
МЗ> Не понравиться — напишет свой
Ошибаетесь. Если вы ему такой язык не дадите, он просто обратится к другому производителю, который предоставит ему такой язык. Так же, как если ему вся ваша система не понравится, то он не начнет писать свою, а купит другую. Потому что писать языки и системы — это ваша работа, а не его, и он за это платит. Впрочем, бизнес расставит все по своим местам.
S>>Сами вначале мучались. Сначала хотели на Delphi, потом на встроееной в Oracle Java, потом на Java Script и т.д. Плюнули, вобщем, и потратили пол-года на свой язык. МЗ>У нас то же был такой опыт (стоит отметить, что проектная документация со всякими ТТ писалась больше года), мы прошли от полностью встроенного языка до концепции "зоопарка", как вы выразились.
При этом сами предпочитаете писать на одном-единственном C#, а не на зоопарке. А ваш пользователь должен будет:
1) Знать С#, чтобы разбираться в ваших типовых решениях — вы их собрались писать на С#.
2) Знать (зачем-то) отдельный язык, на котором вы хотите, чтобы он писал бизнес логику.
А если ему все это не понравится (а мне, как бывшему внедренцу, это уже сильно не нравится. Уверен, что не понравится и другим), вы предлагаете ему создать до кучи третий, свой собственный язык. Смотрите, вам виднее.
Здравствуйте, 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. Многие системы — не конструкторы. Рынок развивается, нужно выводить "принципиально" новые продукты.
Здравствуйте, Максим Зелински, Вы писали:
МЗ>>>Если ему дать хороший фреймворк, с хорошей документацией и с примерами, то почему он не сможет? Во всяком случаи он может "купить" какой-нибудь встроенный язык 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#, а бизнес правила на своём языке. МЗ>
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Если это небольшая фирма — пожалуйста, у нас будет язык с 1C like синтаксисом (бесплатно). Не понравиться — напишет свой
Во первых, работать с вашим языком (даже 1С like) надо учится, чего не надо делать с 1С.
Во вторых, я нашим 1С-никам кидал шутку: Перед прочтением взвести таймер
Здравствуйте, Serginio1, Вы писали:
S> Несмотря на выпуск 8 ки основная масса сидит на 7.7 причем на связке дбф+ терминальные сессии.
У нас народ сидит на 7.7 sql без терминала. Всё упирается в железо — не дают его. И так думаю не только у нас, но и у многих контор с урезанным бюджетом.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, AndrewVK, Вы писали:
AVK>>Ну навскидку Парус , Галактика, МС . Дальше ищи сам. Можешь поглядет на вакансии в форуме job.offers
L>+ Компас
О да..... Компас ЭТА КРУТА!!!
В прошлом году подходил к ним на выставке, что говорю вы можете о ней, что в нех крутого?
У нас все почти также хорошо как в 1С, но есть уникальная фича — программа конфигурирования показывает имена файлов для таблиц.
Чем это круче и какие это дает преимущества, так и не понял, как не старался выспроситью
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Вы о разработке системы или ТР?
Все что я писал — только о разработке конфигураций (не ядра), ножет и не только типовых.
МЗ>Если мы не сможем реализовать удобный фреймворк, то мы оставим только вариант с интерпретируемыми языками.
МЗ>Байт код естественно. Никаких препроцессоров кода!
Тогда и синтаксиса удобного не сможете сделать. Ну и не будете, как я понял.
И ваша стандартная конфигурация (вы ведь сами-то собираетесь писать ТП) будет нечитаемой.
МЗ>Многие системы разрабатывались в дремучие 90. Многие системы — не конструкторы. Рынок развивается, нужно выводить "принципиально" новые продукты.
Продукты и сейчас развиваются. Только проблемы несколько другие: повышение производительности (в основном не языка) или вот здесь
G>>Короче, если нужен полноценный скриптинг во всех позах, Java — лучший выбор, чем .NET. Почему так: МЗ>Мы к Java приценивались, но пришлось отказаться, так как там нет "атрибутов", которые очень нам нужны.
как это нет ??? а в JDK1.5 ??
, что пока будем использовать C# для логики, а потом прикрутим язык предметной области.
Только вот проблема, если язык у системы один и вшит намертво, как быть с "хорошей заточкой под предметную область"?
