Здравствуйте, gyraboo, Вы писали:

G>А, ясно. Не знал такого термина, поэтому не заметил.

https://en.wikipedia.org/wiki/Leaky_abstraction

Здравствуйте, gyraboo, Вы писали:

BFE>>Абстракция в ООП — это возможность совершать операцию над неопределённым множеством разнотипных объектов (или же метод позволяющий исполнить такую возможность).

G>Не совсем корректная формулировка. Ведь все эти разнотипные объекты все же состоят в отношениях с абстракцией ("is a" в случае наследования или "realize" в случае реализации). Поэтому говорить, что эти объекты разнотипны — это не совсем корректно. Их типы всегда имеют одним из базовых типов тип абстракции.

Нет. Объекты вообще могут быть без базовых классов, без наследования.

G>Кроме того, есть абстракции, выделенные по признакам (полям), а не по операциям, поэтому возможность совершать операцию — это не определение того что такое абстракция.
G>Я думаю так: Абстрагирование — это создание типа, обобщающего множество объектов разных подтипов. Абстракция — это сам обобщающий тип.

Нет, абстракция может быть функцией без объекта. Типичный пример — это функция сортировки, которая в качестве параметра берёт оператор сравнения сортируемых объектов. В С++ это std::sort. В общепринятой терминологии такие функции называют обобщёнными, чтобы отличать их от виртуальных. Однако следует ясно понимать, что и те и другие позволяет реализовать полиморфизм, а значит работать с объектами на абстрагированном уровне.

G>К сожалению ты не понял мою мысль, а я не могу её донести.
Я прекрасно понимаю, что вы пытаетесь сказать, но я так же понимаю и Умака Кумакаки.

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

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

Здравствуйте, mgu, Вы писали:

BFE>>Вы понимаете, что с какой планкой в компании будут работать только начинающие программисты?
mgu>В многоклеточной компании существует разделение труда.
mgu>А мне грустно: проскакивала информация, что в Гугле яйцеголовых бросают на цензурирование высказываний в Ютубе.

Такое впечатление, что ваше подсознание не даёт вам понять то, что вы знаете.

Здравствуйте, Умака Кумакаки, Вы писали:

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

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

Здравствуйте, mgu, Вы писали:


mgu>А вашему начальнику не нужны профессионалы: они же, канальи, всё сделают за полгода, и система будет работать как часы. Затем профессионалы откочуют в другую контору, а куда деваться начальнику?
Ага, ага, вот так все возьмут, и напишут.
вообще-то у бизнеса хотелок всегда больше, чем ресурсов для их реализации.

mgu>Так в этом весь смысл! Именно под неспешное переписывание и можно выбить ресурсы. Все программные задачи уже давно решены, либо же собираются Питоном из библиотек.
Ты пробовал выбивать ресурсы под неспешное переписывание?
Если программные задачи уже решены, нафига переписывать-то? Ресурсов не дадут. А даже наоборот, отнимут.
А вот если задачи в бэклоге плодятся как кролики, если команда больше половины времени разгребает инциденты, если проект сменил несколько поколений разрабов и никто реально не понимает, ка он работает — вот тогда как раз и нужно переписывать.
Но переписывать не дадут. А если датут — то выделят, скажем, год на переписывания системы, которую писали 15 лет. И это будет заведомо провальный проект.
Но можно сцепив зубы постепенно отпиливать кусочки от существующего монолита. Или распределенного монолита. Постоянно выбивая у бизнеса ресурсы на рефакторинг и доказывая что когда-нибудь это сократит поток инцидентов и time-to-market. И это можно сделать. Все можно. Только где вот тут неспешность?

Здравствуйте, Gradiens, Вы писали:

mgu>>А вашему начальнику не нужны профессионалы: они же, канальи, всё сделают за полгода, и система будет работать как часы. Затем профессионалы откочуют в другую контору, а куда деваться начальнику?
G>Ага, ага, вот так все возьмут, и напишут.
G>вообще-то у бизнеса хотелок всегда больше, чем ресурсов для их реализации.

