Надо использовать собственные "фреймворки" для собственных разработок"!

Частично навеяно вот этим - http://18delphi.blogspot.ru/2013/09/blog-post_16.html

Что я хочу сказать?

У меня есть "собственная разработка". Редактор текстов. Эверест называется. Крайне проприетарная система, которой пользуется ОЧЕНЬ ограниченный круг пользователей.

Но! Я стараюсь его использовать для своих "повседневных" нужд.

Ну там заявление на отпуск написать или ещё какой документ.

И я им - ПОЛЬЗУЮСЬ. ПРИНЦИПИАЛЬНО.

И если мне что-то НЕ НРАВИТСЯ или "неудобно в использовании" или "вдруг падает", то я сразу беру и ПРАВЛЮ ЭТО. Без всяких "тикетов" или задач. с полноценным тестированием. Ибо - "если у меня не работает", то как оно может работать у других?

Исходя из СВОИХ потребностей, как потребностей "обычного пользователя".

Что я хочу сказать?

Да одну ЭЛЕМЕНТАРНУЮ вещь. Было бы ЗДОРОВО, если бы ВСЕ производители, которые "продвигают" тот или иной фреймворк - САМИ бы его ИСПОЛЬЗОВАЛИ бы.

За примерами далеко ходить не надо.

Вот скажем - Microsoft - ПРОДВИГАЕТ (или продвигали) .NET - а много ли РЕАЛЬНЫХ коммерческих приложений у них построено на этой технологии?

Почему они до сих пор не опубликовали "примеры из жизни"? (Или я чего не знаю)

Или скажем Embarcdero - ПРОДВИГАЕТ FM. А почему среда IDE на нём до сих пор не базируется?

Или скажем IBM - "купила" Rational и RUP. А много ли собственных разработок они строят ИМЕННО на этих технологиях? Мне как "реальному программисту" - было бы интересно на это взглянуть. Хотя бы одним глазком... (Про то, что модель объектов Rational Rose - нарисована на UML - я знаю.. но это было ещё ДО IBM)

Или - пример из прошлого. Borland - продвигали ModelMaker - а почему бы им не было взять и нарисовать на нём ту же библиотеку VCL? Тут бы и "огрехи" реализации - сразу бы вылезли.

Или скажем - DUnit? ОФИГИТЕЛЬНАЯ идея. И неплохая реализация. И ХОРОШИ примеры тестов "взятые из головы". Но! Почему бы им не НАПИСАТЬ и не опубликовать набор тестов, который бы тестировал САМ DUnit? Ведь тут - СРАЗУ ВСЁ ПОНЯТНО. Люди - САМИ - потянутся. "назад к байтам", когда авторы фреймворка для тестирования публикуют тесты для тестирования этого фреймворка. Или я что-то упустил?

Или опять.. Embarcadero... Ну люблю я их.. что поделаешь.. Вот есть скажем DataSnap или скажем FireDAC. Ну почему не взять и не нарисовать модель классов в "рисовалке" Delphi-architect? Ну чтобы и САМИМ пользоваться и пользователям - "дать посмотреть".

Вот тот же Кнут - зачем TeX написал? Да затем, что "хотел написать книгу, а хороших инструментов - не было". (Потом кстати  говорят - "жалел о потраченном времени")

Пусть никто не сочтёт это НАЕЗДОМ...

Отнюдь - не наезд...

Просто - "мысли вслух"...

Если ТЫ ХОЧЕШЬ, чтобы кто-то пользовался твоими технологиями - САМ первый - ИСПОЛЬЗУЙ их...

P.S. когда-то у нас была купленная версия Delhi 1.0 "из коробки" и там была чудная "диаграмма" формата А3 - "дерево наследования классов библиотеки VCL". Почему бы Embarcadero не сделать чего-то подобного для новых версий VCL и FM? Тут готов немного "помочь" - у меня лично дерево наследования VCL и VGScene - давно нарисовано. Кому-то интересно?

P.P.S. http://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D1%81%D0%BA%D1%80%D1%83%D1%82%D0%BA%D0%B0_%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%82%D0%BE%D1%80%D0%B0

О собственных фреймворках

Когда-то. Давно. Мы силами нашей большой и дружной команды написали ОФИГЕННЫЙ (как нам тогда казалось) фреймворк для "конструирования" GUI-приложений. Скажем так "Office & IDE like".

Построенный на Delphi и VCL.

Называется VCM.

Вам не почудилось.. "Похоже" на MVC...

Именно. "Акроним" - взят оттуда. Да и разрабатывали мы свой фреймворк "с оглядкой на MVC".

