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

S>>·>Это значки, и в спеке яп = называется словом assignment. А вот flatmap это уже слово и понятие.
S>>О да, это же совсем другое, понимать надо! А я и не понял.
·>Да.

Ожидаемо. Только вот у меня нет столько "Этодругина Форте" чтобы воспринимать ваши виляния всерьез: тут есть в теории, значит минус в карму ЯП, а вот тут нет, ну и пофиг. Тут вот мы требуем flatMap в стандартной библиотеке, а вот тут ее нет ну и пофиг. Тут вот объяснение, но корявое, поэтому оно не определение, а значит и не корявое.

S>>·>Это не правда. В ruby flatten делает то же, что и в scala.
S>>А я и не говорил, что в ruby flatten делает что-то другое.
·>Говорил, цитирую: "совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten".

А теперь найдите где бы я сказал, что в ruby flatten делает что-то отличное от flatten в Scala.

Цепочка моих рассуждений, если что, была такой:

cppguard заявляет, буквально: "Во всём остальном мире flat-map это превращение древовидной структуры в плоскую".
Здесь нет flatMap = map + flatten, здесь только про превращение древовидной структуры в плоскую, это как раз то, что делает flatten.

Потом появляется комментарий от dsorokin: "В Scala название flatMap обозначает монадическую связку (она же известна в других языках как bind, and_then, then и даже как ">>=") — соединяет одно вычисление с другим, создавая новое комбинированное", на которого я и ссылаюсь.

Что и позволило мне сказать, что заявляемый cppguard-ом общеизвестный flat-map в случае Ruby делается flatten-ом, а в случае Scala flatMap означает вообще другое.

S>>·>ЕЩЁ раз: flatmap = flatten + map уже пол века, везде, повсюду, кроме С++.
S>>Кстати, ссылку на Python вы дали на NumPy, а не на стандартную библиотеку Python-а.
·>И что?

И все.

·>Ещё раз, для тормозов

Претензии здесь высказываются к стандартной библиотеке C++, в качестве примера приводится Python, в котором flat_map нет вообще. Вот это поворот!

Ах да, это же другое.

·>Пустое заявление.

И это тоже другое.

·>Ты не понял, я уточнил, и процитировал формальные определения.

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

·>Во следующем предложении после процитированного: "The user can access elements by their integer index (position in the list), and search for elements in the list.

Так вот про это и был комментарий: "От оно чё. List -- это пронумерованная, оказывается. Ну OK."

Для вас список, в котором есть доступ по индексу, возможно, нормален. А вот как быть тем, кто считает это маразмом? Им жаловаться на прохой нейминг в Java? Бегать по форумам и писать "и только в Java такая херня"? Или просто пожать плечами, сказать "ну здесь так" и спокойно себе кодить на Java?

S>>А у элемента списка номер нужно вычислять.
·>И что?

И все. Хотя нет, у вас это опять пойдет по категории "это другое".

S>>·>Вот при обходе множества — номера вычислить не получится, нет однозначного соответсвия.
S>>А здесь вы определитесь говорите ли вы про математическое понятие "множества" или про тип данных.
·>я надеялся abstract_data_type будет очевидной инфой.

Зря. Потому что я не понимаю, у вас abstract data type -- это уже про программирование и про реалиазации этих самых абстрактных типов данных в ЯП, или это все еще теория.

S>>Если про тип данных и у вас есть детерминированный способ
·>Если бы кабы... А кто его вам даст и с каого бодуна?

Да как бы общепринятая вещь для реализаций такого понятия, как "множество". Например, в Java интерфейс Set наследуется от Iterable. Про C++ вообще очевидно. В Python-е используется for x in set.

·>Это очередная безграмотность. У тебя может быть два эквивалентных множества, но например, созданных по-разному, которые будут выдавать разные номера для тех же элементов в зависимости от фазы луны.

Могут быть. Поэтому я и сказал "Если ... есть детерминированный способ". Очевидно, что если у вас такая реализация Set, которая при каждой итерации выдает элементы в другом порядке, то пронумеровать их не получится.

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

S>>Как я и говорил в той теме -- нужно выяснить коэффициент доверия к вашим словам.
C>Кому нужно?

Как минимум мне.

S>>И да, мне таки интересно, кто же такие эти самые "нормальные инженеры". Возможно, интересно это не мне одному.
C>Которые пишут код для критически важных систем. Такое определение сойдёт?

Нет.

S>>А вы уже основали свою?
C>Спорить с претензией на элитарность и использовать аргумент "сперва добейся"? Ясно-понятно.

И вот все у вас так: это же вы первым завели шарманку из категории "сперва добейся", вот, цитирую:

Вот когда вы станете основателем компании и будете смотреть

Типа "когда достигнешь, тогда поймешь".

C>Но таки да, основал.

Хорошо, значит в этом смысле мы можем поговорить на равных.

S>>Ну вы бы хоть краткий список таковых предоставили, а то к тем, что вспоминается мне, C++ вообще не имеет отношения.
C>Безопасный код? Сложность кода?

Тю. И это, по вашему, фундаментальные проблемы?

По секрету: безопасность кода слабо коррелирует с ЯП.
А уж сложность кода вообще штука безотносительная языка программирования.

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

S>cppguard заявляет, буквально: "Во всём остальном мире flat-map это превращение древовидной структуры в плоскую".
S>Здесь нет flatMap = map + flatten, здесь только про превращение древовидной структуры в плоскую, это как раз то, что делает flatten.

S>Потом появляется комментарий от dsorokin: "В Scala название flatMap обозначает монадическую связку (она же известна в других языках как bind, and_then, then и даже как ">>=") — соединяет одно вычисление с другим, создавая новое комбинированное", на которого я и ссылаюсь.

S>Что и позволило мне сказать, что заявляемый cppguard-ом общеизвестный flat-map в случае Ruby делается flatten-ом, а в случае Scala flatMap означает вообще другое.

Не очень понимаю, что вы тут докапываетесь друг к другу по мелочам. Ну, да ладно!

Я могу еще вам усложнить жизнь. FlatMap в контексте вычисления будет монадической связкой, как и SelectMany в C#, а вот в контексте контейнера будет вот тем самым map плюс flatten, опять же как в том же самом C#. Ну, и чтобы совсем было хорошо, один и тот же список можно рассматривать и как контейнер, и как недетерменированное вычисление, у которого может быть множество значений на выходе.

Слушайте, вам что, перед Новым годом заняться больше нечем?

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