Нет ресурсов -- нет фронта работ. Есть ресурсы -- перетасовываем кнопки, это недолго.

mgu>>Так в этом весь смысл! Именно под неспешное переписывание и можно выбить ресурсы. Все программные задачи уже давно решены, либо же собираются Питоном из библиотек.
G>Ты пробовал выбивать ресурсы под неспешное переписывание?

Винчестер выбить не могу. Но я не специалист по выбиванию.

G>Если программные задачи уже решены, нафига переписывать-то? Ресурсов не дадут. А даже наоборот, отнимут.
G>А вот если задачи в бэклоге плодятся как кролики, если команда больше половины времени разгребает инциденты, если проект сменил несколько поколений разрабов и никто реально не понимает, ка он работает — вот тогда как раз и нужно переписывать.

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

G>Но переписывать не дадут. А если датут — то выделят, скажем, год на переписывания системы, которую писали 15 лет. И это будет заведомо провальный проект.
G>Но можно сцепив зубы постепенно отпиливать кусочки от существующего монолита. Или распределенного монолита. Постоянно выбивая у бизнеса ресурсы на рефакторинг и доказывая что когда-нибудь это сократит поток инцидентов и time-to-market. И это можно сделать. Все можно. Только где вот тут неспешность?

А это смотря как взяться и как отчитываться. А год на 15-летнюю систему -- реально, ведь писали-то вслепую, 2 шага вперёд, один шаг назад.

G> А если и осилят, то в конце пути вам вместо награды вручат еще одно легаси ))

Печальный и непреложный факт

mgu>int -- это абстракция, возраст обычно не превышает 120 лет, понадобятся проверки. А можно и чисто конкретно:
mgu>Age age = new Age(33);

Всегда удивляло, почему ратующие за подобную типизацию товарищи все еще не перешли на Haskell или OCAml. Упорно продолжают грызть не приспособленный для этого кактус, и хорошо еще если это Java, а не C++.

G>Но переписывать не дадут. А если датут — то выделят, скажем, год на переписывания системы, которую писали 15 лет. И это будет заведомо провальный проект.
G>Но можно сцепив зубы постепенно отпиливать кусочки от существующего монолита. Или распределенного монолита. Постоянно выбивая у бизнеса ресурсы на рефакторинг и доказывая что когда-нибудь это сократит поток инцидентов и time-to-market. И это можно сделать. Все можно. Только где вот тут неспешность?

Похоже, что у вас есть действительно ценный опыт. Без шуток, описываемое вами — ничуть не редкость, но чаще случается в больших (или очень старых) конторах.

В значительной мере это self-inflicted wound: отсутствие специалиста по маркетингу, который будет "продавать" бизнесу объяснение, что именно дает рефакторинг. Продавать в терминах, понятных этому бизнесу. Одна из реально сложных проблем для инженеров: объяснить с цифрами в руках, как много убытков наносит кривизна здесь, корявость там, и тормоза вот в этом месте.
Но найти таких маркетологов сложно, и еще сложнее убедить бизнес в том, чтобы этого маркетолога нанять.

Здравствуйте, SkyDance, Вы писали:

mgu>>int -- это абстракция, возраст обычно не превышает 120 лет, понадобятся проверки. А можно и чисто конкретно:
mgu>>Age age = new Age(33);

SD>Всегда удивляло, почему ратующие за подобную типизацию товарищи все еще не перешли на Haskell или OCAml. Упорно продолжают грызть не приспособленный для этого кактус, и хорошо еще если это Java, а не C++.

А зачем? Статическая типизация есть статическая типизация. Ну перейдут они на ФП, будут грызть кактус другого порядка.
Сильно не факт, что слаще.

Здравствуйте, SkyDance, Вы писали:

mgu>>int -- это абстракция, возраст обычно не превышает 120 лет, понадобятся проверки. А можно и чисто конкретно:
mgu>>Age age = new Age(33);

SD>Всегда удивляло, почему ратующие за подобную типизацию товарищи все еще не перешли на Haskell или OCAml.

Это был абстрактный пример.

