Dissare mcureenab
2 Dissare, тебя самого какие прикладные направления интересуют? Наверняка в них есть задачи ждущие решения на ЭВМ.
Лично меня интересует разработка универсальных ERP-систем, гибких к потребностям конечного пользователя. Только не уверен, что это правильное направление деятельности. Вот и хотелось узнать, что об этом думают другие.

Нужен чисто объектный механизм конструктор , на основе абстракций предметной области : параметр с простой типизацией, документ (как структурный набор параметров) , запрос ( умеющий найти любой набор значений параметров) . Это позволит описать задачи управления "так как есть "-в логике (понимании) постановщика задач. Инструменты умеющие работать с такими обстракциями: конфигуратор ( строить) , клиент (запрашивать, считать, показывать), сервер (писать, хранить как есть, искать) . Средства общения с внешними программами - экспорт-импорт. Вкратце все.
И никаких реляционных приблуд и псевдообъектных усожнений.

GalantА вот никто не хочет разработать конструктор запросов к БД?
Не аналайзер скопировать, а сделать визуальный конструктор. Идеально было указать исходный набор данных и результирующий, а SQL-конструкцию он напишет сам :)

Вопчем, такой... продвинутый конструктор.

Можно.

BusyMan Dissare mcureenab
2 Dissare, тебя самого какие прикладные направления интересуют? Наверняка в них есть задачи ждущие решения на ЭВМ.
Лично меня интересует разработка универсальных ERP-систем, гибких к потребностям конечного пользователя. Только не уверен, что это правильное направление деятельности. Вот и хотелось узнать, что об этом думают другие. Да нормально... Только вот найди заказчика, который даст тебе пару лет на нем эксперименты ставить... А там - если гением окажешься, то и все получится ) Такие вещи можно только "на живом теле делать" )

2 года только блуждать, 1 год- понять 3 года релизовывать.

Shtockполностью согласен с "Проблема как раз в том что-бы решить любую задачу с помощью только одного ЯП, который был-бы одновременно и алгоритмическим, процедурным, функциональным и декларативным.", я бы правда ко всему этому добавил "легкий в освоении". Для меня сейчас важно,чтобы человек,посаженный за мою систему (причем 2 роли:специалист по 3d-моделированию и по предметной области) за неделю стал что-то настраивать/докручивать в базовой модели на этом языке,причем с учетом того что специалисты по предметной области не очень то любят все это программирование.

Интересная идея. А подробнее можно?

мод ShtockДля меня сейчас важно,чтобы человек,посаженный за мою систему за неделю стал что-то настраивать/докручивать в базовой модели на этом языке,причем с учетом того что специалисты по предметной области не очень то любят все это программирование.
Вот именно. Для этого в системе уже д.б. язык по этой предметной области (сконструированный из базового универсального ЯП). Тогда специалисто-предметников не надо учить ЯП, а только "их" языку.

Да, Да,Да.

iscrafm alkinНужен чисто объектный механизм конструктор , на основе абстракций предметной области : параметр с простой типизацией, документ (как структурный набор параметров) , запрос ( умеющий найти любой набор значений параметров) . Это позволит описать задачи управления "так как есть "-в логике (понимании) постановщика задач.
Инструменты умеющие работать с такими обстракциями: конфигуратор ( строить) , клиент (запрашивать, считать, показывать), сервер (писать, хранить как есть, искать) . Средства общения с внешними программами - экспорт-импорт. Вкратце все.
И никаких реляционных приблуд и псевдообъектных усожнений.
Иллюзии :)
В логике постановщика задач нужно быстро строить интерфейсы, взаимодействие с СУБД и модулей между собой. Абстракции из предметной области - утопия, к которой периодически все возвращаются, наживают гемморой, забывают... опять возвращаются... и по кругу в N-й раз.

А зачем нужно СУБД? Если хранить на сервере документ в той структуре какой он есть в природе и запрос делать зная эту структуру, то строить надо взаимодействие постановщика с сервером. Понятие Модульность уходит на уровень доступа к данным определенного типа документа , а если точнее к отчетам построенным на данных определенных постановщиком типов документов и т.п. Реально?

iscrafm alkinА зачем нужно СУБД? Если хранить на сервере документ в той структуре какой он есть в природе и запрос делать зная эту структуру, то строить надо взаимодействие постановщика с сервером. Понятие Модульность уходит на уровень доступа к данным определенного типа документа , а если точнее к отчетам построенным на данных определенных постановщиком типов документов и т.п. Реально?
Без базы не обойдетесь. Вы же о реальной системе. Много данных.

База будет одна. Та что хранится на сервере. Имею ввиду чисто объектный сервер. Документ записывается в него в той структуре какой есть в природе ( писал об этом ранее)., т.е. каждый параметр документа знает с какими параметрами соседствует в документе. Как думаете что это даст?

мод alkinИмею ввиду чисто объектный сервер. Документ записывается в него в той структуре какой есть в природе ( писал об этом ранее)., т.е. каждый параметр документа знает с какими параметрами соседствует в документе. Как думаете что это даст?
Что есть на сегодняшний день:
Объекты и документы описываются на некоем декларативном языке а-ля кобол и регистрируются в системе. В СУБД это хранится по EAV в фикс. таблицах.
На основе этого описания автоматич. генерируются меню, экранные и печатные формы. Для чтения данных есть стандартные view и функции, которые представляют понятия прикл. области. Можно писать свои.
Т.о проектировщик может не знать настоящей структуры таблиц БД. При этом все открыто.

Документ д.б. объектом. Язык должен обеспечивать описание документа в понятном для проектировщика (постановщика виде) например упрощенно:
Тип документа "Накладная" -
Шапка - Параметры : Номер, Дата, Организация, Покупатель ....
Таблица- Параметры :Товар, ед.изм, кол-во, сумма ...
Всё. Документ готов. Если проектировщик , знает , что именно так этот документ хранится, значит он знает как запросить с него данные. Это дает преимущества. Понятия (абстракции) предметной области становятся понятиями програмирования. Вьювер Да. Функции, что под ними подрузумевать?...

Гликоген авторАбстракции из предметной области - утопия

Ах, эта безапелляционность...
А как же документы, планы счетов, проводки, наконец, в 1С?

Вот вот и я о том же!

мод alkin
Все так и есть. Все документы образуют множество или список, доступ к которому и обесп. view (для поиска и фильтра).
Функции реализуют понятия прикл. области -
пример: остаток_на_счете(дата, счет)


Если я правильно понял схема - клиент-запрос-view-сервер ?

Alexey Kudinov alkinДокумент д.б. объектом. Где он должен быть объектом ? В базе ? На клиенте ? Где-то еще ? alkinЯзык должен обеспечивать описание документа в понятном для проектировщика (постановщика виде) Так проектировщика или постановщика ?
alkinЕсли проектировщик , знает , что именно так этот документ хранится, значит он знает как запросить с него данные. Зачем ему знать как он хранится ? alkinЭто дает преимущества Какие преимущества ? Для кого ? В сравнении с чем ? alkinПонятия (абстракции) предметной области становятся понятиями програмирования Какие понятия програмирования ? Что такое понятия програмирования ?
Объектом должен быть везде.
Проектировщик и постановщик должен быть в одном лице
Имею ввиду логическое представление хранения (физическое может отличаться)
Преимущества для проектировщика - 1 документ -1 объект , а не 1 документ- n- объектов ( таблица, база, регистр и т.п. кто как называет). Легче понимать и представлять.
Понятия имею ввиду терминология для проектировщика. Только параметр, документ, запрос + 2-3 шт и производные от них.

Думаю за этим будущее.