s> S>>О да, это же совсем другое, понимать надо! А я и не понял.
s> ·>Да.
s> Ожидаемо. Только вот у меня нет столько "Этодругина Форте" чтобы воспринимать ваши виляния всерьез: тут есть в теории, значит минус в карму ЯП, а вот тут нет, ну и пофиг. Тут вот мы требуем flatMap в стандартной библиотеке, а вот тут ее нет ну и пофиг.
Мы не требуем конкретно в стандартной библиотеке. Пусть в нестандартной, пофиг. Суть в том, что есть общепринятое и хорошо известное понятие флатмаппинга. И везде, во всех учебниках, во всех ЯП, оно означает одно и то же. Кроме плюсов; там это же понятие означает совершенно другое, ничего общего с общепринятым.

s>Тут вот объяснение, но корявое, поэтому оно не определение, а значит и не корявое.
Потому что это значки, а не понятия. Попробуй поискать "how assign value in <ЯП>" и потом "how flatmap in <ЯП>".

s> ·>Говорил, цитирую: "совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten".
s> А теперь найдите где бы я сказал, что в ruby flatten делает что-то отличное от flatten в Scala.
Ты сказал, что "совсем другой смысл". Может я не так распарсил твоё высказывание, но это неважно. Суть в том, что смысл никакой не другой, а ровно такой же. Во всех ЯП эти термины означают одно и то же.

s> Цепочка моих рассуждений, если что, была такой:
s> cppguard заявляет, буквально: "Во всём остальном мире flat-map это превращение древовидной структуры в плоскую".
s> Здесь нет flatMap = map + flatten, здесь только про превращение древовидной структуры в плоскую, это как раз то, что делает flatten.
Тоже неважно, он неточно выразился, dsorokin правильно исправил.

s> Что и позволило мне сказать, что заявляемый cppguard-ом общеизвестный flat-map в случае Ruby делается flatten-ом, а в случае Scala flatMap означает вообще другое.
Ну ошибся, а доки поленился прочитать. Впрочем, эта ошибка не имеет значения. Это неважно, т.к. везде flatmap — функция преобразования контейнеров или подобного. И только в с++ — пошли своим путём.

s> ·>И что?
s> И все.
Вот именно.

s> Претензии здесь высказываются к стандартной библиотеке C++, в качестве примера приводится Python, в котором flat_map нет вообще. Вот это поворот!
Не к стандартной библиотеке претензии, а к понятию flat_map и что оно означает в контекстах разных ЯП.

s> Ах да, это же другое.
Да, верно.

s> ·>Пустое заявление.
s> И это тоже другое.
Конечно.

s> ·>Ты не понял, я уточнил, и процитировал формальные определения.
s> Я-то все понял, это вы с какого-то бодуна полезли доказывать, что List с нумерованными элементами -- это нормально.
Это твои фантазии.

s> ·>Во следующем предложении после процитированного: "The user can access elements by their integer index (position in the list), and search for elements in the list.
s> Так вот про это и был комментарий: "От оно чё. List -- это пронумерованная, оказывается. Ну OK."
Я неточно перевёл термин indexed/position как пронумерованный, каюсь.

s> Для вас список, в котором есть доступ по индексу, возможно, нормален.
Конечно, у каждого элемента в списке есть позиция|индекс и по нему можно однозначно получить элемент. Это один из признаков, отличающих списки от множеств. Поэтому я об этом и упомянул изначально, объясняя почему в ArrayList используется слово List.
Что в LinkedList, что в ArrayList можно однозначно адресовать элемент по числовому индексу. Отличие будет лишь в вычислительной сложности операции. А для Set такой операции просто нет, вообще нет.

s> А вот как быть тем, кто считает это маразмом?
Заняться самообразованием. Теорию CS подтянуть, про абстрактные типы данных почитать.

s> Им жаловаться на прохой нейминг в Java? Бегать по форумам и писать "и только в Java такая херня"? Или просто пожать плечами, сказать "ну здесь так" и спокойно себе кодить на Java?
Ну никто не запрещает. Можно сразу в спортлото жаловаться.

s> S>>А у элемента списка номер нужно вычислять.
s> ·>И что?
s> И все. Хотя нет, у вас это опять пойдет по категории "это другое".
Что другое?

s> ·>я надеялся abstract_data_type будет очевидной инфой.
s> Зря. Потому что я не понимаю, у вас abstract data type -- это уже про программирование и про реалиазации этих самых абстрактных типов данных в ЯП, или это все еще теория.
Так разберись. Задавай вопросы, что неясно.

s> S>>Если про тип данных и у вас есть детерминированный способ
s> ·>Если бы кабы... А кто его вам даст и с каого бодуна?
s> Да как бы общепринятая вещь для реализаций такого понятия, как "множество". Например, в Java интерфейс Set наследуется от Iterable. Про C++ вообще очевидно. В Python-е используется for x in set.
А доки почитать опять лень? "Returns an iterator over the elements in this set. The elements are returned in no particular order ". Где тут про детерминизм? Для сравнения: "Returns an iterator over the elements in this list in proper sequence."

s> Могут быть. Поэтому я и сказал "Если ... есть детерминированный способ". Очевидно, что если у вас такая реализация Set, которая при каждой итерации выдает элементы в другом порядке, то пронумеровать их не получится.
Угу. Поэтому для Set ты не можешь определить позицию каждого элемента.

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

d> Я могу еще вам усложнить жизнь. FlatMap в контексте вычисления будет монадической связкой,...будет вот тем самым map ...
Так вопрос на засыпку: в каком контексте FlatMap будет ассоциативным контейнером?

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

S>Хорошо, значит в этом смысле мы можем поговорить на равных.
Так вот он что, Мыхалыч. Вы, оказывается, занимаетесь консалтинго-аутсорсом в С++, если я правильно понял. https://stiffstream.com/ru/services.html <- оно же? Мы могли бы сохранить несколько ватт мировой энергии, не начиная вообще этот спор. Рассказывать какие-то нелицеприятные вещи про инструмент человеку, который этим на хлеб зарабатывает, это та ещё специальная олимпиада

