Хотел поредактировать переписку, но не стал.
Привожу как есть.
Надеюсь, что никто не обидится.
"Виктор Морозов
О графических нотациях.
Я категорически разочарован в графических нотациях. Когда-то, когда я о них знал только из книг, они казались весьма полезными. Представлялось, что с помощью графических нотаций можно понятным образом отражать структуру сложных вещей в их взаимосвязи.
Но когда я столкнулся на практике, оказалось, что всё вовсе не так радужно. Изобразительные свойства графических нотаций явно недостаточны. Детальная разрисовка архитектуры системы и генерация кода с модели не спасает от килотонн дичайшего макаронного кода, а эти самые килотонны дичайшего кода, прекрасно могут жить в системе, будучи инкапсулированными в паттернизированные и отвечающие всем принципам "хорошего ООП-тона" конструкции.
В этом смысле, ООП, конечно, вообще оказалось страшным троянским конём: обещали всеобщее счастье и "город Солнца", а на деле получился жуткий страх с менеджерами фабрик, адаптерами фасадов и сервантами фасетов.
Дело не в нотациях. И не в функциональщине. Хотя функциональщина во многом может спасти. Дело в масштабах. И в том, что для каждого масштаба нужен свой инструмент. Т.е. "прецедент системы" надо программировать на одних изобразительных средствах, а "локальные алгоритмы" - на других. А собственно "фреймворки" и "инфраструктуру" - на третьих. Разные уровни абстракции. А обычно всё сваливается в кучу. Ну и опять же - любая "нотация" без вменяемой документации и примеров использования (читай тестов) - ничто. Как-то так. Ну мне по крайней мере видится. Но дальше есть ещё одна проблема - "организация труда". И тут уже дело совсем и не в нотациях и не в тестах.
Насчёт инструментов и масштаба. Пример - есть скажем ассемблер и есть C, а есть C++. А есть bat-файлы. Никому в голову не приходит (теперь наверное) писать всю систему на ассемблере. Хотя наверное есть любители. Так вот и на C++ или C или Delphi ВСЮ систему видимо писать СЛОЖНО. Видимо нужны более высокоуровневые изобразительные средства. Графическая нотация (с кодогенерацией) это попытка "прикрутить некоторые костыли" для решения проблемы "укрупнения масштаба", но не панацея. Но какие-то более высокоуровневые инструменты - нужны. Мне так кажется.
Кстати к функциональщине я бы ещё добавил бы АОП как средство уменьшения сложности и вынесения "пользовательского кода" за скобки "системного". Но тут тоже весь вопрос в правильном фреймворке.
Кнут кстати как-то посетовал на то, что он зря потратил время на TeX. Который он начал делать, чтобы публиковать свои работы. Хотя мне лично кажется, что не зря. Да и опыт опять же. Не буду пытаться никого равнять с Кнутом, но и в опыте "графических нотаций" многое было "сделано зря". Потому, что "надо было колёса паровоза на ходу менять". Но иначе никак. Если это "прикладуха", которая приносит деньги, а не "чисто научный проект". Но тут дело такое - "чисто научный проект" может родить ещё большего "коня в вакууме".
Наверное QT является неплохим примером средства преодоления "проблем масштаба". В их "расширениями" и "макросами". Не могу до конца внятно судить об этом. Но мне так кажется. Хотя и QT тот же Borland когда-то ухитрился более чем трансректально использовать.
Ну и в "моих скриптах" я пытаюсь как раз решать задачу "разных масштабов" и разных "аксиоматик" для разных уровней системы. Но это пока в "плане изысканий" только. А так и на "скриптах" уже "наваяли" столько "макарон". Дело видимо не только в инструменте, но и в "описании подходов" и их документировании, на что тоже зачастую не хватает времени при занятии "прикладухой". Да и тут дело такое - "можно всё описать", но либо "не так", либо оно не будет востребовано в должном объёме. Т.е. затраты - большие, а толку - ноль.
Но тема поднята - правильная. Я сам над нею давно уже думаю.
Виктор Морозов · Общий друг – Михаил Костицын
Всё правильно. Но опять же есть "граничные случаи". Тривиальные и сложные. Пример тривиальных случаев ты привёл. Любая концепция или фреймворк к сожалению перекашивается либо в сторону тривиальных вещей, либо в сторону сложных. Нет баланса. А "очевидно", что "тривиальные" и "сложные вещи" должны делаться по-разному. В этом и сложность - сделать "унифицированный" (не забываем про UML или RUP) инструмент/подход для "всех случаев жизни". Либо это слишком тривиально, либо слишком сложно. Встаёт вопрос - "а нужен ли унифицированный инструмент"? СКОРЕЕ всего - НЕ нужен. Но тут другая проблема - что сложнее выучить один "унифицированный" инструмент или несколько "специализированных". Вот на этот вопрос "за всех" - ответить не берусь.
Ну и про "контекстное меню и кнопку" Про VCM я тебе рассказывал - изначально добавить кнопку и пункт меню было просто. Но это не вписалось во "внешние требования". Не угадали с "концепцией".
Ну а дальше - ну сложно "менять колёса на ходу".
iOS - да - неудобен в этом плане тоже. По своему опыту знаю.
Про Android - не скажу. Не программировал в нативной среде.
Виктор Морозов · Общий друг – Михаил Костицын
Ну Вить, в "нашем конкретном случае" над БАЛАНСОМ я ДАВНО думаю. Только не на всё хватает времени. Я же тебе рассказывал, что много времени тратится "в свисток" типа переделки всяческих конвертеров и схем данных. Годы уходят подчас. Но поверь - ты наблюдаешь уже далеко "не самый худший вариант". Так что - было бы желание улучшать. И искать тот самый баланс. Что непросто опять же при программировании "прикладухи". Очень много "побочных требований" приходится реализовывать.
Был кстати момент, когда не было тебя и Миши и я ОДИН занимался "всем вместе", начиная от GUI и кончая "системными вещами". Но всё равно старался улучшить ситуацию. Это я "про нас".
Но проблема ещё и в том, что я не видел "законченной концепции" с должным балансом от "ведущих производителей". За Android опять же - не скажу. Не знаком. Возможно стоит ознакомиться.
Виктор Морозов · Общий друг – Михаил Костицын
Тут - согласен. У всех есть проблемы. И для меня самого загадка - что с этим делать. Если бы была "серебряная пуля" - все бы её давно бы использовали бы.
Виктор Морозов · Общий друг – Михаил Костицын
Понятно. Ну набор кубиков это хорошо. Но это как раз почти у всех есть. А вот дальше - сложности. Особенно если проект "на годы".
Виктор Морозов · Общий друг – Михаил Костицын
ну "не скажи" есть и кубики.. хотя конечно как посмотреть..
И ещё о графической нотации. Вот скажем сервисы (на модели) - по-моему вполне себе удачное решение. Облегчает "ручной труд" и решает задачу "уменьшения связности системы". А вот те же сборки (на модели) - то ещё убожество. Пользоваться сложно. Хотя без модели ещё сложнее.А казалось бы и то и то - одна из "реализаций" Dependency Inversion. Видимо дело не только в модели, но и в накопленном опыте и его переосмыслении.
Привожу как есть.
Надеюсь, что никто не обидится.
"Виктор Морозов
О графических нотациях.
Я категорически разочарован в графических нотациях. Когда-то, когда я о них знал только из книг, они казались весьма полезными. Представлялось, что с помощью графических нотаций можно понятным образом отражать структуру сложных вещей в их взаимосвязи.
Но когда я столкнулся на практике, оказалось, что всё вовсе не так радужно. Изобразительные свойства графических нотаций явно недостаточны. Детальная разрисовка архитектуры системы и генерация кода с модели не спасает от килотонн дичайшего макаронного кода, а эти самые килотонны дичайшего кода, прекрасно могут жить в системе, будучи инкапсулированными в паттернизированные и отвечающие всем принципам "хорошего ООП-тона" конструкции.
В этом смысле, ООП, конечно, вообще оказалось страшным троянским конём: обещали всеобщее счастье и "город Солнца", а на деле получился жуткий страх с менеджерами фабрик, адаптерами фасадов и сервантами фасетов.
И, хотя я очень не люблю закорюки, очевидно, что единственным способом борьбы с перерождением ООП во всепоглощающего дикого макаронного монстра, является лёгкая функциональщинка и реактивщинка. Особенно, если она не требует закорючек."
Дело не в нотациях. И не в функциональщине. Хотя функциональщина во многом может спасти. Дело в масштабах. И в том, что для каждого масштаба нужен свой инструмент. Т.е. "прецедент системы" надо программировать на одних изобразительных средствах, а "локальные алгоритмы" - на других. А собственно "фреймворки" и "инфраструктуру" - на третьих. Разные уровни абстракции. А обычно всё сваливается в кучу. Ну и опять же - любая "нотация" без вменяемой документации и примеров использования (читай тестов) - ничто. Как-то так. Ну мне по крайней мере видится. Но дальше есть ещё одна проблема - "организация труда". И тут уже дело совсем и не в нотациях и не в тестах.
Насчёт инструментов и масштаба. Пример - есть скажем ассемблер и есть C, а есть C++. А есть bat-файлы. Никому в голову не приходит (теперь наверное) писать всю систему на ассемблере. Хотя наверное есть любители. Так вот и на C++ или C или Delphi ВСЮ систему видимо писать СЛОЖНО. Видимо нужны более высокоуровневые изобразительные средства. Графическая нотация (с кодогенерацией) это попытка "прикрутить некоторые костыли" для решения проблемы "укрупнения масштаба", но не панацея. Но какие-то более высокоуровневые инструменты - нужны. Мне так кажется.
Кстати к функциональщине я бы ещё добавил бы АОП как средство уменьшения сложности и вынесения "пользовательского кода" за скобки "системного". Но тут тоже весь вопрос в правильном фреймворке.
Кнут кстати как-то посетовал на то, что он зря потратил время на TeX. Который он начал делать, чтобы публиковать свои работы. Хотя мне лично кажется, что не зря. Да и опыт опять же. Не буду пытаться никого равнять с Кнутом, но и в опыте "графических нотаций" многое было "сделано зря". Потому, что "надо было колёса паровоза на ходу менять". Но иначе никак. Если это "прикладуха", которая приносит деньги, а не "чисто научный проект". Но тут дело такое - "чисто научный проект" может родить ещё большего "коня в вакууме".
Наверное QT является неплохим примером средства преодоления "проблем масштаба". В их "расширениями" и "макросами". Не могу до конца внятно судить об этом. Но мне так кажется. Хотя и QT тот же Borland когда-то ухитрился более чем трансректально использовать.
Ну и в "моих скриптах" я пытаюсь как раз решать задачу "разных масштабов" и разных "аксиоматик" для разных уровней системы. Но это пока в "плане изысканий" только. А так и на "скриптах" уже "наваяли" столько "макарон". Дело видимо не только в инструменте, но и в "описании подходов" и их документировании, на что тоже зачастую не хватает времени при занятии "прикладухой". Да и тут дело такое - "можно всё описать", но либо "не так", либо оно не будет востребовано в должном объёме. Т.е. затраты - большие, а толку - ноль.
Но тема поднята - правильная. Я сам над нею давно уже думаю.
Виктор Морозов · Общий друг – Михаил Костицын
Относительно Кнута - лично моё мнение: написание системы вёрстки-разметки ради издания книги (даже многотомной) - очень странная затея. Очень странная с точки зрения именно мотивации и народнохозяйственной обоснованности.
Если же не исходить из той посылки, что TeX писался ради написания его трудов - тогда очевидно, что не зря. Ведь пользуются же люди этим инструментом. "Практика - критерий истины".
Что касается "опыта графических нотаций", то, как мне кажется, одна из самых неприятных черт этого инструмента заключается в изрядной самобытности, изначальной его идеологизированности и, наконец, в том, что из-за применения этого инструмента в системе возникают сущности, наличие которых продиктовано не логикой предметной области, не архитектурой разрабатываемой системы, а только спецификой инструмента.
Примерно то же касается и фреймворков: если заводятся какие-то сущности, которые непонятно что олицетворяют собой и непонятно за что отвечают - это усложняет разработку.
Вот на мой вкус в качестве примера "неудобной" разработки можно привести iOS: меня заставляют ради простейшего функционала лепить какие-то заумные вундервафли, без которых все вполне спокойно обходятся в андроиде при реализации аналогичного функционала.
Простые вещи обязаны делаться просто и быстро.
Добавление кнопки - простая операция. Добавление контекстного меню - тоже. Добавление пункта в контекстное меню - еще проще.
Если же не исходить из той посылки, что TeX писался ради написания его трудов - тогда очевидно, что не зря. Ведь пользуются же люди этим инструментом. "Практика - критерий истины".
Что касается "опыта графических нотаций", то, как мне кажется, одна из самых неприятных черт этого инструмента заключается в изрядной самобытности, изначальной его идеологизированности и, наконец, в том, что из-за применения этого инструмента в системе возникают сущности, наличие которых продиктовано не логикой предметной области, не архитектурой разрабатываемой системы, а только спецификой инструмента.
Примерно то же касается и фреймворков: если заводятся какие-то сущности, которые непонятно что олицетворяют собой и непонятно за что отвечают - это усложняет разработку.
Вот на мой вкус в качестве примера "неудобной" разработки можно привести iOS: меня заставляют ради простейшего функционала лепить какие-то заумные вундервафли, без которых все вполне спокойно обходятся в андроиде при реализации аналогичного функционала.
Простые вещи обязаны делаться просто и быстро.
Добавление кнопки - простая операция. Добавление контекстного меню - тоже. Добавление пункта в контекстное меню - еще проще.
Всё правильно. Но опять же есть "граничные случаи". Тривиальные и сложные. Пример тривиальных случаев ты привёл. Любая концепция или фреймворк к сожалению перекашивается либо в сторону тривиальных вещей, либо в сторону сложных. Нет баланса. А "очевидно", что "тривиальные" и "сложные вещи" должны делаться по-разному. В этом и сложность - сделать "унифицированный" (не забываем про UML или RUP) инструмент/подход для "всех случаев жизни". Либо это слишком тривиально, либо слишком сложно. Встаёт вопрос - "а нужен ли унифицированный инструмент"? СКОРЕЕ всего - НЕ нужен. Но тут другая проблема - что сложнее выучить один "унифицированный" инструмент или несколько "специализированных". Вот на этот вопрос "за всех" - ответить не берусь.
Ну и про "контекстное меню и кнопку" Про VCM я тебе рассказывал - изначально добавить кнопку и пункт меню было просто. Но это не вписалось во "внешние требования". Не угадали с "концепцией".
Ну а дальше - ну сложно "менять колёса на ходу".
iOS - да - неудобен в этом плане тоже. По своему опыту знаю.
Про Android - не скажу. Не программировал в нативной среде.
Виктор Морозов · Общий друг – Михаил Костицын
Вот! Я именно к балансу и "отсутствию перекосов" и клоню. Вот именно этот баланс - и есть главная проблема. Во всяком случае, эта проблема встречается практически везде, где есть "обширный фреймворк".
Ну Вить, в "нашем конкретном случае" над БАЛАНСОМ я ДАВНО думаю. Только не на всё хватает времени. Я же тебе рассказывал, что много времени тратится "в свисток" типа переделки всяческих конвертеров и схем данных. Годы уходят подчас. Но поверь - ты наблюдаешь уже далеко "не самый худший вариант". Так что - было бы желание улучшать. И искать тот самый баланс. Что непросто опять же при программировании "прикладухи". Очень много "побочных требований" приходится реализовывать.
Был кстати момент, когда не было тебя и Миши и я ОДИН занимался "всем вместе", начиная от GUI и кончая "системными вещами". Но всё равно старался улучшить ситуацию. Это я "про нас".
Но проблема ещё и в том, что я не видел "законченной концепции" с должным балансом от "ведущих производителей". За Android опять же - не скажу. Не знаком. Возможно стоит ознакомиться.
Виктор Морозов · Общий друг – Михаил Костицын
Да я не о нашем конкретном случае, он - всего лишь частный случай. Я в целом пытаюсь рассуждать, в некотором отрыве от нашего всего хозяйства. Ведь всюду одни и те же проблемы, грабли, костыли и велосипеды. В той или мной мере. И что с этим всем делать - непонятно.
Тут - согласен. У всех есть проблемы. И для меня самого загадка - что с этим делать. Если бы была "серебряная пуля" - все бы её давно бы использовали бы.
Виктор Морозов · Общий друг – Михаил Костицын
Про андроид - там нет законченной концепции. Вообще. Есть набор кубиков - бери и делай. Вот тебе RecyclerView чтоб показывать список/грид/еще что-то, вот тебе loader чтоб данные загружать, вот тебе fragment и т.д.
Именно в этом и состоит концепция.
И - правильно. Поскольку 90% приложений - простые. Как только возникают сложные - возникает NDK и всё то же, что и везде: бубен, грабли, велосипед.
Именно в этом и состоит концепция.
И - правильно. Поскольку 90% приложений - простые. Как только возникают сложные - возникает NDK и всё то же, что и везде: бубен, грабли, велосипед.
Понятно. Ну набор кубиков это хорошо. Но это как раз почти у всех есть. А вот дальше - сложности. Особенно если проект "на годы".
Виктор Морозов · Общий друг – Михаил Костицын
Ну не скажи что "почти у всех есть". У Embarcadero вот нет никаких кубиков - одни только контролы и совсем уж низкоуровневые классы. Велосипедостроние в полный рост
ну "не скажи" есть и кубики.. хотя конечно как посмотреть..
И ещё о графической нотации. Вот скажем сервисы (на модели) - по-моему вполне себе удачное решение. Облегчает "ручной труд" и решает задачу "уменьшения связности системы". А вот те же сборки (на модели) - то ещё убожество. Пользоваться сложно. Хотя без модели ещё сложнее.А казалось бы и то и то - одна из "реализаций" Dependency Inversion. Видимо дело не только в модели, но и в накопленном опыте и его переосмыслении.
Комментариев нет:
Отправить комментарий