Здравствуйте, DarkGray, Вы писали:
DG>для абстрактных понятий не бывает четких критериев (вот введи, например, четкие критерии при каком соотношении смесь спирт-вода: называется спиртом, водкой, водой. а здесь хотя бы есть четкий способ измерить соотношение)
Четкий-не четкий, а ответ дать можно. Водка — это ~ 40%. Спирт от 70 и выше. Остальное смеси. Вода — это 0%.
DG>у абстрактного понятия "фреймворк" есть два противопоставления: DG>1. фреймворк vs библиотека DG>2. framework vs законченное приложение
О последнем вроде бы никто не говорил. Но послушать было бы интересно.
DG>способ измерения для первого противопоставления тебе уже дали: если ближе к каркасу — то framework, если ближе к нашлепке сбоку — то библиотека.
Выделенное повеселило. Определение масла через масленичную субстанцию.
DG> и тот же mfc, asp.net можно рассматривать и как framework, и как библиотеку (в зависимости от контекста)
Вот-вот. И интересен контекст в котором их рассматривают как фрэймворк. Если что "каркас" — это просто русский перевод. Не надо его в определения включать.
DG> .net — сложно рассматривать как библиотеку (в очень редких контекстах — это будет библиотека)
Дык и фрэймворком его сложно назвать. Это скорее рантайм плюс набор универсальных библотек (или фрэймворков).
DG> stl — тяжело рассматривать как framework (в очень редких контекстах — это будет framework)
Сдается мне он ни в каких контекстах не фрэймворк. Да и что это за зависимость от контекста?
DG>способ измерения для второго противопоставления: если шнягу настраивать для конечного использования надо мало — готовое приложение, если много — то framework
Что-то у тебя совсем все размазано получилось.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
DG>> .net — сложно рассматривать как библиотеку (в очень редких контекстах — это будет библиотека) VD>Дык и фрэймворком его сложно назвать. Это скорее рантайм плюс набор универсальных библотек (или фрэймворков).
Вот именно. Это, конечно, офф, но может кто объяснит, почему .NET Framework, а не .NET Platform: Re[2]: Framework
Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>Во-вот. Получается, что если использование библиотеки приводит к дикому связыванию кода, так что оторвать код от фрэймворка уже нельзя, то это был фрэймворк. А если код получается относительно независимым, то — это библиотека. Только тогда уж я бы предпочел библиотеку.
PD>Поздно. Придется вернуться лет на 20 назад
История развивается по спирали.
ЗЫ
Кстати, а причем тут Немерле?! (с)
Я тут заметил, что немерлу не нужны фрэймворки. Они в нем прекрасно выражаются в виде библиотек макросов. И преимущества у такого подхода как раз то же что и у обычных библиотек — возможность достижения низкой связанности.
Так не являются ли фрэймворки костылями для современных технологий?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD> Кстати, а причем тут Немерле?! (с) VD> Я тут заметил, что немерлу не нужны фрэймворки. Они в нем прекрасно выражаются в виде библиотек макросов.
Где бы что ни говорили — все одно сведет на баб (c)
Здравствуйте, hattab, Вы писали:
VD>> Кстати, а причем тут Немерле?! (с) VD>> Я тут заметил, что немерлу не нужны фрэймворки. Они в нем прекрасно выражаются в виде библиотек макросов.
H>Где бы что ни говорили — все одно сведет на баб (c)
Завидно?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Y>>Я всегда считал, что настоящий Тролль -- родственник Капитана. Его аргументы неопровержимые до очевидности.
VD>Опустим это словоблудие.
Ваше право. Я лишь хотел, убедиться, что Вы не Тролль.
Пока не получилось.
Y>>General MFC Topics http://msdn.microsoft.com/en-us/library/583ya1kc(VS.80).aspx Y>>Слово Framework на странице встречается 7 раз.
VD> Ага. Как в слове алкоголика встречается слова "хрень"/"хреновина". Но называется все это библиотекой.
1. MSDN(Library) и слова алкоголика имеют разную квоту доверия (у меня, во всяком случае)
2. Я привык считать, что когда люди ввязываются в спор "не за выгоды", они это делают, не что бы убедить собеседника в чем-то, а что бы узнать, не ошибаются ли они в чем-то сами (во всяком случае я делаю так).
С Вашей стороны совершенно не конструктивно (с точки зрения выяснить, чем фреймворк от библиотеки отличается) указывать на то, что там еще и слово Library есть.
Очевидно, что Библиотека, в широком смысле, -- это набор средств (в основном в виде кода), который не является продуктом для "конечного пользователя", на который можно возложить решение каких-то задач.
И Очевидно, что задачи эти могут быть как "прикладными", так "системными" -- из области организации разрабатываемого приложения. И, да, очевидно, большая библиотека может содержать пачку фреймворков.
Библиотека в смысле "библиотека vs. фреймворк" -- средства, решающие те или иные задачи, но не обеспечивающие "внутреннюю организацию" приложения.
VD> И существовал MFC еще в те времена когда модного слова "фрэймворк" еще не существовало (не употреблялось в компьютерном сленге).
Мне видится в этом как минимум две причины:
1. Маркетологи поработали
2. "Явление" стало более массовым ("фреймворков" развелось).
VD> Что позволяет назвать некую библиотеку фрэймворком.
Ничего. Если важны слова, то, как я написал выше, библиотека может его содержать.
VD>Вот скажем может ли быть фрэймворк внутри приложения? Или он обязан быть отдельной частью?
Имхо, может быть внутри.
В текущем велосипеде (спец. САПР, много интерактивной графики) он сначала был "внутри", потом стал отдельной сборкой (начал использоваться в другом приложении)
Здравствуйте, VladD2, Вы писали:
VD>Кстати, а причем тут Немерле?! (с) VD>Я тут заметил, что немерлу не нужны фрэймворки. Они в нем прекрасно выражаются в виде библиотек макросов. И преимущества у такого подхода как раз то же что и у обычных библиотек — возможность достижения низкой связанности.
Фреймворки ортогональны способу их реализации (на библиотеках или макросах). Я разделяю это
определения. Не против других, но эти более строгие. В зависимости от того, кто, когда и кого вызывает может получиться библиотека или фреймворк. На самом деле ситуация еще интереснее: фреймворк может быть собран из отличного набора вполне ортогональных библиотек. Например, сервер для веб-сервисов собирается из библиотек работы с сетевыми соединениями, обработки протокола HTTP (парсинг), библиотеки работы с XML, библиотеки разбора SOAP, части бизнес логики. И с точки зрения типичных задач (добавить новый вызов) вся собранная система будет в какой-то степени framework'ом. Другое дело, что при необходимости стек обработки можно будет заменить (ввести свой транспорт и форматы передачи), но это получится "настройка фреймворка" в основном. Более сложные задачи (если вдруг что-то где-то потребуется между слоями приложения таскать) потребуют разработки новой системы связей. Но после этого все равно типичные задачи будут задачами использования фреймворка а не библиотеки. В виде библиотеки оно неудобно получается.
То, что большинство "фреймворков" превращаются в монолиты, это проблема дизайна фреймворков. В данном случае дизайн — это не только код, но и сопутствующая документация по этому самому фреймворку (обучение использованию). На примере веб-сервиса выше было показано, как все может быть реализовано в виде библиотек. Если в документации при этом описано, что есть "стандартные" методы построения стека (и то, что они делают внутри), то можно самим сконструировать новый стек. Если же описано только написание новых методов — то да, это проблемы. С макросами может быть та же история — либо это большой макрос, интегрирующий код в свой (или другой) фреймворк, либо макрос, генерирующий вызовы к стеку библиотек. Правда как при этом настраивать макрос — не понятно. Как видим — ничего крутости макросов не показывает.
Более того, у меня перед глазами есть конкретный пример фреймворка на макросах nemerle со всеми его проблемами расширяемости Это NemerleUnit. Вызов пользовательского кода прошит в framework и NemerleUnit определяет, что и как будет вызываться. Типичная framework'овская проблема в том, что тесты создают сами макры. Это, в частности, не позволяет делать "параметрические" тесты. "Параметрические" тесты — это тесты, которые получают на вход объект и тестируют его. Изначально мне такие тесты были нужны для тестирования интерфейсов. Фактически — некоторый validation для различных реализаций. В принципе, для одного и того же интерфейса могут быть разные комплекты (не ортогональные, а проверяющие некоторые дополнительные гарантии). И реализовав интерфейс я хочу проверить наличие основной фичи и опциональных фичей C и D. Как мне реализовывать эти тесты? Ну в xUnit можно через наследование, но это все же workaround. А в NemerleUnit? Кстати, ссылки на svn не работают с указанной странички, я хотел макру посмотреть, вдруг там из коробки есть то, что мне нужно.
К чему все это — да все к тому же, и макры, и библиотеки могут быть framework'ом. "Библиотека" запуска юнит-тестов в правильном виде состоит из двух частей. "Runners", получающих на вход набор тестов для проведения. И библиотека для генерации наборов тестов. Это всевозможные способы генерации сьютов (из метаданных класса, конструктивным кодом и т.п.). Различные способы генерации тестов (из метаданных классов, настраиваемые способы). Ну и "обвязка по умолчанию", конструирующая тесты из метаданных и передающая их запускалке. С возможностью полностью перекроить эту обвязку. Плюс документация. Фокус в том, что можно это реализовать как на макрах (теми же макрами генерировать тесты для библиотеки), так и в обычном коде (кое где может понадобиться больше кода). Если же runner'ы глубоко глубоко прятать, то придется копаться в коде или писать костыли (например, генераторы, генерирующие требуемые коды для макры NemerleUnit).
VD>Так не являются ли фрэймворки костылями для современных технологий?
Ну... Макры — это фреймворк по расширению компилятора Кстати, компилятор мог быть бы и набором библиотек. Например, расширяемый парсер + отдельный кодогенератор + набор конвертеров между представлениями. Может, конечно, так и есть... Тогда в макрах должно быть можно создавать совсем новые типы узлов AST, новые системы типов и т.п. Например, можно ли CheckedExceptions добавить макрой? С учетом отсутствия карринга (а только с частичным применением) это не слишком усложняет систему типов. Или добавить ко многим объектам новый атрибут — документацию. Поясню, зачем это нужно — есть некоторые идеи генерировать по одному описанию весь спектр "различных" по поведению структур: иммутабельные, реактивные без возможности мутации в API, реактивные с возможностью мутации в API и кучу конвертеров между ними. Ну и в добавок различные протоколы сериализации плюс документацию по формату протокола в wiki . А макры такое смогут?
В случае ортогонального набора библиотек такие изменения на уровне "языка" не слишком сложно было бы сделать. Ну да, написать кучу оберток поверх стандартных структур, вызывая стандартные обработчик после преобразований типов. Либо вообще просто добавлением дополнительных обработчиков (хотя в этом сомневаюсь). Вот и интересно — макры это все же framerwork к компилятору (хотя бы в одном из двух примеров нужно что-то править в "ядре" компилятора) или способ удобного использования библиотек компилятора (тогда оба примера реализуются "на макрах").
P.S. Ну и если бы nemerle был набором библиотек, к нему достаточно легко было бы прикрутить другой backend. Это было бы огромным плюсом. Ну и заодно еще одним свидетельством того, что сама платформа "nemerle" — это больше набор библиотек, чем famework over .Net.
Здравствуйте, VladD2, Вы писали:
VD>Кто-нибудь может дать внятное определение термину Framework?
ИМХО — Фреймворк — прослойка между программным кодом и машиной, вводящая новый синтаксис и семантику, которые более аппаратно-независимые чем машинные, и представляют определенные удобства для программиста в том смысле в каком обычно его представляет высокоуровневое программирование по сравнению с низкоуровневым. В идеале, программист вообще может не знать об особенностях машины, на которой работает, фреймворк должен скрывать эти особенности и их сложность.
Здравствуйте, VladD2, Вы писали:
VD>Кто-нибудь может дать внятное определение термину Framework?
VD>Википедевое не предлагать. Оно не внятное.
Думаю внятнее найти сложнее, тут и про костыли и про форму и про размер и про шаблоны, ну и само собою про точки расширения.
The fixed part of the solution is written using traditional design, coding,
and testing techniques.
Depending on the size and shape of the problem,
this fixed part of the solution might be called a framework, a platform, an
interpreter, or an Application Programming Interface (API).
The fixed part
captures the architectural patterns that make up the domain and exposes extension points that enable it to be used in a variety of solutions.
What makes the approach applicable is the fact that you create the variable part
of the solution by using a special-purpose language—a DSL.
Здравствуйте, VladD2, Вы писали:
VD>Так где же эта грань отделяющая библиотеки или подходы от фрэймворка? VD>Это только мне кажется что слово Framework является эдаким цензурным синонимом слова "хреновина"?
Разница должна быть нечеткая.
По мне так, фреймворк это то, что менее гибкое чем библиотека. Фреймворк может предлагать рантаймовый граф обьектов (передопределенный фреймворком заранее), в который можно вносить небольшие добавки.
Как в свое время был MFC с шаблончиками DocumentView (или как там его), очень негибкий и костлявый инструмент.
И в то же время существовал Delphi — это уже скорее была гибкая библиотека GUI (в сравнении с MFC).
Если сравнивать WinForms и WPF , то WPF ближе к фреймворкам, WinForms ближе к гибким библиотекам.
А в LINQ to Objects колбэки есть, но нету рантаймовых, жестко предопределенных, графов. К тому же он очень универсальный, гибкий инструмент, поэтому называть это фреймворком как то не очень.
Здравствуйте, VladD2, Вы писали:
MC>>Набор публичных библиотек, образующих большую систему и призванных облегчить (упростить, ускорить, предоставить готовые проверенные решения) разработку приложений в определенной предметной области или на определенных языках. VD>А зачем для вполне понятного понятия набор библиотек вводить отдельное понятие? VD>Да и почему сразу набор? То есть получается складываем две библиотеки в кучу и получаем фрэймворк?
Мне всегда казалось, что фреймворк от просто библиотеки отличает то, что фреймворк есть некий универсальный набор библиотек, предназначенный для создания приложений разного рода. Т.е. библиотека для работы с ГУИ — это просто библиотека, а вот свалив в кучу ГУИ, веб и проч. и проч. — получаем фреймворк.
Сам термин, скорее, имеет больше маркетинговое применение, особой пользы в нем нет. Разве что позволяет отличить проблемно-ориентированный набор библиотек, т.е. набор библиотек, ориентированных на решение какой-то конкретной задачи, и набор библиотек, ориентированных на решение разных несвязанных между собой задач.
Здравствуйте, VladD2, Вы писали:
VD>Кто-нибудь может дать внятное определение термину Framework?
1) Гугл предлагает очень много различных вариантов. Очень часто во всех встречаемых мной определениях содержались следующие слова:
облегчающая, решение, типового, набора, задач, определенной, предметной, области
2) Учитывая иностранное происхождение термина, берем словарь и находим перевод, выкинув заведомо неподходящие к ней области варианты, клеим остальное
.......
3) PROFIT!!!!!
кодовая база/основа, облегчающая решение типового набора задач в определенной предметной области
система готового набора средств, облегчающая решение типового набора задач в определенной предметной области
набор готовых средств, облегчающий решение типового набора задач в определенной предметной области
коробка готовых инструментов, облегчающих решение типового набора задач в определенной предметной области
Получается, что в зависимости от контекста, это слово может означать материальное отражение накопленного и структурированного опыта, знаний и инструментов, которые как вы уже наверное догадались
облегчают решение типового набора задач в определенной предметной области
.
Кстати, компилятор мог быть бы и набором библиотек. Например, расширяемый парсер + отдельный кодогенератор + набор конвертеров между представлениями. Может, конечно, так и есть... Тогда в макрах должно быть можно создавать совсем новые типы узлов AST, новые системы типов и т.п. Например, можно ли CheckedExceptions добавить макрой? С учетом отсутствия карринга (а только с частичным применением) это не слишком усложняет систему типов. Или добавить ко многим объектам новый атрибут — документацию. Поясню, зачем это нужно — есть некоторые идеи генерировать по одному описанию весь спектр "различных" по поведению структур: иммутабельные, реактивные без возможности мутации в API, реактивные с возможностью мутации в API и кучу конвертеров между ними. Ну и в добавок различные протоколы сериализации плюс документацию по формату протокола в wiki 