У меня только два вопроса: если вы работаете по time-and-material, число часов сверху ограничиваете? И как долго после сдачи проекта исправляете ошибки (если вообще занимаетесь бесплатным исправлением ошибок)? Если нет, то объясните мне, как потенциальному заказчику, как я должен спланировать бюджет проекта, если расходы потенциально могут уйти в бесконечность? Другими словами, если вы заявляете, что С++ весь такой удобный и эффективный, то какие гарантии вы даёте заказчику, чтобы он был уверен, что С++ действительно хороший выбор для его задачи, а не что просто вам нравится с ним работать, и за счёт денег заказчика вы готовы писать всякие сложные штуки, которые заказчику реально не нужны. Или к вам приходят сразу с запросом на С++?

Расскажу, как это делаю я. Обращается заказчик с задачей. В ходе R&D выясняем экономический эффект от предполагаемой работы, смотрим срок окупаемости. Работаем по часам, но ставим ограничение по общему количеству сверху, чтобы заказчик был уверен, что бюджет не выйдет за рамки. Любые ошибки исправляем за свой счёт без ограничения по сроку.

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

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

d>> Я могу еще вам усложнить жизнь. FlatMap в контексте вычисления будет монадической связкой,...будет вот тем самым map ...
·>Так вопрос на засыпку: в каком контексте FlatMap будет ассоциативным контейнером?

Не знаю. А в каком?

Вот здесь https://hackage.haskell.org/package/containers-0.7/docs/Data-Map-Lazy.html слово Monad встречается только в контексте Data, а я даже не знаю, что это за зверь.

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

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

d>> Я могу еще вам усложнить жизнь. FlatMap в контексте вычисления будет монадической связкой,...будет вот тем самым map ...
·>Так вопрос на засыпку: в каком контексте FlatMap будет ассоциативным контейнером?

А! Это шутка про C++?

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

·>Суть в том, что есть общепринятое и хорошо известное понятие флатмаппинга. И везде, во всех учебниках, во всех ЯП, оно означает одно и то же. Кроме плюсов; там это же понятие означает совершенно другое, ничего общего с общепринятым.

Вы со своими претензиями опоздали лет на 30-35: во всем мире есть понятие map -- отображение m(x)->y, тогда как в C++ это не map, а transform. И как-то всем пофиг уже не первое десятилетие. И здесь такие пуритане "а вот как же с flat_map-ом!", и это после того как в Boost-е (т.е. во второй по значимости библиотеке в C++ после stdlib) этот самый flat_map уже лет десять, как минимум.

s>>Тут вот объяснение, но корявое, поэтому оно не определение, а значит и не корявое.
·>Потому что это значки, а не понятия.

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

s>> ·>Говорил, цитирую: "совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten".
s>> А теперь найдите где бы я сказал, что в ruby flatten делает что-то отличное от flatten в Scala.
·>Ты сказал, что "совсем другой смысл".

Ну так научитесь читать, репетитора возьмите, что ли. Я не говорил, что в ruby flatten делает что-то отличное от flatten в Scala.

·>Может я не так распарсил твоё высказывание, но это неважно.

Это важно. Мы здесь можем исходить только из того, что именно люди говорят, т.к. заглянуть в голову пишущему и выяснить в каком контексте он находится невозможно. Поэтому если сказанное было ошибочным (как в моем случае, когда я посчитал, что в словах cppguard ключевым требованием к flatMap является только преобразование из древовидной структуры в плоскую), то обсуждать и исправлять можно именно то, что было сказано ошибочно.

Вы же вообще не можете понять, что я вам пишу, а потом еще и говорите, что это неважно.

·>Суть в том, что смысл никакой не другой, а ровно такой же.

Ну да, ну да. В Python flatMap-а нет вообще, в Ruby flat_map возвращает новый контейнер, тогда как в Scala flatMap возвращает один объект (который в моем мире, далеком от ФП и монад, назвали бы ленивым итератором или отображением (view) для диапазона (range)). Возврат объекта-view вместо готового контейнера -- это же ровно тоже самое, да.

s>> ·>Ты не понял, я уточнил, и процитировал формальные определения.
s>> Я-то все понял, это вы с какого-то бодуна полезли доказывать, что List с нумерованными элементами -- это нормально.
·>Это твои фантазии.

Блин, ну почему хаятели C++ в итоге демонстрируют альтернативную одаренность и пытаются спорить с собственноручно написаным же:

Нет никакого оксюморона... всё очень чётко и однозначно. list (список) — что хранится, пронумерованная коллекция элементов (в отличие от Set), а array (массив) — как хранится, расположение элементов одним блоком.

s>> Для вас список, в котором есть доступ по индексу, возможно, нормален.
·>Конечно, у каждого элемента в списке есть позиция|индекс и по нему можно однозначно получить элемент.

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

s>> Им жаловаться на прохой нейминг в Java? Бегать по форумам и писать "и только в Java такая херня"? Или просто пожать плечами, сказать "ну здесь так" и спокойно себе кодить на Java?
·>Ну никто не запрещает. Можно сразу в спортлото жаловаться.

Какой замечательный совет. Вам альтернативная одаренность мешает применить его к себе же по поводу C++ного flat_map-а?

·>Так разберись. Задавай вопросы, что неясно.

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

·>А доки почитать опять лень? "Returns an iterator over the elements in this set. The elements are returned in no particular order ". Где тут про детерминизм? Для сравнения: "Returns an iterator over the elements in this list in proper sequence."

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

·>Угу. Поэтому для Set ты не можешь определить позицию каждого элемента.

А я и не говорил, что мне нужно определить позицию каждого элемента. Я говорил, что их можно нумеровать при итерации так же, как это делается при итерации по списку. Ведь если у нас список (список, а не вектор!), то мы вынуждены делать что-то вроде:

int index = 0;
for(const auto & item : container) {
  handle(item, index); // Имеем и элемент, и его порядковый номер в списке.
  ++index;
}

и тоже самое мы будем делать и с set:

int index = 0;
for(const auto & item : container) {
  handle(item, index); // Имеем и элемент, и его порядковый номер во множестве.
  ++index;
}

И если нам нужен N-й элемент, то мы будем последовательно пропускать (N-1) (скажем, через take из ranges) что для списка, что для множества.

Так что если Set дает один и тот же порядок обхода своего содержимого, то номера элементов вполне себе вычисляются. Ровно так же, как и в случае с List-ом.

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

C>Рассказывать какие-то нелицеприятные вещи про инструмент человеку, который этим на хлеб зарабатывает, это та ещё специальная олимпиада

Рациональный вы мой, вы, мягко говоря, задолбали своей манерой общения: на вопросы не отвечаете, ставите диагнозы по Интернету, заранее приписываете собеседнику какие-то негативные качества, и практически полный ноль в плане конкретики. Фу таким быть.

