Обновить
1
2.3

Специалист по теории типов USB-кабелей

Отправить сообщение

А какие из новых идей, опробованных в C++, оказались хорошими?

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

Что такое классическое ООП? Что значит его там нет?

Снова вопрос определений, но для меня лично его наличие в языке — это когда язык позволяет

  1. легко инкапсулировать данные на уровне класса, а не модуля (в коде выше на go нигде не написано, что только функция Say может дёргать name)

  2. легко описывать наследование (а не как в C, где можно обмазаться агрегированием и ЕМНИП явными кастами, конечно, но это больно и нетипобезопасно)

  3. легко описывать полиморфизм подтипов (а не снова как в C, где всё опять на кастах и закате vtbl солнца руками)

Уточню свой исходный вопрос: можете привести пример наиболее популярного, на ваш взгляд, типизированного языка, для которого верно утверждение «классического ООП там нет» (с которым вы изначально спорили)?

Буквально нет никакой смысловой разницы.

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

Не совсем так

Почему? Вот я беру код выше на go и портирую его на C, с точностью до синтаксиса:

typedef struct User
{
  char *name;
} User;

void say(User *u)
{
  printf("%s", u->name);
}

Если гошный User — класс, а Say — его метод, то и здесь User — класс, а say — его метод.

Пропозал на uniform call syntax в C++ сделал бы это менее глупым вопросом, чем кажется, к слову.

Ключевых слов я не вижу

Я их дальше привёл. Можно попробовать прочитать следующий абзац.

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

Тем не менее, не понял связи. Зачем здесь какие-то слова? В каком смысле «где живут»?

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

Можно сделать s/диалектика/религия/g и получится примерно настолько же корректное высказывание.

Распарсенный XML (nodes), в ОЗУ нужно хранить в объектах

Зачем? Вот вам описание типа для XML-узлов на хаскеле (который вот совсем не ООП-язык):

data XmlNode
  = TagNode { name :: String, attrs :: [Attribute], children :: [XmlNode] }
  | TextNode { text :: String }

А в этой статье автор пишет, что ООП скам. Нужно всему верить?

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

Впрочем, видеть вопрос «нужно всему верить?» от человека, до того пишущего «я не копал, но уверен» смешно.

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

Вот как раз про браузеры чувак даёт доклад с говорящим названием OOP Is Dead, Long Live Data-oriented Design.

Зачем вам ООП для XML-парсера?

Правда что ли? Ну, скажите, как они называются.

Например, функции (конвертирующие одни типы в другие). Или, например, события и реакции на них.

Не, серьёзно, DDD настолько естественно, что когда я прочёл пару книжек про DDD, то выяснил только то, что именно так и называется то, чем я давно занимался в ФП. Там, конечно, дают явные названия для этих инструментов, но они естественные, и скорее отражают организационную структуру, чем код. Ну там, shared kernel для ограниченных контекстов, соответствующих тесно связанным бизнес-процессам, или upstream/downstream, когда одна команда (бизнес-процесс)не может влиять на язык другой команды, но другая команда (бизнес-процесс) всё равно DDD, или anticorruption layer, когда другая команда — не DDD.

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

Диалектика противоречива в той мере, в которой противоричивы явления объективной действительности

Явления объективной действительности не противоречивы. Диалектика по описательной силе сравнима со средней религией: можно сделать вид, что описываешь что угодно, но на самом деле не описывается ничего.

Однако обсуждать диалектику здесь - это офтопик.

Только когда речь заходит о том, что диалектика — так себе инструмент, конечно :]

А можно примеры типизированных языков, где в ваших терминах нет методов класса? А то выходит, что даже в C есть классы и у них есть методы.

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

Почему? Там есть куча инструментов для этого, и они настолько естественны, что о них даже не задумываешься.

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

Проблема с диалектикой в том, что она логически противоречива, поэтому она применима ко всему (одинаково плохо).

Думаю, стоит разделять вопросы «почему?» и «зачем?» — у первого больше коннотаций причин, у последнего — целей (например, спрашивать «почему яблоки падают вниз?» норм, а «зачем яблоки падают вниз?» как-то даже звучит глупо, как по мне).

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