SD>Упорно продолжают грызть не приспособленный для этого кактус, и хорошо еще если это Java, а не C++.

А сейчас даже стало интересно: чем такой код на Джаве лучше, чем на С++?

Здравствуйте, SkyDance, Вы писали:

SD>В значительной мере это self-inflicted wound: отсутствие специалиста по маркетингу, который будет "продавать" бизнесу объяснение, что именно дает рефакторинг. Продавать в терминах, понятных этому бизнесу. Одна из реально сложных проблем для инженеров: объяснить с цифрами в руках, как много убытков наносит кривизна здесь, корявость там, и тормоза вот в этом месте.
SD>Но найти таких маркетологов сложно, и еще сложнее убедить бизнес в том, чтобы этого маркетолога нанять.

Да кого волнует эта корявость? В наши дни ресурсы на рефакторинг выбивают, когда личному составу заняться нечем. А сдувать штат чревато.

S>А зачем? Статическая типизация есть статическая типизация. Ну перейдут они на ФП, будут грызть кактус другого порядка.

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

Другое дело если язык изначально разрабатывается с учетом требований статической типизации. Тот же ocaml, базирующийся на type inference (только не надо про 'auto' в С++, это не одно и то же, — уже даже сама необходимость писать тип auto убивает половину смысла).

mgu>Да кого волнует эта корявость? В наши дни ресурсы на рефакторинг выбивают, когда личному составу заняться нечем. А сдувать штат чревато.

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

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

Здравствуйте, SkyDance, Вы писали:

S>>А зачем? Статическая типизация есть статическая типизация. Ну перейдут они на ФП, будут грызть кактус другого порядка.
SD>Когда сам язык изначально не был предназначен для статической типизации, добавление таковой путем наслоения новых конструкций не добавляет элегантности. Скорее, напротив, становится камнем на шее, только мешающим. И инструментировать такое сложнее, и то что компилятор должен быть навороченнее — не добавляет удобства.

О каком языке идет речь, smalltalk или питоне? Потому как ява/цпп/c# изначально разрабатывались статическими ООП языками.

Здравствуйте, SkyDance, Вы писали:

mgu>>Да кого волнует эта корявость? В наши дни ресурсы на рефакторинг выбивают, когда личному составу заняться нечем. А сдувать штат чревато.

SD>Очень сильное заявление!
SD>Где-то рядом по силе с "кого в наши дни интересует производительность", а также "зачем нужны разработки новых алгоритмов, все уже изобретено".

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

По плодам их узна́ете их. А заявляет начальство обычно про то, что через пару лет "мы порвём Майкрософт", ещё 40 тысяч вёдер, и золотой ключик у нас в кармане!

mgu>По плодам их узна́ете их. А заявляет начальство обычно про то, что через пару лет "мы порвём Майкрософт", ещё 40 тысяч вёдер, и золотой ключик у нас в кармане!

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

Здравствуйте, SkyDance, Вы писали:

mgu>>По плодам их узна́ете их. А заявляет начальство обычно про то, что через пару лет "мы порвём Майкрософт", ещё 40 тысяч вёдер, и золотой ключик у нас в кармане!

SD>К счастью, моему начальству делать такие заявления не требуется. Ибо наш продукт действительно не только лучший, но и самый сильный на рынке. Майкрософту не светит.

Шо за продукт?

Здравствуйте, mgu, Вы писали:

SD>>К счастью, моему начальству делать такие заявления не требуется. Ибо наш продукт действительно не только лучший, но и самый сильный на рынке. Майкрософту не светит.
mgu>Шо за продукт?

WhatsApp.

SD>>>К счастью, моему начальству делать такие заявления не требуется. Ибо наш продукт действительно не только лучший, но и самый сильный на рынке. Майкрософту не светит.
mgu>>Шо за продукт?

S>WhatsApp.

Это та срань, что не позволяет просмотреть сообщения без инета, которые писались на телефоне? И которая не переносит сообщения на другое тело телефона, если я симку поменяю? И которая не дает добавить контакт в нее, а не в стандартную записную книжку?