Теория нас учит делать небольшие максимально независимые компоненты, соединяя которые получается хороший код. Это действительно работает, но возникает проблема в том, что нужно помнить большое количество этих мелких элементов. Даже объединяя их в библиотеки, фреймворки и каркасы проблема не решается. Как быть в таком случае? Какую методику можно применить для того, чтобы компоненты были универсальны, с другой стороны их было много (в идеале на большинство задач должно быть свое решение), но они должны быть очень запоминаемы и доступны. Так как есть риск тут же сесть за написание очередного велосипеда.
В реальном мире проблема решается узкой специализацией - так строитель занимается только строительством (и там у него также есть своя специализация). В результате рабочий имеет дело с большим, но все же ограниченным набором доступных для работы элементов. В большинстве случаев рабочий не изготавливает собственные блоки - ему поставляют готовые и он пытается сделать что-то из них. Работа растянута во времени, большинство проектов являются типовыми и есть возможность "подсмотреть", есть стандарты, правила и законы жестко регулирующие процесс. В программировании благодаря возможности комбинирования элементов скорость создания и получения новых блоков во много раз выше и это создает проблемы такого рода.
Организация кода
Сообщений 1 страница 16 из 16
Поделиться12017-09-25 10:25:29
Поделиться22017-09-25 11:35:53
Freeman же предлагал БД. Тут вопрос скорее в неоднородности программных единиц.
Поделиться32017-09-25 12:04:19
- Активный участник
- Сообщений: 355
- Провел на форуме:
18 дней 8 часов - Последний визит:
2020-11-06 19:50:25
utkin
Какую методику можно применить для того, чтобы компоненты были универсальны
Теория больших-данных . Берём все возможные случае. И проводим абстрагирование, т.е. классификацию и обобщение результатов. И отсечения малозначимых, бритвой Аккамы.
Процент малозначимости задаётся изначально. Поэтому его можно варьировать.
Если данных недостаточно, то следует притенять теорию ИИ и генерировать самим недостающие данные используя индукцию и обратные связи.
Результатом объединения таких подходов стала возможность автоматического построения семантической основы естественного языка - онтологическое дерево, вернее граф.
В ведение:
http://www.jfsowa.com/talks/vrmind.pdf
А тут как-бы продолжение автор он там немного скорректировал взгляды.
http://www.jfsowa.com/talks/nlu.pdf
Тут только стоит правильно проработать метрику оценки достижения цели.
В принципе у меня есть идеи по такой метрике - но пока не публикую.
Отредактировано Павиа (2017-09-25 12:06:44)
Поделиться42017-09-25 12:49:37
Freeman же предлагал БД. Тут вопрос скорее в неоднородности программных единиц.
Вопрос не в реализации пока, а в самой технологии. Как это должно выглядеть. В конце-концов лежит это где-то в папке, в сети или просто на бумаге не имеет значения, поскольку количество компонентов достаточно велико.
Теория больших-данных . Берём все возможные случае. И проводим абстрагирование, т.е. классификацию и обобщение результатов. И отсечения малозначимых, бритвой Аккамы.
При этом проблема не решается. Допустим у нас есть все возможные случае в 10^15. Абстрагирование - стало 10^10. Отсекли малозначимое - 10^5. Для человека оперировать 10^5 количеством элементов это пупец как проблемно. В распределенной среде (командная разработка) количество проблем начнет опять увеличиваться.
Как видите проблема не решена.
Поделиться52017-09-25 14:22:32
- Активный участник
- Сообщений: 355
- Провел на форуме:
18 дней 8 часов - Последний визит:
2020-11-06 19:50:25
utkin
Есть понятие тезариус - закрытый или замкнутый словарь. В основе антологии знаний есть как раз положен тезаурус. Есть остов дерева в среднем где-то 300-10 000 понятий. Остальные понятие даются через них. Года за 3-5 средний студент должен такое освоить.
Можно и одной инструкцией всё описать:
https://en.wikipedia.org/wiki/One_instr … t_computer
Или вспомнить Эллочку Людоедочку которой хватала 23 слова для общения.
Который раз составляю план создания ОС и бросаю это дело. Вечно выходит минимум 100 программ. Получается 10 000 функций. А если всё разделять на независимые, то считай что это будут классы, то это ещё в 10 раз больше будет.
Как не печально но видимо эти 10 000 понятий и есть оптимум.
Отредактировано Павиа (2017-09-25 14:36:33)
Поделиться62017-09-25 14:59:35
Это понятно. Но Вы открыли только вершину айсберга. Допустим Вы делаете ОС и Вам нужно 10 000 функций. ОК. Но потом Вы возьметесь за другой проект (например социальные сети) и там Вам понадобится еще 2000 функций. Понимаете? Эти 2000 функций (или 1000 какая разница?) отличны от 10 000 функций для ОСи. Даже если Вы их логически разложите по отдельным полкам - это не отменяет понимание хотя бы интерфейса (то есть как вызвать и что будет возвращено в итоге). Это та сложность, которая ограничивает скорость создания крупных проектов.
Поделиться72017-09-25 15:12:54
- Активный участник
- Сообщений: 355
- Провел на форуме:
18 дней 8 часов - Последний визит:
2020-11-06 19:50:25
Это та сложность, которая ограничивает скорость создания крупных проектов.
Скорость системы определяет самое медленное звено в цепочке. Да человек самое медленное звено. Исключаем его или заменяем на ИИ. И ваша система будет создаваться очень быстро.
Поделиться82017-09-25 16:11:31
Допустим Вы делаете ОС и Вам нужно 10 000 функций. ОК. Но потом Вы возьметесь за другой проект (например социальные сети) и там Вам понадобится еще 2000 функций. Понимаете? Эти 2000 функций (или 1000 какая разница?) отличны от 10 000 функций для ОСи. Даже если Вы их логически разложите по отдельным полкам - это не отменяет понимание хотя бы интерфейса (то есть как вызвать и что будет возвращено в итоге).
Почему БД для этого подходят?
Поделиться92017-09-26 07:04:38
Исключаем его или заменяем на ИИ. И ваша система будет создаваться очень быстро.
Пока не получается.
Почему БД для этого подходят?
Наверно почему не подходят? Потому что все равно как не абстрагируй на данный момент человеку приходится иметь дело с большим количеством компонентов. Грубо говоря глаза разбегаются. Можно выбрать неправильный компонент (менее эффективный для данного случая), можно не найти компонент, можно перепутать (то есть использовать компонент не по назначению). Нужно в конце концов знать чем занимается каждый компонент, чтобы выбрать нужный.
Это не проблема если у Вас 10 или 15 компонентов. Их можно выучить, разложить по полочкам. С тысячью компонентов уже начинаются проблемы. Потому что если разложить по полочкам, полочек может оказаться много. И тогда полочки нужно тоже разложить по полочкам (ящичкам, стопочкам, папочкам, сундучкам и т.д.). Когда вложенность иерархий достигает более 3-4 начинаются проблемы. Мы получаем большую разветвленную иерархию это в простом виде. Если все обнести тегами (то есть присвоить каждому элементу определенные свойства для поиска), то получаем граф с большим количеством проблем.
Ситуацию можно представить в виде библиотеки. Если Вы ищите одну конкретную книгу проблем нет. Но если Вы ищите книгу, название и автор которой неизвестны начинаются проблемы. Вы говорите мне нужна книга рецептов, не помню кто автор. Не вопрос - библиотекарь ведет Вас к стеллажу до потолка с книгами по кулинарии и чтобы просто прочитать хотя бы названия всех этих книг уже потребуется время.
Здесь вопрос не в БД или в БД. Здесь вопрос в организации хранения и поиска нужных компонентов.
Поделиться102017-09-26 11:26:27
Здесь вопрос не в БД или в БД. Здесь вопрос в организации хранения и поиска нужных компонентов.
Но БД занимаются именно этим вопросом.
Но если Вы ищите книгу, название и автор которой неизвестны начинаются проблемы. Вы говорите мне нужна книга рецептов, не помню кто автор.
Тем не менее, можно написать запрос, учитывающий, что у автора были яйца и духовка. Можно найти даже по приблизительным словам, учитывая похожесть.
Проблема может быть только в слабой самодокументированности кода.
А жёсткие иерархии вообще плохо решают эту проблему (грифона искать среди сказочных животных или птиц?) и вынуждают целиком их запоминать.
Обычно при больших объемах используется иерархический "поиск в найденном".
Поделиться112017-09-26 12:27:26
Но БД занимаются именно этим вопросом.
В данном случае не спасает.
Обычно при больших объемах используется иерархический "поиск в найденном".
Вместо работы придется все время делать поиск 
.
Поделиться122017-09-26 12:59:39
- Активный участник
- Сообщений: 355
- Провел на форуме:
18 дней 8 часов - Последний визит:
2020-11-06 19:50:25
Вместо работы придется все время делать поиск .
А как вы хотели? - программирование это интеллектуальный труд.
Есть 3 категории людей. Те кто занимаются настройкой - оператор.
Те кто переписывают данные с одного представления на другое - заняты бесполезной работой.
И есть те кто создают новое. Так вот что-бы создавать новое надо уметь бежать впереди паровоза.
Те кто умеют бежать впереди паровоза тем справка не нужна. Им вообще кроме чистой фантазии ничего не нужно.
Есть те кто умеют имитировать новизну, вот они как раз и занимаются поиском что-бы такое переиначить переделать.
Так вот тех кто умеет бежать впереди паровоза и обгонять время называют гениями.
А программисты это вторые всего лишь слуги народа, которую в угоду потребителю показывают одни и тежи данные в разных формах.
По большей части web-программисты это операторы которые только и настраивают внешний вид данных. Вот и всё - им даже программировать не нужно.
А вот к о создаёт фреймворки, те как раз и занимается поиском и переинчиванием кода. Делая вид новизны.
Но для них есть удобные средства поиска: контекстный поиск по ctrl+<пробел>; поиск по справке F1 или ?; есть поиск по странице ctrl+F.К примеру QT строка поиска всегда в окне редактора.
А гениям я уже говорил окромя чистого листа бумаги и ручки ничего не нужно.
Отредактировано Павиа (2017-09-26 13:01:34)
Поделиться132017-09-26 14:18:02
Да, но задача уменьшить сложность процесса, а не просто свалить все на гениев .
Поделиться142017-09-26 15:57:18
- Активный участник
- Сообщений: 355
- Провел на форуме:
18 дней 8 часов - Последний визит:
2020-11-06 19:50:25
utkin
Для упрощения существуют диалоговые системы. Для примера как в Qartus. Для создания модуля система вам задаёт ряд вопросов на выходе готовый модуль. Только её можно развить используя достижения онтологии. Ты ей вопрос она тебе решение. Или если надо, то она задаёт наводящие вопросы.
Поделиться152017-09-26 16:37:19
Вместо работы придется все время делать поиск .
А что есть работа? Как бы труд программиста и заключается в основном в поиске - руководства, справки, форумы и т.д.
Тут вопрос скорее в скорости и качестве подсказок.
Так изначально был поставлен вопрос - что связи слишком сложные и надо быстро найти наиболее близкое решение.
Да, но задача уменьшить сложность процесса, а не просто свалить все на гениев .
Бегать по жёсткой иерархии много дольше и утомительнее. У новичка вообще настолько неэффективно, что всё равно сведётся к гуглу.
Поделиться162017-09-27 07:23:05
Бегать по жёсткой иерархии много дольше и утомительнее.
Да, я про это как раз и веду речь .
У новичка вообще настолько неэффективно, что всё равно сведётся к гуглу.
Гугл не умеет решать такие задачи . Он ориентирован на получение прибыли.