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

[Исмаил Прокопенко]

Цитата AVA12 @ 06.11.16, 15:04

Не могу представить такую ситуацию.

Вот и я не могу.
Представить, чтобы кто-то смог сразу безошибочно определить все кортежи всех взаимосвязанных классов.
А ООП именно этого требует.

[applegame]

Цитата Исмаил Прокопенко @ 06.11.16, 15:54

Тем что эти "детали" зависят от реализации внешних классов

Далеко не всегда зависят. Писать надо грамотно, чтобы не связанные классы не зависели от реализации друг-друга.

[Исмаил Прокопенко]

Цитата applegame @ 06.11.16, 15:58

Почему обязательно классы?

Ну если пишем простые программы уровня "Халлоу! Ворлд!" и используем только базовые/зарезервированнные типы параметров и полей то да,проблем нет.
А если писать что-то сложней "Халлоу! Ворлд!"?

Добавлено 06.11.16, 16:05

Цитата applegame @ 06.11.16, 16:02

Писать надо грамотно, чтобы не связанные классы не зависели от реализации друг-друга.

Просветите как.
Как можно написать класс-параметр метода другого класса так, чтобы его можно было менять как угодно "не оглядываясь" на класс, в котором этот класс используется как параметр (соответственно внутри класса юсается интерфейс класс-параметра)

[applegame]

Цитата Исмаил Прокопенко @ 06.11.16, 16:03

Ну если пишем простые программы уровня "Халлоу! Ворлд!" и используем только базовые/зарезервированнные типы параметров и полей то да,проблем нет.
А если писать что-то сложней "Халлоу! Ворлд!"?

Я же написал - интерфейсы и параметры шаблона. Что непонятного? Определение класса зависит от интерфейса, но не от реализации внешнего класса. Эта реализация вообще может быть в другой библиотеке. О какой зависимости вы тут глаголете?

Добавлено 06.11.16, 16:06

Цитата Исмаил Прокопенко @ 06.11.16, 16:03

Просветите как.
Как можно написать класс-параметр метода другого класса так, чтобы его можно было менять как угодно "не оглядываясь" на класс, в котором этот класс используется как параметр (соответственно внутри класса юсается интерфейс класс-параметра)

На каком языке вам написать пример?

[Исмаил Прокопенко]

Ведь что получается.
Если ты в методе класса Y в типе параметра указал некий класс Z, то для Z это означает, что ты не можешь менять его без оглядки на Y (без "согласия" на это класса Y).

Добавлено 06.11.16, 16:10

Цитата applegame @ 06.11.16, 16:05

Я же написал - интерфейсы и параметры шаблона. Что непонятного?

ВСЁ непонятно.
Наверное я дурак.
Извольте объяснить "на пальцах"

[applegame]

Цитата Исмаил Прокопенко @ 06.11.16, 16:09

Ведь что получается.
Если ты в методе класса Y в типе параметра указал некий класс Z, то для Z это означает, что ты не можешь менять его без оглядки на Y (без "согласия" на это класса Y).

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

Сообщение отредактировано: applegame - 06.11.16, 16:14

[Исмаил Прокопенко]

Цитата applegame @ 06.11.16, 16:05

На каком языке вам написать пример?

На С++ естественно.
Тут 84% участников в основном на нем пишут

[AVA12]

Цитата

А классы-параметры?
А классы-поля?

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

Цитата

Цитата

Нифига. В прцедурном подходе

А при чем тут он?
Я о нем не говорил.

Хорошо, тогда ООП усложнил программирование по сравнению с чем?

Цитата

Цитата

Чем не нравится сокрытие деталей реализации?

Тем что эти "детали" зависят от реализации внешних классов

И как же детали реализации одного класса зависят от деталей реализации другого класса? Можно пример?

Цитата

Если ты в методе класса Y в типе параметра указал некий класс Z, то для Z это означает, что ты не можешь менять его без оглядки на Y (без "согласия" на это класса Y).

Неверно. Можно вносить изменения, не противоречащие исходному контракту. А если контракт изначально хреновый, значит проектировщик никудышный. Это не проблема ООП, при других подходах тоже могут быть ошибки проектирования.

[Исмаил Прокопенко]

Цитата applegame @ 06.11.16, 16:12

Что именно менять нельзя? ....Интерфейс менять нельзя,

Вот вот.
А я разве про это не сказал?

Цитата Исмаил Прокопенко @ 06.11.16, 11:31

Т.е. при проектировании ты должен, как минимум, продумывать имена и сигнатуры методов СРАЗУ ВСЕХ взаимосвязанных классов и потом не можешь их менять. Вот где попа.