C>У меня только два вопроса: если вы работаете по time-and-material

Да. Во времена победившего agile, когда в понедельник у клиента одна задача на ближайшие две недели, а в среду появляется более приоритетное вбрасывание, в fixed price нет смысла.

C>число часов сверху ограничиваете?

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

C>И как долго после сдачи проекта исправляете ошибки (если вообще занимаетесь бесплатным исправлением ошибок)?

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

C>Если нет, то объясните мне, как потенциальному заказчику, как я должен спланировать бюджет проекта, если расходы потенциально могут уйти в бесконечность?

А вот это вот одна из фундаментальных проблем разработки, но, если вы этого не поняли, то от ЯП она вообще не зависит.

C>Другими словами, если вы заявляете

Мы такого не заявляли. Иногда мы помогаем разобраться в том, действительно ли C++ будет удобным и эффективным. Несколько раз мы советовали использовать вместо C++ другие языки.

C>то какие гарантии вы даёте заказчику, чтобы он был уверен, что С++ действительно хороший выбор для его задачи

Нам не нужно давать такие гарантии. Обычно к нам приходят когда кодовая база на C++ уже есть. Несколько раз были случаи, когда стартовал новый проект, но там выбирать было особо не из чего — С++ или Си или Rust. Но при выборе между C++ и Rust, кроме технических, вставали еще и различные организационные проблемы, решение которых для C++ выглядели более простыми и дешевыми.

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

Не знаю, поверите ли вы или нет, но проблема со всякими сложными/новыми/интересными/передовыми штуками актуальна не только для C++.

C>В ходе R&D

Я вот хз что у вас значит "R&D", потому что мы вроде как и делаем для заказчиков R&D за их счет. А уже смысл сего действа и экономический эффект -- это уже зона ответственности заказчика. Если он решает сделать аналог Excel-я или AWS S3, то это его головняк как он будет строить бизнес, организовывать продажи, и пр.

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

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

S>Рациональный вы мой, вы, мягко говоря, задолбали своей манерой общения: на вопросы не отвечаете, ставите диагнозы по Интернету, заранее приписываете собеседнику какие-то негативные качества, и практически полный ноль в плане конкретики. Фу таким быть.

На какие вопросы? Вы тоже отвечаете обтекаемо. Про инженеров я ответил. Вам не понравилось моё определение — это уже не моя проблема. В инженерии действительно к С++ очень осторожное отношение. Даже всякие MISRA и CERT придумали. А сейчас и вообще ходят уйти от языков с неуправляемой памятью. Правда, я считаю, что нужно работать над доказуемостью программ, а отдавать всё на откуп питонам и джавам, внутри которых внезапно те же С/С++.

S>Предварительная трудоемкость работ оговаривается с заказчиком. Дальше как пойдет, см. выше про победивший agile.
Вот именно это и интересно — как она оговаривается? В духе "ну, это займёт от 100 до 1000 человеко часов"? Или же вы в контракте прописываете точное значение или верхнюю границу? Смотрите выше про обтекаемые ответы.

S>Да, в договоре описывается срок гарантийных обязательств. Обычно пропорционально сроку самого договора. Например, если договор на 2 месяца, то гарантия -- месяц.
Вы продаёте код, который через месяц может протухнуть? Или я что-то неправильно понял? Что вам мешает давать гарантию в 10 лет?

S>А вот это вот одна из фундаментальных проблем разработки, но, если вы этого не поняли, то от ЯП она вообще не зависит.
Нет, это одна из фундаментальных проблем некоторых компаний, которые любят за чужой счёт заниматься творчеством. Не надо только снова нападать или писать что-то про меня — только время зря потратите. Я понимаю такую позицию, особенно когда нужно кормить штат разработчиков, просто не уважаю. Когда мне говорят, что оценка бюджета это проблема, то я всегда представляю, как этот же человек приходит в строительную компанию строить дом, а ему говорят, что стройка может затянуться на годы, а сколько будет стоить — вообще непонятно, и предлагают просто платить каждый месяц N рублей. Ещё бывают перлы типа "умный дом будет экономить вам N рублей в месяц, только установите нашу новую систему за офердофига, кстати, она выполнена на noname-компонентах из Китая, которые могут стать тыквой уже завтра".

S>Не знаю, поверите ли вы или нет, но проблема со всякими сложными/новыми/интересными/передовыми штуками актуальна не только для C++.
О, я не только верю, я очень часто сталкиваюсь к этому лицом к лицу. Что ж, каждому хочется заниматься интересным и не заниматься рутиной. А попробовать что-то новое за счёт заказчика — так вообще конфетка. Я бы, возможно, принял, что это неиздежность, если бы не встречал подрядчиков, которые простые вещи делают простыми способами, быстро и дешёво. И даже совсем не сердито.

S>Я вот хз что у вас значит "R&D", потому что мы вроде как и делаем для заказчиков R&D за их счет. А уже смысл сего действа и экономический эффект -- это уже зона ответственности заказчика. Если он решает сделать аналог Excel-я или AWS S3, то это его головняк как он будет строить бизнес, организовывать продажи, и пр.
RnD у нас это выяснение проблем заказчика и первичное проектирование решений. Возможно, прототипов, с целью показать, что вообще можно сделать, и сколько это примерно будет стоить. Да, это тоже стоит денег, но эти суммы — о() от итоговой стоимости проекта. Как раз эта работа и помогает нам в дальнейшем предоставить заказчику гарантированную защиту от выхода его бюджета за uint32.

S>Образно говоря, когда кто-то строит бизнес-центр не дело сантехников выяснять насколько просто будущему владельцу будет отбить вложенное, дело сантехников так проложить канализацию, чтобы обитатели бизнес-центра в говне не утонули потом. Даже если владелец хочет максимально сэкономить на материалах.
Painters and plumbers Всё верно насчёт сантехников, только так получается на практике, что если они не могут для конкретной задачи ответить на вопрос о стоимости, то идут лесом. А потом ещё пишут/звонят "а почему вы не выбрали нас?". А как их выбрать, если это уже моя задача предоставить заказчику среди прочего и расчёт окупаемости?

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

C>На какие вопросы?

Практически на все.

C>Про инженеров я ответил.

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

S>>Предварительная трудоемкость работ оговаривается с заказчиком. Дальше как пойдет, см. выше про победивший agile.
C>Вот именно это и интересно — как она оговаривается?

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