Хотя мы тогда сами его не до конца понимали.

В итоге получилось "нечто" похожее на MVC, но в "своей интерпретации". И с гораздо большим количеством "слоёв ответственностей".

Что он позволяет?

А вот что:
- Описывать "модель данных", опирающуюся на объекты "БД".
- Описывать модель бизнес-объектов "областей ввода", опирающуюся на "модель данных".
- Описывать сущности (группы операций) и операции внутри них.
- Описывать "области ввода". Опирающиеся на "бизнес-объекты областей ввода" и сущности с их операциями. В терминах VCL - "формы". И РЕАЛИЗУЮЩИЕ "сущности" и "операции".
- Описывать бизнес-объекты "прецедентов. Опирающиеся на бизнес-объекты "областей ввода".
- Описывать "реализации прецедентов", опирающиеся на бизнес-объекты-прецедентов и "области ввода".
- Ещё несколько аспектов, которые "с кандачка" не опишешь.

Далее фреймворк позволяет конструировать приложения на основе уже описанных прецедентов.

Отдельно он строит "фабрики прецедентов", для создания экземпляров "реализаций прецедентов". А также "фабрики областей ввода", для создания "экземпляров областей ввода".

Кроме этого он позволяет в РЕАЛЬНОМ ВРЕМЕНИ строить командные меню, тулбары и контекстные меню. Для текущего экземпляра "реализации прецедента". Опираясь на описания сущностей и их операций.

Все отношения между указанными "элементами системы" описывались формальными правилами (предикатами - если хотите).

И всё было КРАЙНЕ ЗДОРОВО. Версия 1.0 фреймворка с точки зрения "реального программиста", живущего в "идеальном" мире - была - "ИДЕАЛЬНА". Она была - Perfert (если хотите).

И мы на этом фреймворке много чего сделали.

Но потом - "семейная лодка разбилась о быт".

О какой - спросите вы.

Да вот о какой - мы встретились с "реальными заказчиками" и "реальными дизайнерами".

И тут наши "ИДЕАЛЬНЫЕ" формальные правила полетели в тартарары.

Заказчики и дизайнеры - живут в ДРУГОМ мире. Они - "не понимают", да и "не хотят понимать" формальных правил "реальных программистов", живущих в "идеальном" мире.

Да и в общем-то - они - ПРАВЫ.

И началось - "а давайте тут красную ленточку.. а тут синюю кнопочку... а тут пункт меню убрать.. а тут пункт меню прибавить.. а тут сдвинуть на три пикселя..." И всё в таком духе....

И вся наша "идеальная" концепция - разлетелась как карточный домик.

И мы начали "кастомизировать" наш фреймворк. С точки зрения "реального программиста" из "идеального" мира - выглядело это "добавлением "костылей", а также "ниточек и верёвочек"". Ибо мы не поспевали за "реальным", а не "идеальным" миром.

И были версии фреймворка - 2.0 и 3.0. И они были - ОТНЮДЬ не "идеальны", с точки зрения "реального программиста", живущего в "идеальном мире".

Заказчикам и дизайнерам - НЕ НУЖНА, да и "непонятна" формальная логика предикатов. Они хотят - "красную ленточку и на три пикселя влево".. И - ИМЕЮТ ПРАВО!

Они живут в "реальном", а не "идеальном" мире. И именно они - ОТВЕТСТВЕННЫЕ за то, чтобы "продать" систему и "реальные программисты" - получили свою зарплату. Я нарочно утрирую.. Конечно...

К чему это я?

К ТОМУ, ЧТОБЫ НЕ ПИСАТЬ СОБСТВЕННЫХ ФРЕЙМВОРКОВ?

Нет КОНЕЧНО!

ПИСАТЬ!

Особенно если вы задумываетесь о "повторном использовании" уже "обкатанных" ПРОЕКТНЫХ РЕШЕНИЙ.

ПИСАТЬ!

Но!

Надо быть готовым к тому, что придёт "реальный заказчик" или дизайнер. И начнёт "ломать" всё вашу "идеальную схему".

И НЕ НАДО воспринимать это как "личную обиду" или "плевок в душу".

Мир "реальных программистов" и дизайнеров - ПО-ДРУГОМУ устроен. Они - ПО-ДРУГОМУ видят.

И имеют на это ПОЛНОЕ ПРАВО.

Особенно, если ОТВЕЧАЮТ за ПОСЛЕДСТВИЯ своих решений.

