О вреде ООП надо говорить! Это - слишком важная тема, чтобы отмалчиваться.

Мой любимый вопрос к тем, кто думает, что программирование интуитивно понятно: «Как ты пишешь программы?».

Перевожу описание алгоритма с русского языка на язык программирования.

Мой любимый вопрос к тем, кто думает, что программирование интуитивно понятно: «Как ты пишешь программы?».

Представляю программу по кусочкам в голове, потом записываю, проверяю, представляю следующий кусочек…

А что отвечают те кто бьет тебя ногами?

Так, у тебя лучше не спрашивать. А том можно у разговором увлечься))

все у него с ним в порядке=)

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

а ты крепко подумал с 2001 года и перешел из ro в rw на лоре?:)

Оооо, ты даже не представляешь!..

Оооо, ты даже не представляешь!

да уж интересно, конечно.) времени-то прошло огого.

Представляю программу по кусочкам в голове... представляю следующий кусочек...

И как это — представляю. И почему именно этот кусочек? И как после этого кусочка — другой кусочек?

А что отвечают те кто бьет тебя ногами?

Что-то про методологии, ООП, паттерны. На эту тему анекдот есть, ппц какой бородатый.

Техникум, значит, идет экзамен по электротехнике. Препод спрашивает у студента, как работает трансформатор. Тот, недолго подумав: "-- Уууууууууу."

Вот так и тут, с этим Уууууууу-ООП.

И как это — представляю.

Ну это фича мозга) кто то подключает зрительную кору, кто то без нее обходится просто проговаривая алгоритм словами.

И почему именно этот кусочек?

То с чего проще начать или то в чем больше всего сомневаешься, смотря какая программа.

И как после этого кусочка — другой кусочек?

Связанный соответсвенно, постепенно усложняю то что получается.

Я сейчас между проектами просто. Один уже созрел и скоро будет отпущен на волю. А следующие проекты будут связаны с психологией, человеком, Сильным ИИ и вот этим вот всем. Программирование, как мы его знаем, фсё. Доживает своё.

Вот так и тут, с этим Уууууууу-ООП.

С трансформатором плохой пример, это же устройство, а не то что ты делаешь.

Ну и вообще то что интуитивно понятно наоборот как раз сложно объяснить словами, по этому и интуитивно)

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

Само по себе странно пытаться получить объяснение того что на интуиции)

но если я начну тебя спрашивать ты охренеешь рассказывать как и в какой момент отрабатывают твои мышцы и как ты контролируешь равновесие

Годно, но есть возражение. Фактор размерности не мешает нам передавать информацию из головы А в голову Б посредством механизмов символизации. Не всё так может быть передано на практике, так как вербальный канал, всё же, слабоват. Ну, давайте подключим визуальный, и еще книжки можно читать.

Само по себе странно пытаться получить объяснение того что на интуиции)

странно пытаться получить объяснение того что на интуиции

Мегагодно. И теперь главный вопрос: почему «странно»? Поскольку вопрос таки серьезный, я на время отложу шутеечки в сторону и конкретизирую вопрос. Тут есть какое-то фундаментальное препятствие или это просто «слишком сложно»?

Тут есть какое-то фундаментальное препятствие или это просто «слишком сложно»?

Мне кажется что процессы в голове разные происходят.

Например готовить борщ не сложно, но нельзя сказать что это интуитивно понятно, нужна инструкция.

То есть сложно и интуитивно это ортогональные вещи.

Gui без ООП? X-Window

https://www.x.org/wiki/guide/concepts/#index8h3 – принципы ООП

HTML+CSS+Javascript, Dear ImGui…

Объекты есть, полиморфизм и наследование есть.

Dear ImGui…

https://github.com/ocornut/imgui/blob/master/imgui.h – во все поля.

Своими примерами сказать-то что хотел, теоретик?