S>>Да, в договоре описывается срок гарантийных обязательств. Обычно пропорционально сроку самого договора. Например, если договор на 2 месяца, то гарантия -- месяц.
C>Вы продаёте код, который через месяц может протухнуть?

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

C>Или я что-то неправильно понял?

Больше похоже, что не дали себе труда понять.

C>Что вам мешает давать гарантию в 10 лет?

Тот простой факт, что программ без ошибок не бывает.

И опыт.

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

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

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

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

Да? Ну ладно, в вашей вселенной всякое может быть.

C>RnD у нас это выяснение проблем заказчика и первичное проектирование решений.

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

C>Painters and plumbers Всё верно насчёт сантехников, только так получается на практике, что если они не могут для конкретной задачи ответить на вопрос о стоимости, то идут лесом.

Хватит вносить отсебятину. Вы берете предварительный набросок здания и список хотелок (например, одновременно в бизнес-центре могут находится до 1500 человек, в пике до 4500, а еще нам нужны санузлы для инвалидов-колясочников на каждом этаже (в количестве двух штук) и было бы неплохо иметь отдельные санузлы для представителей первых 15 гендеров из очередного радужного списка), прикидываете сколько и каких санузлов нужно на каждом, их пропускную способность, длину и объем коммуникаций, примерное расположение здания, возможные варианты интеграции с городскими коммуникациями и т.д., и т.п. Берете какое-то типовое оборудование (обычно то, с которым привыкли работать), стоимость каких-то типовых расходных материалов (обычно от поставщиков с которыми долго работаете), прикидываете количество людей и как-то учитываете сроки, в которые заказчик хочет уложиться, суммируете это все, домножаете на выработанный годами поправочный коэффициент и озвучиваете некоторое значение (или обозначаете вилку вокруг оного).

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

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

C>А как их выбрать, если это уже моя задача предоставить заказчику среди прочего и расчёт окупаемости?

А я вот не знаю, какие расходы по окупаемости можно предоставить заказчику, который приходит к нам с проблемой вроде "мы импортозамещаем AWS S3, сделали обслуживание входящих запросов на X, уперлись в проблемы, их нужно разрешить". В процессе разбирательств приходим к заключению, что решается это заменой X на Y и обойдется это в ~N денег +- лапоть. При этом само обслуживание этих самых входящих запросов составляет, условно, 5% от общего объема проекта, а то и меньше.

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

s> ·>Суть в том, что есть общепринятое и хорошо известное понятие флатмаппинга. И везде, во всех учебниках, во всех ЯП, оно означает одно и то же. Кроме плюсов; там это же понятие означает совершенно другое, ничего общего с общепринятым.
s> Вы со своими претензиями опоздали лет на 30-35: во всем мире есть понятие map -- отображение m(x)->y, тогда как в C++ это не map, а transform. И как-то всем пофиг уже не первое десятилетие. И здесь такие пуритане "а вот как же с flat_map-ом!", и это после того как в Boost-е (т.е. во второй по значимости библиотеке в C++ после stdlib) этот самый flat_map уже лет десять, как минимум.
Пофиг. Ты опять не понял. Суть претензии не в том, как конкретный метод называется. А в том, что общепринятое понятие в контексте плюсов имеет совершенно другой смысл.
Например, в haskell тоже нет метода с названием flatmap, а конструируется из других методов. И что?

s> s>>Тут вот объяснение, но корявое, поэтому оно не определение, а значит и не корявое.
s> ·>Потому что это значки, а не понятия.
s> Так я и говорю, что это настолько другое, что пипец.
Да, верно. Синтаксис и Семантика — две очень разные различные разницы.

s> s>> А теперь найдите где бы я сказал, что в ruby flatten делает что-то отличное от flatten в Scala.
s> ·>Ты сказал, что "совсем другой смысл".
s> Ну так научитесь читать, репетитора возьмите, что ли. Я не говорил, что в ruby flatten делает что-то отличное от flatten в Scala.
И что? Ты говорил "совсем другой смысл", когда никакого другого смыла по факту нет. То что твои заблуждения основаны на словах cppguard, это твои проблемы и мне совершенно неважно, надо читать доки и учебники, а не мысли в чужих головах.

s> ·>Может я не так распарсил твоё высказывание, но это неважно.
s> Это важно. Мы здесь можем исходить только из того, что именно люди говорят, т.к. заглянуть в голову пишущему и выяснить в каком контексте он находится невозможно.
Можете, но лучше не надо. За фактами надо заглядывать не в головы, а в спеки и учебники. И тут даже уже были ссылки несколько раз.

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

s> ·>Суть в том, что смысл никакой не другой, а ровно такой же.
s> Ну да, ну да. В Python flatMap-а нет вообще, в Ruby flat_map возвращает новый контейнер, тогда как в Scala flatMap возвращает один объект (который в моем мире, далеком от ФП и монад, назвали бы ленивым итератором или отображением (view) для диапазона (range)). Возврат объекта-view вместо готового контейнера -- это же ровно тоже самое, да.
Ну с натяжкой более менее примерно так... Вроде dsorokin всё уже расписал, довольно подробно.

s> s>> Я-то все понял, это вы с какого-то бодуна полезли доказывать, что List с нумерованными элементами -- это нормально.
s> ·>Это твои фантазии.
s> Блин, ну почему хаятели C++ в итоге демонстрируют альтернативную одаренность и пытаются спорить с собственноручно написаным же:
s> Нет никакого оксюморона... всё очень чётко и однозначно. list (список) — что хранится, пронумерованная коллекция элементов (в отличие от Set), а array (массив) — как хранится, расположение элементов одним блоком.
Это не доказательство того, что "List с нумерованными элементами -- это нормально", я такой бред никогда не заявлял, и уж тем более не пытался доказывать. А мои процитированные слова — это объяснение на пальцах почему ArrayList называется именно так.

s> ·>Конечно, у каждого элемента в списке есть позиция|индекс и по нему можно однозначно получить элемент.
s> Ну так смысл в том, что список, у которого доступ к элементам возможен по индексу, это говно, а не структура данных (не важно, абстрактная или нет).
Оно только в твоей голове. Напомню, что это общепринятое понятие: https://en.wikipedia.org/wiki/List_(abstract_data_type) , а не моё личное изобретение или мои вкусовые пристрастия.

s> ·>Ну никто не запрещает. Можно сразу в спортлото жаловаться.
s> Какой замечательный совет. Вам альтернативная одаренность мешает применить его к себе же по поводу C++ного flat_map-а?
Не волнуйся за меня, мне ничего не мешает.