И ещё... Чем хорош "собственный фреймворк" в такой ситуации? Да ТЕМ, что вы можете - ЕГО ИЗМЕНИТЬ и ПОПРАВИТЬ. А чужой - вот уж дудки. Тут придётся сказать заказчикам - "архитектура - не позволяет сделать вашу "красную ленточку""...

Ну как-то  так...

P.S. Далее мы перешли к тому, что научились описывать понятия фреймворка и экземпляров его понятий на UML и это позволило "сглаживать многие углы". Но это - другая история.... Может быть я когда-нибудь расскажу...

P.P.S. Кстати в этой разработке мы использовали многие "новомодные" технологии. И "утиную" типизацию. И "открытые именованные списки параметров". И fluent-interface'ы. И "вызов метода по селектору". И от всех их отказались (точнее - "почти от всех"... "утиную" типизацию - например ПОКА - сохранили). "Почему-то".. Ну я то - знаю почему...

Коротенько. SizeOf в $IfDef

Оказывается не все знают.

В $If например можно написать так:

{$If SizeOf(ItemType) > 4}

Удобно. Для примесей и абстрактных контейнеров.

Немного полемики. Автор - не убедил

http://namerec.blogspot.ru/2013/09/dsl.html
http://namerec.blogspot.ru/2013/09/dsl-2.html
http://namerec.blogspot.ru/2013/09/dsl-3.html

Что сказать? Автор - МЕНЯ ЛИЧНО - не убедил. И тем БОЛЕЕ - не переубедил.

Что сказать? Мнение - имеет право на жизнь.

Мы все готовы признавать свои ошибки и даже ВЫПЯЧИВАТЬ их.

Что - ЗДОРОВО. И делает честь тем, кто это делает.

Но!

Начну с посыла:
"Как я сказал уже выше, разнообразие функциональности по работе со строками в Pascal было не очень большим, с PChar работать было вообще неудобно, если не сказать - опасно, ввиду чего работа с абзацами (тогда мы не использовали этот термин, вообще, система понятий была несколько иной, я вынужден подбирать нечто похожее из современного, чтобы не утомлять читателя) "заворачивалась" в классы-обёртки, но всё равно, возни с форматированием было намного больше, чем бы хотелось.
И мы были вынуждены экономить память. Жёстко, брутально."

-- мы ВСЕ были в такой ситуации в 90-х. И ничего...

Не смертельно.. Причём тут DSL - непонятно.. :-(

Ещё (если придираться) есть у меня ощущение, что автор - "плавает в датах". 90-й или 93-й или 95-й годы - это как говориться "depends". Там и разные инструменты были и подходы.

Там "год - за десять шёл".

Ну ладно.. Считайте, что я грубо и мелочно придираюсь к автору.. Потому, что он меня "задел".. Может и так...

Я готов признавать свою неправоту.

Но! "мотивации" - "почему не надо делать DSL" - я простите - не увидел.

ДА. Есть опыт unsuccesful-story. Не более того. У меня таких - "миллионы". Спросите меня и я вам расскажу.

Я сам - столько всего "по-молодости" "наколбасил".

Отклонюсь немного в сторону - «Императивщина всё равно функциональнее декларативных ЯП.»

БРАВО! Очевидность - возведённая в РАНГ истины.

Простите уж.

Никто не спорит, что "императив" - МОЩНЕЕ "декларатива". МОЩНЕЕ. И ВЫРАЗИТЕЛЬНЕЕ.

Точка. 

Но это совсем не означает, что "императив" - "лучше"и скажем - читабельнее. Вот совсем. Поверьте мне на слово.

У меня был коллега, который МНОГИЕ задачи решал в стиле "пробежаться по списку элементов и посчитать матожидание". И это - РАБОТАЕТ! Но я ВСЕГДА ему говорил в таких случаях - "опиши КАКУЮ ЗАДАЧУ решаем". Да! это - СЛОЖНЕЕ. На первом этапе. НО, потом - оно того стоит. Теперь - он "начальник". Не у нас. А я всё ещё - "кодер" :-) Но - наука -пошла впрок.

"Текучие интерфейсы" vs DSL - ну это моему разуму - НЕ ПОДДАЁТСЯ. Это - ОРТОГОНАЛЬНЫЕ вещи.

То, что у автора - "не получилось"... Ну так - "бывает".. Все через это проходили.

По сути...

FunFromField(tabBALANCE1, 'АктуальноС', fnMax, vDate);

-- вот тут мне кажется и кроется - ПРОБЛЕМА. Это по-сути "не DSL", да простит меня автор.

В том-то и ПРОБЛЕМА, что "пользователя" заставляли "программировать" в терминах "полей и таблиц". Не "описав предметной области" и не "повысив уровня абстракции".

