Здравствуйте, 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+ клиентов). Обкатаем, напишем.
Здравствуйте, Максим Зелински, Вы писали:
МЗ>А что, язык 1С впитывается с молоком матери?
Я про то, что это самый простой язык, но люди, его использующие на самом деле не настоящие программисты и => создать свой язык для них будет не простой задачей.
МЗ>Не открывается у меня
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Вот типовой объект на 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. Скорость.
Хотелось бы иметь такой язык, что бы совмешал в сете как статическую типизацию так и позднее связывание.
Вот смотрю я на питон и облизываюсь. А как у него там со статической типизацией????
и солнце б утром не вставало, когда бы не было меня
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 $ не столь существенна (если конецно не экономить на мониторе).
Подключение торгового оборудования тоже не проблема. (порты хорошо мапятся)
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, 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.