Для GUI-приложений лучшего подхода чем ООП и ООП на стероидах декларативщины (как QML или Flutter) так и не придумали. Так что твои примеры GUI якобы без ООП лишь ослабали твои изначальные аргументы против этого объектного подхода и этой философии.

Тупого включил?

Вот ты именно что включил.

То есть сложно и интуитивно это ортогональные вещи.

Ок. Принимаю. Да, «это интуитивное» — это правильный ответ первого уровня. И я очень рад (честно), что его сразу услышал. Хотя на первом уровне меня никто бить ногами еще не собирался, но есть и второй, третий, и т.д.

У меня глубокая ночь уже и пора спать, а я пока задам тебе один вопрос, если позволишь)

Мне кажется что процессы в голове разные происходят.

Как ты думаешь (из твоей собственной практики), если быть осведомленным об этих процессах, это влияет на сложность проблем, которые мы способны решать?

Как ты думаешь (из твоей собственной практики), если быть осведомленным об этих процессах, это влияет на сложность проблем, которые мы способны решать?

Ну вообще смотря какие конкретно там процессы, мысли в голове не из космоса появляются, круг решаемых задач точно можно расширить, со сложностью сложнее) если это количество аспектов ситуации то у пространства в черепе есть предел.

В общем КМК, когда люди говорят что прогать интуитивно понятно, с посылом что это легко, они просто понтуются.) У них это интуитивно потому что на опыте.

Корректно можно было бы сказать например: «для студентов физмат школ программирование интуитивно понятно». Тогда можно было бы что то конструктивно обсуждать.

А ты их за эти понты наказываешь вопросами вообще из другой плоскости)

Как ты думаешь (из твоей собственной практики), если быть осведомленным об этих процессах, это влияет на сложность проблем, которые мы способны решать?

Вопрос не ко мне, но если быть точно осведомлёнными, то это позволяет промежуточные данные записывать на внешний носитель (хотя бы листок бумаги). Без этого в мозге не более 9 сущностей крутить можно. Это как раз про сложность.

Кроме того, часть эвристик построения алгоритмов можно формализовать (как это сделано в ТРИЗ, например). Кстати, паттерны ООП именно эту цель и преследуют: вместо создания алгоритма с нуля можно сначала перебрать паттерн и выбрать тот, который подходит к структуре задачи. Это не про сложность, но про скорость получения ответа.

Без этого в мозге не более 9 сущностей крутить можно.

Это если сознательно, и там количество меняется после каждого нового эксперимента. Уже 3-4)

Интуиция бессознательная деятельность.

Это не про сложность, но про скорость получения ответа.

По идеи это и про сложность так же, только паттерны не ресурс мозга увеличивают, а упрощают задачу с помощью абстракций. Делаем из сложной задачи простую.

Это если сознательно, и там количество меняется после каждого нового эксперимента. Уже 3-4)

Я же пишу «не больше». Зависит от человека (от 5 до 9) и зависит от дополнительных мыслительных потоков (всё, что надо помнить в кратковременной памяти или что надо видеть в окружающем мире, занимает эти ресурсы).

Интуиция бессознательная деятельность.

Но ограничение на взаимодействующие объекты всё равно есть. Если количество объектов больше, то в лучшем случае будет ощущение «нутром чую, объяснить не могу».

Даже не понятно, что тут может быть непонятно. Просто прикиньте какое количество пользователей водки читали материалы «как правильно пить водку» и какое количество программистов на ООП языках читали материалы «как правильно использовать ООП».

«нутром чую, объяснить не могу».

Вроде как это и называется инсайт.

Вроде как это и называется инсайт.

Инсайт — это когда есть понимание. А здесь как раз понимания нет. Примерно как когда часовой механизм (который с кучей шестерёнок) разглядываешь. Или когда пытаешься пару десятизначных чисел в уме перемножить. Каждый участок понятен, при взгляде издали «бессознательно всё ясно», но сформулировать необходимый ответ уже никак.

упрощают задачу с помощью абстракций