Далее....

"Если Вы "нормальный программист" то Ваша реакция должна быть "Фу-у-у-у!" и Вы, совершенно понятно, точно знаете, как сделать в 100500 раз лучше.

Остальным мне хочется пожать руку, поскольку это - не просто работало, но закрывало очень существенную проблему. Больше возвращаться к этой теме не буду."

-- я - "нормальный" программист. Руку, мне жать - незачем. Именно - "фу"... Хотя - я понимаю - откуда и что берётся.

И "ругать" - я НИКОГО не хочу... Есть "естественный ход событий". И есть mile-stone'ы и прочая "дребедень"..

DSL - это "не просто" скриптовый язык. Иначе бы не было бы ДВУХ разных терминов.

"вот и всё, что я хотел сказать о креветках"

А автор - МОЛОДЕЦ. ОЧЕНЬ насущные проблемы поднял. DSL - "с кандачка" и "просто так" - не пишется.

Надеюсь, что я его не задел. Никоим образом - не хотел.

P.S. На "закуску"...

http://local.joelonsoftware.com/mediawiki/index.php/%D0%90_%D0%B2%D0%B0%D1%88_%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_%D1%82%D0%B0%D0%BA_%D0%BC%D0%BE%D0%B6%D0%B5%D1%82%3F

WORDWORKER И BOOLEAN IN aFirst

 // Двусторонний, а не обратный польский &&

 aFirst IF

  WordToWork DO IF

   true

  ELSE

   false

  ENDIF 

 ELSE

  false 

 ENDIF 

 //WordToWork DO &&

; // %&&

WORDWORKER ИЛИ BOOLEAN IN aFirst

 // Двусторонний, а не обратный польский ||

 aFirst IF

  true

 ELSE 

  WordToWork DO IF

   true

  ELSE

   false

  ENDIF  

 ENDIF 

 //WordToWork DO ||

; // %||

WORDWORKER НЕ

 // Правосторонний, а не обратный польский !

 WordToWork DO !

; // %!

WORDWORKER РАВНО

 // Правосторонний, а не обратный польский ==

 WordToWork DO ?==

; //%==

WORDWORKER НЕРАВНО

 // Правосторонний, а не обратный польский !=

 WordToWork DO ?!=

; //%!=

WordAlias "НЕ РАВНО" НЕРАВНО

WORDWORKER БОЛЬШЕ

 WordToWork DO >

;

WORDWORKER МЕНЬШЕ

 WordToWork DO <

;

WORDWORKER "БОЛЬШЕ ИЛИ РАВНО"

 WordToWork DO < !

;

WORDWORKER "МЕНЬШЕ ИЛИ РАВНО"

 WordToWork DO > !

;

WORDWORKER ЯВЛЯЕТСЯ OBJECT IN anObj

 WordToWork DO anObj pop:object:Inherits

;

WORDWORKER НЕЯВЛЯЕТСЯ OBJECT IN anObj

 WordToWork DO anObj pop:object:Inherits !

;

WordAlias "НЕ ЯВЛЯЕТСЯ" НЕЯВЛЯЕТСЯ

WORDWORKER =+ INTEGER IN anInc

 WordToWork DO anInc + =:^ WordToWork

;

WORDWORKER =- INTEGER IN anInc

 WordToWork DO anInc - =:^ WordToWork

;

WORDWORKER2 ПОКА

 @ ( WordToWork1 DO ) WHILE ( WordToWork2 DO )

;

WordAlias ДА true

WordAlias НЕТ false

....

: K397288098

 CONST N 150

 

 10 LOOP (

 "Список всех документов"

 "Перевести фокус в список"

 "Нажать {('Enter')}"

 N раз ( "Следующий документ в списке"

 "Дать системе перерисоваться" )

 N раз ( "Предыдущий документ в списке"

 "Дать системе перерисоваться" )

 ОМ

 "Список всех документов"

 "Перевести фокус в список"

 N раз "Стрелка вниз"

 "Нажать {('Enter')}"

 N раз ( "Предыдущий документ в списке"

 "Дать системе перерисоваться" )

 N раз ( "Следующий документ в списке"

 "Дать системе перерисоваться" ) )

;

K397288098

....

К чему это я? Да просто к тому, что идея - "управления из языка процессом компиляции" как это сделано в FORTH - по-моему - НЕЗАСЛУЖЕННО забыта.

А эта идея - позволяет "определять грамматику на лету". Только и всего.