s> ·>А доки почитать опять лень? "Returns an iterator over the elements in this set. The elements are returned in no particular order ". Где тут про детерминизм? Для сравнения: "Returns an iterator over the elements in this list in proper sequence."
s> Детеминизм здесь в том, будет ли итерация по одному и тому контейнеру возвращать элементы в одном и том же порядке или нет, если в контейнер не вносятся изменения.
Где ты увидел это? Написано же явно: no particular order.
Скажем, гипотетическая реализация коллекции при переборе может на ходу проводить какую-нибудь дефрагментацию внутреннюю и при втором переборе этой же коллекции выдать те же элементы, но в другом порядке.

s> ·>Угу. Поэтому для Set ты не можешь определить позицию каждого элемента.
s> handle(item, index); // Имеем и элемент, и его порядковый номер во множестве.
Нет, не имеем. Мы имеем порядковый номер в итераторе. Iterable это такая шутка, которая умеет конструировать совсем другой тип — Iterator. И в цикле будет перебираться Iterator, а не сам контейнер.

s> И если нам нужен N-й элемент, то мы будем последовательно пропускать (N-1) (скажем, через take из ranges) что для списка, что для множества.
Угу, делать так можно, но в общем случае для множества это будет выдавать произвольный результат. Это же почти как undefined behaviour, тебе как плюсовику должно быть понятно, что закладываться на UB нельзя, даже если код вроде как бы работает.

s> Так что если Set дает один и тот же порядок обхода своего содержимого, то номера элементов вполне себе вычисляются. Ровно так же, как и в случае с List-ом.
Нет, не ровно. "no particular order" != "in proper sequence".

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

s>> Вы со своими претензиями опоздали лет на 30-35: во всем мире есть понятие map -- отображение m(x)->y, тогда как в C++ это не map, а transform. И как-то всем пофиг уже не первое десятилетие. И здесь такие пуритане "а вот как же с flat_map-ом!", и это после того как в Boost-е (т.е. во второй по значимости библиотеке в C++ после stdlib) этот самый flat_map уже лет десять, как минимум.
·>Пофиг. Ты опять не понял.

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

В теории (и в других языках) имеем общепринятое понятие map, как функцию отображения map(x)->y. А в C++ мало того, что это понятие именуется как transform, так еще и в C++ map -- это имя типа ассоциативного контейнера.

И пофиг.

·>А в том, что общепринятое понятие в контексте плюсов имеет совершенно другой смысл.

А вот тут вдруг уже не пофиг.

s>> ·>Потому что это значки, а не понятия.
s>> Так я и говорю, что это настолько другое, что пипец.
·>Да, верно. Синтаксис и Семантика — две очень разные различные разницы.

Смотрим:
— в теории есть символ "=" который имеет семантику сравнения на строгое равенство;
— в C++ есть символ "=" который имеет семантику присваивания нового значения.

Имеем: один синтаксис, разные семантики.
И это OK.

Смотрим дальше:
— в теории есть символ flat_map, который означает трансформацию элементов с сохранением результата в плоскую коллекцию;
— в C++ есть символ flat_map, который означает просто плоскую коллекцию.

Имеем: один синтаксис, разные семантики.
Но это уже не OK.

И опять здесь настолько другое, что мне этого не понять.

·>И что?

А то, что я не говорил, что flatten в Ruby делает что-то отличное от flatten в Scala. Но вы мне это в качестве претензии выдвигаете.

При этом когда я заявляю, что вы полезли доказывать, что говняный Java-вский List -- это нормально, то оказывается, что ничего такого вы не говорили.

Да, это опять совсем другое.

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

Зафиксируем на время то, что вам "интересны факты".

s>> ·>Конечно, у каждого элемента в списке есть позиция|индекс и по нему можно однозначно получить элемент.
s>> Ну так смысл в том, что список, у которого доступ к элементам возможен по индексу, это говно, а не структура данных (не важно, абстрактная или нет).
·>Оно только в твоей голове. Напомню, что это общепринятое понятие: https://en.wikipedia.org/wiki/List_(abstract_data_type) , а не моё личное изобретение или мои вкусовые пристрастия.

Раз вы в очередной раз ссылаетесь на Wikipedia, то приведите оттуда цитату, в которой бы говорилось, что доступ к элементу списка по индексу -- это обязательная и неотъемлемая часть абстрактного типа List. Там ведь ни в неформальном определении:

In computer science, a list or sequence is a collection of items that are finite in number and in a particular order. An instance of a list is a computer representation of the mathematical concept of a tuple or finite sequence.