Мне так не кажется. Паттерны не упрощают алгоритмы, они упрощают выбор формы описания алгоритма. Примерно как наличие существительных и прилагательных в языке не упрощает процесс формирования мысли, но упрощает процесс её высказывания. То есть, в языке с существительными и прилагательными не удастся сформулировать более сложную мысль, чем в языке, где слова не делятся на существительные и прилагательные.

шиз который из крайности в крайность мечется.

Не добавить не убавить. Очень верное определение.

Мне так не кажется. Паттерны не упрощают алгоритмы, они упрощают выбор формы описания алгоритма.

Паттерны это самостоятельные мысленные объекты со своими свойствами, ими проще думать чем кучкой классов. Упрощаем задачу для мозга.

Можно просто подумать о том что вот тут у нас будет прокси, а сколько в этом прокси будет классов и как он вообще будет работать нас пока не интересует, мы об этом потом подумаем.

Ну можно сказать что это способ деления задачи на более мелкие.

Что предлагаете взамен? Километровые switch case?

Это тоже слишком комфортно, только if else, только хардкор. Я реально видел такой код, процедуры на несколько сотен строчек из набора if else

Паттерны это самостоятельные мысленные объекты со своими свойствами, ими проще думать чем кучкой классов. Упрощаем задачу для мозга.

На алгоритм задачи паттерны никак не влияют. Даже ООП на алгоритм задачи не влияет. А для решения сначала нужен алгоритм, а уже потом перевод этого алгоритма на конкретный язык программирования (и тут уже будут объекты в Java, классы типов в Haskell, простые структуры на Си, …).

вот тут у нас будет прокси, а сколько в этом прокси будет классов и как он вообще будет работать нас пока не интересует, мы об этом потом подумаем

Это просто откладывание решения задачи. Например, надо вывести на экран список элементов из заданного множества с наибольшей суммой, не превышающей данную. И программист вместо решения задачи сначала пишет программу, которая выводит список элементов. Потом пишет класс для множества элементов. Потом интерфейс для наследника этого класса, с методом «вернуть список с наибольшей суммой, не превышающей данную». И только потом начинает решать задачу.

Кефир вреден?

На алгоритм задачи паттерны никак не влияют.

А что ты понимаешь под алгоритмом? Например у нас задача написать форум, какой у форума алгоритм? Набор сценариев работы?

И программист вместо решения задачи сначала пишет программу, которая выводит список элементов. Потом пишет класс для множества элементов. Потом интерфейс для наследника этого класса, с методом «вернуть список с наибольшей суммой, не превышающей данную». И только потом начинает решать задачу.

Как это только потом? А вот эти классы и интерфейсы это не часть решения задачи?

какой у форума алгоритм?

Алгоритм формирования главной страницы. Алгоритмы реакции на элементы управления. Они почти все тривиальны и пишутся без включения головного мозга, хотя писанины может быть много.

А вот эти классы и интерфейсы это не часть решения задачи?

Это часть описания, но не часть решения. Также как в алгоритме Евклида текст «Даны два целых неотрицательных числа a и b. Требуется найти их наибольший общий делитель, т.е. наибольшее число, которое является делителем одновременно и a и b.» не является частью решения.

Но если мы меняем условие на более удобное это часть решения. Например если нам в математике нужно что то доказать мы можем доказать от обратного, перевернуть условия задачи.

Ну и вообще, что бы запилить где то интерфейс нужно понимать зачем он там нужен и кого он будет контролировать. Об этом нужно подумать, каким образом это превратилось в часть условия задачи?

нужно понимать зачем он там нужен и кого он будет контролировать. Об этом нужно подумать, каким образом это превратилось в часть условия задачи?

А это разве не часть условия? Или «зачем он там нужен и кого он будет контролировать» выводится из каких-то других условий? И даже если так, то программист не пишет это в тексте программы, поэтому относительно программы это точно часть условия задачи.