СРАЗУ ВСЕХ, Карл.

И это называется "решать задачу по частям"?

Не читали?
Но осудили

Добавлено 06.11.16, 16:25

Цитата AVA12 @ 06.11.16, 16:19

И как же детали реализации одного класса зависят от деталей реализации другого класса? Можно пример?

Да ради Бога.
К примеру в списке параметров метода g класса X есть объект h класса Y.
И теле g по полной юсается интерфейс класса Y.

А теперь скажите мне: как Вы сможете "КАК УГОДНО" менять интерфейс класса Y не оглядываясь на класс X?

Добавлено 06.11.16, 16:28

Цитата AVA12 @ 06.11.16, 16:19

Можно вносить изменения, не противоречащие исходному контракту. А если контракт изначально хреновый, значит проектировщик никудышный. Это не проблема ООП,

Это проблема ООП.
Так как программист вынужден СРАЗУ/ОДНОВРЕМЕННО продумывать контракты (в Вашей терминологии) СРАЗУ ВСЕХ взаимодействующих классов. И потом уже не может их безболезненно менять

[applegame]

Цитата Исмаил Прокопенко @ 06.11.16, 16:21

Вот вот.
А я разве про это не сказал?

А что у вас есть альтернативы ООП, у которых есть возможность менять интерфейсы без каких-либо последствий?

Добавлено 06.11.16, 16:40

Цитата Исмаил Прокопенко @ 06.11.16, 16:21

Да ради Бога.
К примеру в списке параметров метода g класса X есть объект h класса Y.
И теле g по полной юсается интерфейс класса Y.

А теперь скажите мне: как Вы сможете "КАК УГОДНО" менять интерфейс класса Y не оглядываясь на класс X?

Вы не путайте интерфейс и реализацию - это разные вещи. А то вас трудно понять. Говорят про реализацию, а вы толкаете про интерфейсы.

Сообщение отредактировано: applegame - 06.11.16, 16:41

[AVA12]

Цитата

К примеру в списке параметров метода g класса X есть объект h класса Y.
И теле g по полной юсается интерфейс класса Y.

А теперь скажите мне: как Вы сможете "КАК УГОДНО" менять интерфейс класса Y не оглядываясь на класс X?

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

Раз уж речь идет о малопригодности парадигмы, значит есть реальные, конкретные причины для таких жалоб? Нужен конкретный пример: исходные классы/инерфейсы/примеси, исходный контракт (что на входе, что на выходе, поподробнее), итоговая ситуация, при которой необходимо переделывать контракты. А иначе эти жалобы - пустой треп.

Цитата

Это проблема ООП.

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

Цитата

Так как программист вынужден СРАЗУ/ОДНОВРЕМЕННО продумывать контракты (в Вашей терминологии) СРАЗУ ВСЕХ взаимодействующих классов. И потом уже не может их безболезненно менять

Однако же огромные программные комплексы как-то создаются, причем не отдельными программистами, а коллективами (это дополнительные затраты на всякие согласования). Если парадигма работать не может, как же она тогда работает?

P. S. И все-таки, по сравнению с чем ООП усложнил программирование?

[Исмаил Прокопенко]

Цитата applegame @ 06.11.16, 15:58

шаблона

Шаблоны - это уже не ООП, другая парадигма. МЕТАпрограммирование

Добавлено 06.11.16, 17:57

Цитата AVA12 @ 06.11.16, 16:58

Вы не путайте интерфейс и реализацию - это разные вещи. А то вас трудно понять. Говорят про реализацию, а вы толкаете про интерфейсы.

Я говорил про то, что НЕВОЗМОЖНО менять КАК УГОДНО (хошь интерфейс, хошь реализацию) класс-параметр и класс-поле "без оглядки" на класс, в котором находятся эти параметры и поля. Т.е. налицо ЗАВИСИМОСТЬ.
А то, что я НЕ говорил - не надо мне приписывать или ДОДУМЫВАТЬ.

Добавлено 06.11.16, 18:02

Цитата AVA12 @ 06.11.16, 16:58

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

Не надо передергивать.
Если "парадигма" говорит, что можно разбивать задачу на НЕЗАВИСИМЫЕ куски и прорабатывать их по отдельности (они же независимы), а по факту это не так, то ДЕРЬМО это, а не парадигма.

И по факту получается, что никакого облегчения нет.
И программист должен решать задачу не по частям, не по методу "последовательного уточнения", а должен БЕЗОШИБОЧНО расписать СРАЗУ ВСЕ кортежи зависимых классов.
А если классов больше сотни и в каждом по 10 и более кортежей?
А в каждом кортеже по 5 и более слотов?