Так вот, вы отвечаете на вопрос «почему?». Я с этим вопросом не спорю и его даже не задаю — в конце концов, у меня тоже есть опыт, например, когда на работе была некоторая ерунда, ощущавшаяся как адская несправедливость, и я после работы её в голове прокручивал, и прокручивал, и прокручивал… Только потом я понял, что это непродуктивно, потому что стратегию поведения это вырабатывать не помогает, а только тратит моё личное время и эмоциональные ресурсы на какую-то бессмысленную ерунду. Вроде собирался вечером кардио поделать, на дорожке всякие там научпоп-новости почитать, а в итоге одна статья на одном месте открыта уже полчаса, а я всё прокручиваю, и прокручиваю, и прокручиваю…

Можно научиться этого не делать. Со способностями «легко забывать о рабочих проблемах» я тоже, тащем, не родился, но непродуктивные, неприятные проблемы (множество которых почему-то почти целиком совпадает со множеством проблем, понятных человеку вне отрасли) можно научиться выкидывать. А продуктивные, приятные проблемы («ну как же вот решить эту архитектурную задачу/ускорить этот кусок кода/етц») выкидывать даже, я бы сказал, и не нужно — мне их обдумывание вообще заснуть помогает, например. Но ими с другим человеком не поделишься, если он не то что вне отрасли, а вне конкретной предметной темы.

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

И для них психологическая поддержка — часть хорошего партнёрства. Даже если близкий не разбирается в теме и не может дать конструктивных советов — его моральная поддержка, даже на уровне «Вот козлы!», снижает стресс.

Я, наверное, слишком эмоционально тупой, чтобы «просто выговориться» для меня работало. Обсудить проблему и прийти к решению — да. Но просто обсуждать проблему без даже надежд на решение — это даже обсуждением язык назвать не поворачивается.

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

это не догма а принцип ddd

Для выражения которого ООП совершенно не нужен. DDD отлично делается на функциональных языках.

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

Так же, как не обсуждать с любым другим человеком. Зачем обсуждать негатив, переваривая его что в своей голове, что выплёскивая его на другого человека?

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

Нет, зачем? Это ж не TLA+ какой-нибудь.

Или вы считаете, что успешность передается по наследству?

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

Это начинает сильно пахнуть спором об определениях.

Для меня ситуация «люди из локации A массово передвигаются в локацию B потому, что локация B предоставляет существенно лучшие условия» является одним из примеров «люди бегут от ситуации в B». Можно, конечно, обсуждать, что такое «массово», но 60-кратная разница в потоках для меня также подходит под «массово».

А так по цифрам это обычная трудовая мобильность.

Это если бы люди более-менее равномерно ездили между всеми локациями. Вот если условный поток норвежцев в Швецию — пусть даже 10 на 1000 норвежцев (втрое больше, чем в США), но и поток шведов в Норвегию — 10 на 1000 шведов, то тогда да, это мобильность. Если поток сильно несбалансирован, то это не мобильность, а бегство, опять же.

Что толку от свободы слова, если твоя свобода действовать (пусть даже путём голосования) ограничена?

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

Тоже, увы, содержит парадокс: есть риски, которые для своей нейтрализации потребуют создания государства или его эквивалента.

Например?

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

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

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

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

— ровно поэтому я считаю, что эти риски меньше, чем от ограничений, и чем от наличия самого фреймворка для ограничений.

Культурно гомогенные suburban/rural areas в США, например (не все suburban/rural areas таковыми являются, конечно).

Обратите внимание: примеров и обоснований по вашим 99% процентам так и нет, но вместо этого обсуждается только опровержение постулируемого вами тезиса про эти 99%.

За счет каких средств это делается? Это важный вопрос.

За счёт того же эффекта масштаба, например. Половину от сэкономленного доллара можно оставить себе, половину — раздать расстановщикам товаров.

В моем понимании, 30 тысяч в год для Штатов это почти нищета. Аж жалко их там стало!

Официальная черта нищеты — 15 тыщ в год, что ли. А тут вдвое больше платят за работу, которая требует ноль квалификаций.

А в каком перцентиле по зарплатам должны оказаться расстановщики товаров, к которым ноль требований и квалификаций?

Зачем (снова)?

Работодателя объём выполняемых работ устраивал. На тех работах, где нужно было реально работать 6-8 часов в сутки, предлагают 350-500. Это заставляет считать, что обмен труда на деньги был справедливым (то бишь, на пересечении обоюдно устраивающих диапазонов курса этого обмена).

Информация

В рейтинге
1 164-й
Зарегистрирован
Активность