Например если нам в математике нужно что то доказать мы можем доказать от обратного, перевернуть условия задачи.

Мы не меняем условие. Мы утверждаем, что для того, чтобы доказать А, нам достаточно доказать, что не-А приводит к противоречию. Это часть решения (математического).

А это разве не часть условия? Или «зачем он там нужен и кого он будет контролировать» выводится из каких-то других условий? И даже если так, то в программист не пишет в это в тексте программы, поэтому относительно программы это точно часть условия задачи.

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

Мы не меняем условие. Мы утверждаем, что для того, чтобы доказать А, нам достаточно доказать, что не-А приводит к противоречию. Это часть решения (математического).

Мы создаем новую задачу, решение которой приводит к решению изначальной, или можно сказать что меняем условия задачи.

Нифига не понял, интерфейсы решают архитектурные задачи, они нужны например для инверсии зависимостей.

Интерфейс - да. «зачем он там нужен и кого он будет контролировать» – часть условия задачи.

Решение возможных проблем это часть решения задачи.

А указание возможных проблем – часть условия.

Так программист сам должен найти эти проблемы, это его задача.

Мы создаем новую задачу, решение которой приводит к решению изначальной, или можно сказать что меняем условия задачи.

Создание нового объекта никак не равносильно модификации существующего.

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

Да, но если из основной задачи делается одна подзадача которой достаточно для решения основной это принято называть «поменяли условие задачи»

Так программист сам должен найти эти проблемы, это его задача.

Сам найди проблемы, сам реши… Если заказчик явно не указывает проблемы и задача одноразовая, то данное условие на усмотрение программиста (и решается простейшим способом из доступных, в ООП языках – паттернами).

Я уже поднимал вопрос, как надо решать задачу «вернуть сумму чисел от 1 до 100»? Варианты от return 5050, до fold(sum, range(1, 100)). Все «правильные».

Сам найди проблемы, сам реши… Если заказчик явно не указывает проблемы и задача одноразовая, то данное условие на усмотрение программиста

Если насрать на репутацию то да) так и есть)

Это вопрос качества решения задачи.

У тебя какой то очень бюрократический взгляд на все это.)

Еще можно сказать, заказчик просил написать форум но не уточнил что он должен запускаться и работать.

принято называть «поменяли условие задачи»

Хорошо. В этом смысле, это часть решения. Но в программировании решением является алгоритм, а не доказательство. И алгоритм от формата его представления не зависит.

Гм… Если решением считать текст программы, тогда классы и интерфейсы являются частью решения. Но, по-моему, результатом работы программиста является алгоритм. А текст программы является его представлением, также как для математика текст на русском языке является представлением доказательства теоремы (и аналогично для текста существенно разбиение на предложения и абзацы, введение терминов или использование словосочетаний, но на доказательство всё это не влияет).

Алгоритм это продукт жизнедеятельности программиста. А все что приводит к получению этого алгоритма это часть процесса решения.

заказчик просил написать форум но не уточнил что он должен запускаться и работать.

Запуск и работа является критерием написанности. А вот, например, если заказчик не уточнил язык программирования, то у меня два сайта на Racket и крупная программа с интерфейсом на Tcl/Tk.

Классы, ООП и паттерны не помогают родить алгоритм. Они помогают только оформить готовый алгоритм в текст программы.

Классы, ООП и паттерны не помогают родить алгоритм. Они помогают только оформить готовый алгоритм в текст программы.

У тебя какой то карго культ на алгоритмы, решением задачи может стать взятие готового движка форума, задача будет решена.

Это вопрос качества решения задачи.

Как надо решать задачу «вернуть сумму чисел от 1 до 100»? Какое из решений return 5050 или return fold(sum, range(a, 100)) (с вспомогательными fold, sum, range) качественней?

решением задачи может стать взятие готового движка форума, задача будет решена.

Верно. И тогда именно работы программиста нет. Есть работа дизайнера и продажника. Так 1C-Bitrix «внедряют».