А Python. Ну да - "неплохой" язык. Динамический. И с интересными "плюшками". И я - ЗНАЮ - как он устроен.

Всё та же "стековая машина" и "словари".

Что касается "батареек"  - ДА. Они там - МОЩНЫЕ. Сам как-нибудь - попробую использовать. Если задача подходящая возникнет.

P.P.S. Ну и ещё "о батарейках" - https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/DSL/Testing/GUI и https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/DSL/Testing

Чужая статья. "Куда приводят мечты" :-)

http://namerec.blogspot.ru/2013/09/dsl.html

С нетерпением жду продолжения.

Было... было...

http://namerec.blogspot.ru/2013/09/dsl.html?showComment=1378576097286#c5234050007570919327

А в 97-м был написан редактор Эверест. Но тут вышел Word 97 с вертикальным объединением ячеек таблиц. И на некоторое время "испортил карму".

Offtopic. Про комментарии в блогах...

Никогда не замечали?

Вот пишешь комментарий и "проецируешь уже ответ возможных корреспондентов".

Типа - "а он ТАК ответит, а ему ТАК отвечу, а он ТАК ответит, а я ему ТАК..."

Такие вот "шахматы по переписке".

Не замечали? А я - замечал. За собой. И стараюсь от этого избавляться...

"Где вы разместите правый фланг?"

"Слева!"

Чем-то напоминает программирование и написание ТЗ  :-)

Offtopic. О "необходимости обоснования СВОЕЙ позиции"

Друзья мои! Коллеги!

Хочу прояснить вот какой момент - "Я НИКОМУ и НИЧЕГО не собираюсь доказывать".

Я пишу не для того, чтобы ДОКАЗАТЬ или ПОКАЗАТЬ, что я "непризнанный гений".

Я СТАРАЮСЬ "поделиться" своими мыслями. И КОНЕЧНО хочу, чтобы они "кого-то тронули".

Скажете СПАСИБО - буду рад.

Но! ДОКАЗЫВАТЬ никому и ничего не хочу.

Доказывать можно руководству, коллегам, детям, маме, жене (хотя в двух последних случаях - далеко не всегда это надо делать). Но! НЕ "аудитории в интернете".

Я АПРИОРИ уверен в том, что то, что я пишу - может представлять "интерес" (ну за исключением некоторых "лирических отступлений").

Посему - я РАД дискуссиям, но уж пожалуйста не ждите, что я буду кому-то, что-то ДОКАЗЫВАТЬ.

Не согласны со мной? Написали об этом.. СПАСИБО вам! Я читаю и пытаюсь учитывать МНЕНИЯ ВСЕХ.

Но! Я - занятой человек, я КАЖДЫЙ день произвожу и складываю в CVS МНОЖЕСТВО строк кода.

И я с трудом НАХОЖУ время для ведения блога. Мне ВРЕМЕНИ (и моральных) не хватает НА ТО, что я "хотел бы написать".

Прошу иметь это в виду.

Зачем я это написал? Ну ЯВНО, не для того, чтобы кого-то "отчитать". Просто, чтобы вы понимали реалии.

Если я кому-то не отвечаю или "не привожу доводы", то это не значит, что я "ушёл от ответа".

Просто зачастую задаются такие вопросы на которые сложно ответить "двумя словами".

Хотите считать "моё молчание" признаком "своей правоты" - да ради бога.

Я НИКОМУ не навязываю своё мнение. Я старюсь ДЕЛИТЬСЯ. Какие выводы вы из этого сделаете - это уж всё на ваше усмотрение.

Хочется, чтобы вы ПРАВИЛЬНО меня поняли. СПАСИБО.

P.S. И ещё - я атеист и интернационалист. И в вопросах программирования - тоже. Про тот же Python - я ВНИМАТЕЛЬНО прочитал. И если я его критикую  - это не значит, что он мне "не понравился".

P.P.S. Ещё раз. Никого не хочу "отчитывать", а уж тем более - "пытаться воспитывать".

P.P.P.S. "Покритикуйте меня" - мне - НРАВИТСЯ, и я ГОТОВ признавать свои ошибки, а вот "поставьте меня в положение оправдывающегося" - НЕ НРАВИТСЯ. Эта грань - ТОНКА, Но постарайтесь её прочувствовать. И я не к тому, что "не надо писать комментарии". НАДО! Просто постарайтесь учитывать эту грань, когда читаете мои ответы. Ну или если их нет.

ОТЛИЧНЫЕ две ссылки

http://habrahabr.ru/post/192502/
http://habrahabr.ru/post/192296/

ОБОИМ авторам - пожал бы руки.