Получается полная задница

Добавлено 06.11.16, 18:04
И не дай Бог вам ошибиться хотя бы в одном слоте из нескольких тысяч.
Обретете такой гимор, что проклянете тот день, когда родились на свет

Добавлено 06.11.16, 18:07

Цитата AVA12 @ 06.11.16, 16:58

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

"В огороде бузина, а в Киеве - дядько"(с)
Давайте все же Вы не будете скатываться на откровенный троллинг

Добавлено 06.11.16, 18:10

Цитата AVA12 @ 06.11.16, 16:58

Однако же огромные программные комплексы как-то создаются

Вот именно "как-то".
Годами и ДЕСЯТИЛЕТИЯМИ создается то, что можно было создавать за пару недель.
Зато все счастливы и программисты чувствуют себя важными людьми, надувают щёки и получают хорошие зарплаты.

Хотя можно было из 10 тыс. программистов оставить одного который бы делал даже больше.

[AVA12]

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

Цитата

Давайте все же Вы не будете скатываться на откровенный троллинг

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

Цитата

Годами и ДЕСЯТИЛЕТИЯМИ создается то, что можно было создавать за пару недель.

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

Заменить десятилетия коллективного труда на две недели индивидуального - это бред. Кнопку "сделать базу данных, чтоб работала" еще не изобрели.

P. S. И еще раз: по сравнению с чем ООП усложнила программирование?

[Исмаил Прокопенко]

Цитата AVA12 @ 06.11.16, 18:43

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

Кто Вам сказал не получается? Получается.
Если долго мучиться можно и баобаб в 3 обхвата спилить зубочисткой.

Я лишь пытаюсь донести мысль, что это гиморно.

"Почему" повторять? Или Вы все же потрудитесь прочитать и, главное, понять, то, что я сегодня написал в этой теме? Или будете даже не попытавшись разобраться в том, что я пишу, продолжать уверять меня, что я не прав (по принципу "не читал, но осуждаю"(с)) задавать мне миллион вопросов?

Добавлено 06.11.16, 19:01

Цитата AVA12 @ 06.11.16, 18:43

Заменить десятилетия коллективного труда на две недели индивидуального - это бред.

Почему бред?

Вы же сами сказали

Цитата AVA12 @ 06.11.16, 18:43

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

Добавлю лишь, что сейчас студент окончивший первый курс технического ВУЗа знает больше об устройстве вселенной, чем лучшие умы, академики 17-го века.

Добавлено 06.11.16, 19:03

Цитата AVA12 @ 06.11.16, 18:43

Кнопку "сделать базу данных, чтоб работала" еще не изобрели.

Надеюсь Вы не будете отрицать, что сейчас студент троечник 2-го курса, который учится на программиста ЗАПРОСТО напишет программу над которой 40 лет назад бились огромные коллективы лучших программистов?

[AVA12]

Цитата

Или Вы все же потрудитесь прочитать и, главное, понять, то, что я сегодня написал в этой теме?

Что ж тут понимать? Голые декларации в духе "все пропало, куда катится мир!", без реальных примеров. Оснований доверять вашим словам нет никаких.

Цитата

Почему бред?

Вы же сами сказали

Извиняйте, таблички "сарказм" у меня при себе нет.

Цитата

сейчас студент троечник 2-го курса, который учится на программиста ЗАПРОСТО напишет программу над которой 40 лет назад бились огромные коллективы лучших программистов?

С помощью ООП? Ну вот, а говорите, что ООП все только усложняет!

Над чем могли 40 лет назад трудиться целые коллективы программистов?
Операционные системы, потребляющие минимум ресурсов тогдашних машин и дающие максимальную производительность и функциональность? Боюсь, даже в наши дни такие задачи далеко не тривиальны.
Специфические расчетные задачи? Ну, при наличии специфических библиотек и на современном железе, пожалуй, можно осилить. А вот с нуля и чтоб сразу работало - сомневаюсь.

Технологический разрыв между нынешним днем и, скажем, прошлым десятилетием совсем мал, так что вместить несколько человековеков в две человеконедели (угу, миллион строк отлаженного и документированного кода в день) - это наивно. Даже если снизить планку в разы - все равно нереально. Сможете ли вы за две недели воспроизвести с нуля, скажем, MS-DOS 6.22? Боюсь, только на чтение документации (что гораздо легче, чем написание документации) уйдет больше времени.

P. S. Ну, вы поняли.