Зміст
Частина 2
Пролог
Пройшло вже декілька дній з моменту публикації першого посту по даній темі. Ох і наслухався я про себе за цей час, ну, не так про себе, як про саму ідею. На жаль, все "Фу..." не пішло в коментарі. Хтось писав в скайп і джаббер, хтось в особистому співлкуванні. Підбиваючи підсумки: всі засумнівались і посміхались. Але... Багато хто так і не зрозумів, що я хочу донести, тобто неправильно зрозуміли суть задачі, яку я пробую вирішити, і зараз я це хотів би поправити. це швидше моя помилка.
Я не пробую створити універсальний засіб вирішення інженерних задач
Це в корені оманливе твердження, яке я отримав в коментарях до попереднього поста. Універсальне рішення - це наш мозгок Але найбільш цікавий момент тут в тому, що він не призначений напряму вирішувати задачі. Схему його роботи шивдше можна подати як: "навчитись рішати" -> "рішити". А в наш час ще й створити засіб для того, щоб задачу, яку ми навчились рішати - вирішував хтось іншй. Наприклад, арифметичні операції прекрасно виконує калькулятор.
До чого я веду?
Я веду до того, щоо я хочу сторити не фреймворк, який вирішує всі задачі (тобто не певну уіиверсальну нейромережу, і ніякий інший універсальний апарат розв'язання задач), - це уже не будет фреймворк, а "кнопка" "Зробити зашибісь". Я хочу створити фреймворк, що реалізує архітектуру (підхід, методологію) для проектування додатків, яку можна застосовувати при вирішенні всіх задач.
Наводжу приклад
практично всі великі комерційні комп'ютерні ігри створюються на об'єктно-оріентованих мовах програмування (в основному це С++). Спроба зробити гру, користуючисьь тільки структурним підходом призведе самі розумієте до чого.
Але тут такий цікавий факт. Маючи, наприклад, в своєму розпорядженні, грубо кажучи, функцію main (розглянемо варіант на С), ми можемо написати будь-який додаток:
// Do any task in the world
return 0;
}
Тобто, по суті, ось воно! =) Відсутність фреймворку, якихось архітектурних правил і обмежень і привело нас до ціли. Користуючись таким "фреймворком" можна зробити все.
Смішно, правда?
Дійсно, понаписував тут про терминаторів, про всяку фігню і дойшов до того, що фреймворки нафіг не потрібні. Не зовсім так.
Суть моїх починань в тому, що розвиваючи код, наведений вище таким чином, щоб він спрощував життя розробнику і при цьому не накладав на нього обмежень у вирішенні якої б то не було задачі, ми отримаємо те, що нам і потрібно. Ну, а, оскільки я, все ж таки згадував, що пробувати виконати реалізацію будемо на Python, то початком будет що? Правильно, - порожній Python-модуль.
Тобто, клжен раз додаючи рядок коду в фреймворк варто задумуватись і доводити, що такий підхід не змусить розробника, який знаходиться в здравому умі і світлій пам'яті, втикати костилі в програму.
Висновок
Справи з підкоренням світу йдуть досить погано, але, дякуючи впевненості Андрія Свєтлова в тому, що задача більш проста, якось до неї повернусь, може навіть напишу про прогрес тут.
Надіюсь, що вніс деяку ясність в ідею, викладену в попередній публікації, якщо не запутав вас ще більше :)
Подразумевается ли наличие некоего стандартного функционала(если да, то что именно) или же фреймворк только должен предоставлять возможность использования архитектуры
ВідповістиВидалитиОтличный вопрос! (он мне показал, что этот пост я написал не зря :) ).
ВідповістиВидалитиЭта тема очень болезненная. Как показывает история и опыт использования, большинство предпочитает batteries included (Django), а не делай как хочешь, и чем хочешь (Pylons).
Понятие "стандартного функционала" более как соответствует целям преследуемой здесь задачи, и эта проблема (надеюсь) будет решаться.
Суть проблемы в том, что в разных областях "стандартный функционал" будет СОВЕРШЕННО разным и даже не пересекатся.
То есть внедрение такового в код, и даже больше, - ОПРЕДЕЛЕНИЕ данного ПОНЯТИЯ еще будет формироваться и пока у меня нет ответа на этот вопрос.
По поводу вопроса в прологе:
ВідповістиВидалитиМайлз Беннетт Дайсон - ведущий программист «Кибердайн Системс» в паралельной/вымышленной вселенной фильмов про Терминатора. :)
Таки да! А на мониторе позади него мы видим призрачные строчки кода будущего фреймврока :)
ВідповістиВидалитиЯ так понял, что идеальный универсальный фреймворк на данный момент состоит из пустого модуля.
ВідповістиВидалитиДумаю теперь стоит произвести небольшой анализ существующих фреймворков и архитектур и вывести из них начальный набор аксиом.
>>> Я так понял, что идеальный универсальный фреймворк на данный момент состоит из пустого модуля.
ВідповістиВидалитиСовершенно верно :)
>>> Думаю теперь стоит произвести небольшой анализ существующих фреймворков и архитектур и вывести из них начальный набор аксиом.
Не совем так. Это то, о чем я писал в первой главе, - никакой жизни не хватит выучить все фреймворки, средства и категории задач", а при такой задачи обязательно знать все :). Задача превращается в полный перебор... =(
Как я описал в первой главе, подход будет более теоретический, то есть: пишем код и смотрим, применим ли он (удобен ли он) для всего класса задач. Если нет - так не пишем, думаем как сделать по-другому.
>>> никакой жизни не хватит выучить все фреймворки, средства и категории задач
ВідповістиВидалити>>> пишем код и смотрим, применим ли он (удобен ли он) для всего класса задач.
Здесь начинается путаница... Нужно разобраться со всем самому либо пустить в мир на растерзание.
"Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг - из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле". (с) Александр Степанов
ВідповістиВидалитиВ данном случае это особенно актуально в связи с полной неясностью задачи
а вообще я люблю написать, посмотреть шевелится ли "оно" и если что кувалдой по голове. Первая итерация. А дальше повторяем :)
ВідповістиВидалитиТак придумали шаблоны проектирования. На базе опыта реализации многих задач выделили общие приемы и подходы
ВідповістиВидалити@theod
ВідповістиВидалити>>> сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы.
Вот с этим категорически и полностью согласен. И я писал об этом в первом посте, как первый путь создания, - анализировать все практические решения. И даже написал, почему таким путем нельзя пойти.
мне больше нравится первый путь решения.
ВідповістиВидалитиобьясню почему:
как ты будеш смотреть\оценивать применима ли "строчка" для всех классов задач? особенно учитывая что отрицаеш необходимость наличия опыта в различных классах задач
изначально ты планируеш решать эту задачу один(делаю такой вывод из того что ты откинул первый вариант про пересечение множеств), но даже уже наличие комментариев, ламает все дрова, т.к. начинаем искать решение вместе
такую задачу нужно решать сообща, и решать её должны люди набившие руку в большом круге задач
это не значит, что ты должен остановится, твой путь и опыт который ты получиш в поисках решения тоже важен, и возможно он приведёт кого-то к какой то правильной мысли
>>> мне больше нравится первый путь решения.
ВідповістиВидалитиМне тоже. И я полностью принимаю и понимаю все аргументы.
>>> как ты будеш смотреть\оценивать применима ли "строчка" для всех классов задач?
Я ждал этого вопроса. Только здравым смыслом =). Я думаю, что в процессе поиска все станет понятно, либо мне станет понятно, что задачу решить не могу (нереально будет звучать слишком громко), и вообще все это фигня =(
Назар
ВідповістиВидалити>>На базе опыта реализации многих задач выделили >>общие приемы и подходы
В том то и дело, что сначала были попытки, а потом появились шаблоны :)
Блин, как я себе сейчас напоминаю этого товарища - http://python.su/forum/viewtopic.php?id=3996
ВідповістиВидалитиЯ правильно понял, что вы собираетесь выработать общую методологию разработки как под создание игр, так и под создание веб приложений? Попахивает поповщиной...
ВідповістиВидалити>>> Я правильно понял, что вы собираетесь выработать общую методологию разработки как под создание игр, так и под создание веб приложений?
ВідповістиВидалитиПримерно "в десятку".
>>> Попахивает поповщиной...
Главное правильно приготовить :) А чем оно там попахивает - разберемся.
>>> Блин, как я себе сейчас напоминаю этого товарища -
ВідповістиВидалити>>> http://python.su/forum/viewtopic.php?id=3996
Ууу... Мега чувак. До сих пор не оставил своей идеи. :-)
А вообще да, я считаю, что в итоге ты придёшь к пустому питоньему модулю, набору стандартных библиотек и pypi. Ведь по сути это и есть твой универсальный фреймвок для решения любых задач.
Ну да, собаку выгулять пока нельзя, но это, думаю, в разработке. :-)
@ZZZ
ВідповістиВидалитиКак сказал мне @theod, разница между мной и тем чуваком в том, что в моем случае нельзя оценить объем работ...