ни в формальном (см. раздел https://en.wikipedia.org/wiki/List_(abstract_data_type)#Abstract_definition) нет ничего про доступ по индексу.

Говорится только что:

Implementation of the list data structure may provide some of the following operations:
...
access an item by index

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

Это вам, как любителю фактов.

Так вот, интерфейс List, который дает доступ по индексу, но стоимость этого доступа может варьироваться от O(1) до O(N) -- это говно, а не "список". Только вот в Java с этим живут десятилетия и живы.

Точно так же в C++ проживут с flat_map в виде структуры данных, а не именем алгоритма трансформации данных.

s>> ·>А доки почитать опять лень? "Returns an iterator over the elements in this set. The elements are returned in no particular order ". Где тут про детерминизм? Для сравнения: "Returns an iterator over the elements in this list in proper sequence."
s>> Детеминизм здесь в том, будет ли итерация по одному и тому контейнеру возвращать элементы в одном и том же порядке или нет, если в контейнер не вносятся изменения.
·>Где ты увидел это? Написано же явно: no particular order.

Перечитайте то, что я вам уже писал, там все написано.

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

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

s>> handle(item, index); // Имеем и элемент, и его порядковый номер во множестве.
·>Нет, не имеем. Мы имеем порядковый номер в итераторе.

Нет, здесь нет никаких номеров в итераторах. Более того, если мы возьмем реализации абстрактных типов List и Set в их C++ном виде, то там и физически никаких номеров в итераторах не будет (как, полагаю, и в Rust-е).

Так что у вас здесь опять это самое "это другое, понимать надо".

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

S>Да, это настолько другое, что я в принципе не понимаю. А именно:
S>В теории (и в других языках) имеем общепринятое понятие map, как функцию отображения map(x)->y. А в C++ мало того, что это понятие именуется как transform, так еще и в C++ map -- это имя типа ассоциативного контейнера.
Во-первых, ты разговор в сторону уводишь опять, софизм вида "раз тут плохо, так гори всё огнём!". Во-вторых, ассоциативный контейнер это таки тоже функция отображения keys->values. В-третьих, тут могу согласится, принципе это тоже не самый удачный выбор, я бы предпочёл dictionary. ИЧСХ, в шарпе, который делали как улучшенную java, исправили терминологию, молодцы.

S>·>А в том, что общепринятое понятие в контексте плюсов имеет совершенно другой смысл.
S>А вот тут вдруг уже не пофиг.
Я бы понял если бы этому было десятки лет, так ведь нет, имея уже устоявшуюся терминологию нарочно наступить на грабли...

S>- в теории есть символ "=" который имеет семантику сравнения на строгое равенство;
S>- в C++ есть символ "=" который имеет семантику присваивания нового значения.
S>Имеем: один синтаксис, разные семантики.
S>И это OK.
Довольно близкие, кстати. "Значения равны?.." vs "значения равны!!!". Это скорее уже специфика конкретных ЯП.

S>Смотрим дальше:
S>- в теории есть символ flat_map, который означает трансформацию элементов с сохранением результата в плоскую коллекцию;
Не символ, а понятие. В некоторых яп оно обозначается символом flatMap, в некоторых fmap, в некоторых bind, как ">>=", thenCompose, через list comprehension и т.п. Да и оно означает несколько другое. Соединение вычислений. В контексте списков получается новый список с другим кол-вом элементов. Флатмапить можно и другие вещи, обладающие монадическими свойствами, например, optional, future и т.п.

S>Имеем: один синтаксис, разные семантики.
S>Но это уже не OK.
S>И опять здесь настолько другое, что мне этого не понять.
Как там принято говорить: мне вас жаль.

S>·>И что?
S>А то, что я не говорил, что flatten в Ruby делает что-то отличное от flatten в Scala. Но вы мне это в качестве претензии выдвигаете.
Я претензии предъявлял к словам "термин имеет совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten". Они не соответсвуют фактам. Каюсь, скорее всего я не так прочитал эти слова и ошибся каким конкретно фактам они не соответсвуют, но рояли не играет. Высказывание в принципе ложное.

S>При этом когда я заявляю, что вы полезли доказывать, что говняный Java-вский List -- это нормально, то оказывается, что ничего такого вы не говорили.
Про нормальность я ничего _не доказывал_. Цитату в студию или признавайся, что врёшь. Я в данном случае вообще ничего не доказывал. Я _объяснял_, что java List соответствует общепринятому ADT List.

s>>> Ну так смысл в том, что список, у которого доступ к элементам возможен по индексу, это говно, а не структура данных (не важно, абстрактная или нет).
S>·>Оно только в твоей голове. Напомню, что это общепринятое понятие: https://en.wikipedia.org/wiki/List_(abstract_data_type) , а не моё личное изобретение или мои вкусовые пристрастия.
S>Раз вы в очередной раз ссылаетесь на Wikipedia, то приведите оттуда цитату, в которой бы говорилось, что доступ к элементу списка по индексу -- это обязательная и неотъемлемая часть абстрактного типа List. Там ведь ни в неформальном определении:
Зачем? Ты придумал бред, а мне доказывать?

S>Т.е. именно что реализации абстрактного типа могут (но не обязаны) предоставлять доступ по индексу.
Верно. А кто-то что-то говорил, что обязаны?
Ещё раз. ADT List — есть индекс/позиция у элементов и _может_ быть доступ по индексу. ADT Set — индекса нет и _не может_ быть доступа оп индексу. Про "обязаны" — это твои фантазии, ты в трёх модальностях заблудился.

S>Так вот, интерфейс List, который дает доступ по индексу, но стоимость этого доступа может варьироваться от O(1) до O(N)
Ты так говоришь, как будто это что-то плохое.

S>Точно так же в C++ проживут с flat_map в виде структуры данных, а не именем алгоритма трансформации данных.
Ты так говоришь, как будто это что-то хорошее.

S>·>Где ты увидел это? Написано же явно: no particular order.
S>Перечитайте то, что я вам уже писал, там все написано.
Мне не интересны твои фантазии. Мне интересны факты. С какого бодуна ты взял, что "Детеминизм здесь в том, будет ли итерация по одному и тому контейнеру возвращать элементы в одном и том же порядке или нет, если в контейнер не вносятся изменения"? И ещё неясно с какого бодуна ты свойства типа Iterator переносишь на тип Set.

S>·>Скажем, гипотетическая реализация коллекции при переборе может на ходу проводить какую-нибудь дефрагментацию внутреннюю и при втором переборе этой же коллекции выдать те же элементы, но в другом порядке.
S>В этом гипотетическом случае у вас не будет возможности пронумеровать элементы коллекции.
ЧТД.

s>>> handle(item, index); // Имеем и элемент, и его порядковый номер во множестве.
S>·>Нет, не имеем. Мы имеем порядковый номер в итераторе.
S>Нет, здесь нет никаких номеров в итераторах. Более того, если мы возьмем реализации абстрактных типов List и Set в их C++ном виде, то там и физически никаких номеров в итераторах не будет (как, полагаю, и в Rust-е).
Физические номера в итераторе ты сам придумал, и сам обиделся.

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

S>>- в теории есть символ flat_map, который означает трансформацию элементов с сохранением результата в плоскую коллекцию;
·> Не символ, а понятие.

Очередное это другое.

·>Я претензии предъявлял к словам "термин имеет совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten".

Я что-то не понял чего ты с чем сравниваешь и зачем. Заметь: flatten != flatmap. А flatten что в ruby, что в scala, что в питоне делает одно и то же.

Именно поэтому вы вставили фразу про то, что flatten в Ruby и в Scala делает одно и тоже. Между тем, обратного я и не говорил, но вы зачем-то выделенное жирным написали.

S>>При этом когда я заявляю, что вы полезли доказывать, что говняный Java-вский List -- это нормально, то оказывается, что ничего такого вы не говорили.
·>Про нормальность я ничего _не доказывал_. Цитату в студию или признавайся

Мои слова (в прямом негативном контексте):

Интересно, как много людей в мире Java страдают от оксюморона ArrayList?

На что вы пишете:

Нет никакого оксюморона... всё очень чётко и однозначно.

Если ArrayList не оксюморон, а все очень четко и однозначно, то трактовать сказанное вами как-то отлично от "нормально", у меня не получается.

·>Я _объяснял_, что java List соответствует общепринятому ADT List.

Только вот он не соответствует.

S>>Т.е. именно что реализации абстрактного типа могут (но не обязаны) предоставлять доступ по индексу.
·>Верно. А кто-то что-то говорил, что обязаны?

Да, вы:

Во следующем предложении после процитированного: "The user can access elements by their integer index (position in the list), and search for elements in the list."
Я, похоже, неточно перевёл index/position как нумерация. Но имхо это мелкая придирка.
А ещё по другой моей ссылке https://en.wikipedia.org/wiki/List_(abstract_data_type) : "access an item by index".

Найдите здесь или где-то выше в своих словах про опциональность индекса в List.

·>Ещё раз. ADT List — есть индекс/позиция у элементов и _может_ быть доступ по индексу.

Нет. У элементов есть позиция, но индексом она не определяется. Индекс вы можете подсчитать при итерации по List-у.
Точно так же вы можете подсчитать индекс элемента при итерации по Set-у.

S>>Так вот, интерфейс List, который дает доступ по индексу, но стоимость этого доступа может варьироваться от O(1) до O(N)
·>Ты так говоришь, как будто это что-то плохое.

Я так говорю, потому что это не просто плохое, это откровенное говно.

s>>>> handle(item, index); // Имеем и элемент, и его порядковый номер во множестве.
S>>·>Нет, не имеем. Мы имеем порядковый номер в итераторе.
S>>Нет, здесь нет никаких номеров в итераторах. Более того, если мы возьмем реализации абстрактных типов List и Set в их C++ном виде, то там и физически никаких номеров в итераторах не будет (как, полагаю, и в Rust-е).
·>Физические номера в итераторе ты сам придумал, и сам обиделся.

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

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

S>Очередное это другое.

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

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

R>А в чем смысл и какова цель вашего спора? Вы всё еще рассчитываете его в чём-то убедить? Так это невозможно, ибо он не ищет истины. Ему нужна просто формальная победа и ради этого он не брезгует никакой демагогией. Это всё равно, что играть в шахматы с голубем.

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

PS. Ну и да, с flatMap я изначальный посыл понял неправильно, в процессе спора выяснилось в чем именно я ошибся.

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

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

Имхо, данному персонажу давно пора закрыть вход на этот форум. Ни разу не видел, чтоб он участвовал в решении каких-то технических вопросов. Зато любое его появление выливается во флейм и словоблудие. Этот тот же Shmj, только минус адекватность. (Даже не думал, что когда-нибудь употреблю слова "Shmj" и "адекватность" в одном предложении).

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


S>·>Я претензии предъявлял к словам "термин имеет совсем другой смысл в Scala, а в Ruby эффект flatmap-а дает функция под названием flatten".
S>

Я что-то не понял чего ты с чем сравниваешь и зачем. Заметь: flatten != flatmap. А flatten что в ruby, что в scala, что в питоне делает одно и то же.

S>Именно поэтому вы вставили фразу про то, что flatten в Ruby и в Scala делает одно и тоже. Между тем, обратного я и не говорил, но вы зачем-то выделенное жирным написали.
И что? Каким фактам оно противоречит? И как это меняет мою претензию к корректности твоих слов?

S>·>Про нормальность я ничего _не доказывал_. Цитату в студию или признавайся
S>Мои слова (в прямом негативном контексте):
S>

Интересно, как много людей в мире Java страдают от оксюморона ArrayList?

А почему это оксюморон-то?

S>На что вы пишете:
S>

Нет никакого оксюморона... всё очень чётко и однозначно.

S>Если ArrayList не оксюморон, а все очень четко и однозначно, то трактовать сказанное вами как-то отлично от "нормально", у меня не получается.
Так и не обязательно ничего трактовать. Я всё прямо и однозначно стараюсь говорить.

S>·>Я _объяснял_, что java List соответствует общепринятому ADT List.
S>Только вот он не соответствует.
Каким местом не соответствует?

S>·>Верно. А кто-то что-то говорил, что обязаны?
S>Да, вы:
S>

Во следующем предложении после процитированного: "The user can access elements by their integer index (position in the list), and search for elements in the list."
S>Я, похоже, неточно перевёл index/position как нумерация. Но имхо это мелкая придирка.
S>А ещё по другой моей ссылке https://en.wikipedia.org/wiki/List_(abstract_data_type) : "access an item by index".

S>Найдите здесь или где-то выше в своих словах про опциональность индекса в List.
Во-первых, это не мои слова, а цитаты. Во-вторых, вот нашел тут: "user can access", "Some languages may allow list types to be indexed", "list data structure may provide some of the following operations: ... access an item by index".

S>·>Ещё раз. ADT List — есть индекс/позиция у элементов и _может_ быть доступ по индексу.
S>Нет. У элементов есть позиция, но индексом она не определяется. Индекс вы можете подсчитать при итерации по List-у.
В чём принципиальная разница в контексте обсуждения *List? Ок, давай забудем "индекс", будем говорить только "позиция". В нашем разговоре это рояли не играет.

S>Точно так же вы можете подсчитать индекс элемента при итерации по Set-у.
Мы можем посчитать нечто, не спорю, но вот только это не будет ни индексом элемента в Set, ни позицией.

S>>>Так вот, интерфейс List, который дает доступ по индексу, но стоимость этого доступа может варьироваться от O(1) до O(N)
S>·>Ты так говоришь, как будто это что-то плохое.
S>Я так говорю, потому что это не просто плохое, это откровенное говно.
Это твоя эмоциональная оценка, никаким фактам не соответствует, поэтому идёт в топку.

s>>>>> handle(item, index); // Имеем и элемент, и его порядковый номер во множестве.
S>>>·>Нет, не имеем. Мы имеем порядковый номер в итераторе.
S>>>Нет, здесь нет никаких номеров в итераторах. Более того, если мы возьмем реализации абстрактных типов List и Set в их C++ном виде, то там и физически никаких номеров в итераторах не будет (как, полагаю, и в Rust-е).
S>·>Физические номера в итераторе ты сам придумал, и сам обиделся.
S>Т.е. "Мы имеем порядковый номер в итераторе." -- это ваши слова,
Это перепевка ваших слов "порядковый номер во множестве".

S>а про физические номера в итераторе -- это я сам придумал?
Да, конечно. Либо давай в студию мою цитату про физические номера.