Что делать с жунами , Что делать с жунами

[sergioK]

У нас в команде молодой парень , по образвованию не програмист, соображает неплохо,
в гугле искать умеет, терминала не боиться, но он не умеет присать код(ну все мы не умели поначалу ) ), выяснилось что не
понимает что такое single tone и думает что анотация наследуеться, и чем отличаеться generic и
polymorphism. Я как бы могу его научить, но мне свою работу делать надо, а он может а это время
написать криво, есть еще одна такое, team lead скороее манажер чем програмист,
Вроде я не должен лезть не в свое дело, пускай дерьмокодет, писать за него я могу но не хочу, this is not my business,
но у меня "душа стонет", из него можно сделать классного SE, кто в такой ситуации был ?

[D_KEY]

Что с ним делать нужно было решать еще до того, как брать

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

[sergioK]

Цитата D_KEY @ 20.03.21, 09:33

Что с ним делать нужно было решать еще до того, как брать

Берут не по приципу знает/не знает, главное чтоб хороший парень был, научиться,
со временем,

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

[D_KEY]

Цитата sergioK @ 20.03.21, 13:08

Берут не по приципу знает/не знает, главное чтоб хороший парень был, научиться,
со временем

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

[Qraizer]

Учить. Бери у начальника таску и пусть оплачивает. Он же брал работника, не ты. Это его вложение.

[sergioK]

Цитата Qraizer @ 20.03.21, 16:04

Учить. Бери у начальника таску и пусть оплачивает. Он же брал работника, не ты. Это его вложение.

Начальник знает, напарник над ним шефствует, меня другое не понятно,
Мы когда начинали мы умели писать, да мы не знали как насроить винду,или
проконфигить сервер,и т,д, сегодня с точностью наоборот джуны realloc свой написать не могу,
у меня как-то из 15 студентов только один смог, готовое говорят есть, ну возьми в сети и разберись,
так что это сложно? а linked List для них как полет на Марс, хорошо бы если бы только жуны,
млять люди по 10лет код пишут а про FTP не слышали, мой мозг это не может принять,
Я один такой cool guy ?

[kopilov]

Цитата sergioK @ 05.04.21, 17:58

джуны realloc свой написать не могу,

А зачем писать системные функции, если Вы не разработчик ядра или ЯП?

Linked List я как-то попробовал использовать в тестовом задании на собеседовании (не свой, а библиотечный) — попросили обосновать, почему не Array List. Возможность добавления элементов без realloc не прокатила, работу не приняли, вписав использование Linked List в один из минусов.

[kopilov]

Цитата sergioK @ 05.04.21, 17:58

про FTP не слышали

И не рассказывайте им, пусть scp/SFTP используют

[korvin]

kopilov, https://twitter.com/joshbloch/status/583813919019573248?s=21

[sergioK]

Цитата korvin @ 06.04.21, 13:59

kopilov, https://twitter.com/joshbloch/status/583813919019573248?s=21

Если бы строители строили здание так как програмисты пишут программы
то первый залетевий дрозд разрушил бы нашу цивилизацию.

korvin
Дрозд уже стартанул или еще думает ?

[korvin]

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

sergioK, ты уже сделал мир чуточку лучше?

[Qraizer]

Там, где залетевший дрозд может обрушить здание, код пишется с учётом заблудившихся колибри. И сто́ит он немеряно, какой-нибудь MSWord стоил бы около $миллиона за копию.
У среднестатистических же строителей водопровод построен из жидкого пластика с мониторингом пробоев и их самоустранением, газовые трубы помещены в герметичные изоляционные каналы с углекислотой между стенками, а входные двери на пару с домофоном организуют двухфакторную идентификацию посетителей с выдачей разовых ключей ограниченного срока действия. Конечно, от дебила с перфоратором и болгаркой это не спасёт, но и стоит такой дом соразмерно самокату.

[sergioK]

Цитата korvin @ 07.04.21, 06:33

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

sergioK, ты уже сделал мир чуточку лучше?

да,

Добавлено 07.04.21, 18:00

Цитата Qraizer @ 07.04.21, 12:41

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

незнаю что такое болгарка но вот делаешь ты сыну операцию, а врач говорить
подождите сбой компа, и ты видишь краем глаза,segmentation fault,
то есть какой то поц забыл память выделить, а QA хз куда смотрел, и какая реакция будет?
это реальный случай,

Когда ботинки новые руться это же нонсенс, а вот програма падает, по незнанию или глупости/пофигизму,
это нормально, ну запихнули там string в long, так тебе сбой сердца ошибочно определили, ну полежал
дня четыре пока не выяснили , не работал ну потерял контракт, приятно ?
учли там калибри или не очень ?

Добавлено 07.04.21, 18:04

Цитата Qraizer @ 07.04.21, 12:41

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

Мало что ли качественных, хороших програм за разумную цену?

[korvin]

Цитата sergioK @ 07.04.21, 17:37

да,

Пока что не заметно.

Цитата sergioK @ 07.04.21, 17:37

незнаю что такое болгарка но вот делаешь ты сыну операцию, а врач говорить
подождите сбой компа, и ты видишь краем глаза,segmentation fault,
то есть какой то поц забыл память выделить, а QA хз куда смотрел, и какая реакция будет?
это реальный случай,

Кто ж виноват, что вы критический софт пишете как клиент для инстаграма? Как вы сертификацию прошли?

Цитата sergioK @ 07.04.21, 17:37

Когда ботинки новые руться это же нонсенс

Да нет, вполне бывает, если покупать дешёвые некачественные ботинки в каком-нибудь «Рога и Копыта, а также обувь».

Цитата sergioK @ 07.04.21, 17:37

Мало что ли качественных, хороших програм за разумную цену?

Мало. Ну, «Hello, World»'ов, наверное, много. Но пользы от них не много.

Добавлено 07.04.21, 21:19

Цитата sergioK @ 07.04.21, 17:37

незнаю что такое болгарка

https://www.vseinstrumenti.ru/instrument/sh.../bolgarka_ushm/

[sergioK]

Цитата korvin @ 07.04.21, 21:18

Кто ж виноват, что вы критический софт пишете как клиент для инстаграма? Как вы сертификацию прошли?

Мы то причем? Про других не знаю, но я не умею писать криво,
ума не хватает,

[korvin]

Цитата sergioK @ 08.04.21, 00:38

но я не умею писать криво

Ты себе льстишь.

[D_KEY]

Цитата sergioK @ 08.04.21, 00:38

но я не умею писать криво

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

[sergioK]

Цитата D_KEY @ 08.04.21, 09:10

Цитата sergioK @ 08.04.21, 00:38

но я не умею писать криво

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

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

[D_KEY]

sergioK, нет, нужно перестать думать, что ты не умеешь криво писать. Идеальный код недостижим, каждому есть куда расти.

Добавлено 09.04.21, 17:37

Цитата sergioK @ 09.04.21, 17:15

или перестать следить ворнингами?

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

[Qraizer]

Ну вот мы, к примеру, буквально сегодня отклонили ответ разработчиков на дефект. У них 2-хбитное поле в структуре int, в него пишется 3, дефект в неравенстве этого поля 3 после такого присваивания, ибо там -1 выходит. Ответили, мол, мы знаем, так и задумано, битовое представление совпадает. Аха, счас, разбежались.
А насколько часто ты сталкиваешься с арифметическим переполнением, sergioK?

Добавлено 09.04.21, 19:02
Если серьёзно...

Цитата sergioK @ 07.04.21, 17:37

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

Если ПО относится к высококритичному, ты заманаешься его писать, тестировать и сертифицировать. В прошлый наш проект на одну из функциональностей на ~475Кб сырцов (с комментами и пустыми строками, шапками трассировкой на требования итп) мы только по завершению этапа тестирования отгрузили тестов с их результатами на 187Мб, а общий объём отчётов по этапу верификации составил чуть меньше 2Гб. И это только наша сторона процесса без планов, аудита, анализов и рассмотрения, ревью итп, а сколько туда добавили подрядчики, я без понятия.
К тому же у любого такого ПО есть чёткие требования к программно-аппаратному окружению. На первом попавшемся ноуте с АЛИшки под свежайшей Убунтой его запустить обычно беспроблем, вот только первый попавшийся ноут со свежайшей Убунтой 100пудово не будет соответствовать правилам эксплуатации этого ПО. И в этом случае все вопросы к врачу или его начальникам, по тех.обеспечению в частности. И не дай бог там внезапно обнаружится когда-то вставлявшаяся флешка или некогда активный клиент телеги. Обычно такое делают просто невозможным, но если вдруг врач хакер...
Но вообще, если такие вылеты допустимы, значит некритично. Оценка критичности лежит на заказчике и прописывается в ТЗ, и чёрта с два он её укажет занижено или сертификат будет получен без следования отраслевым стандартам. Даже у нас, ибо никто не захочет садиться на пожизненно, это эму не ведро алмазов с рудников стырить.

Цитата sergioK @ 07.04.21, 17:37

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

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

Цитата sergioK @ 07.04.21, 17:37

Мало что ли качественных, хороших програм за разумную цену?

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

[applegame]

Цитата korvin @ 06.04.21, 13:59

kopilov, https://twitter.com/joshbloch/status/583813919019573248?s=21

ФП-шники используют связные списки постоянно.

[sergioK]

Цитата D_KEY @ 09.04.21, 17:36

sergioK, нет, нужно перестать думать, что ты не умеешь криво писать. Идеальный код недостижим, каждому есть куда расти.

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

Добавлено 10.04.21, 08:35

Цитата Qraizer @ 09.04.21, 18:19

А насколько часто ты сталкиваешься с арифметическим переполнением, sergioK?

Добавлено 09.04.21, 19:02
Если серьёзно...

Цитата sergioK @ 07.04.21, 17:37

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

Если ПО относится к высококритичному, ты заманаешься его писать, тестировать и сертифицировать. В прошлый наш проект на одну из функциональностей на ~475Кб сырцов (с комментами и пустыми строками, шапками трассировкой на требования итп) мы только по завершению этапа тестирования отгрузили тестов с их результатами на 187Мб, а общий объём отчётов по этапу верификации составил чуть меньше 2Гб. И это только наша сторона процесса без планов, аудита, анализов и рассмотрения, ревью итп, а сколько туда добавили подрядчики, я без понятия.
К тому же у любого такого ПО есть чёткие требования к программно-аппаратному окружению. На первом попавшемся ноуте с АЛИшки под свежайшей Убунтой его запустить обычно беспроблем, вот только первый попавшийся ноут со свежайшей Убунтой 100пудово не будет соответствовать правилам эксплуатации этого ПО. И в этом случае все вопросы к врачу или его начальникам, по тех.обеспечению в частности. И не дай бог там внезапно обнаружится когда-то вставлявшаяся флешка или некогда активный клиент телеги. Обычно такое делают просто невозможным, но если вдруг врач хакер...
Но вообще, если такие вылеты допустимы, значит некритично. Оценка критичности лежит на заказчике и прописывается в ТЗ, и чёрта с два он её укажет занижено или сертификат будет получен без следования отраслевым стандартам. Даже у нас, ибо никто не захочет садиться на пожизненно, это эму не ведро алмазов с рудников стырить.

Цитата sergioK @ 07.04.21, 17:37

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

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

Цитата sergioK @ 07.04.21, 17:37

Мало что ли качественных, хороших програм за разумную цену?

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

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

Добавлено 10.04.21, 08:42

Цитата Qraizer @ 09.04.21, 18:19

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

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

Добавлено 10.04.21, 09:19

Цитата Qraizer @ 09.04.21, 18:19

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

Ну я вытягиваю, в тех задачах что мне надо, конечно с неточностями, я же не супермер,
Вот тебе живой пример, буквально два месяца назад, решили на passwowd regex добавить,
Я первое что попросил у VPR&D это день на мануалы DB, не дали сказали не надо, а там центральное место в системе,
пришлось кучу тестов писать, неделю, а надо было в DB поле поставить типа regex, перегрусить стандартный метод
фраймворка кинуть exception в методе, все кто вызвывают обязаны будут его обработать,компайлер заставит,
работы на день ну два, ну три с учетом изучения, три программера на проэкте были еще двое до меня ушли,
и шеф, так ни один не думал об этом, неделю с лишним возился, и БД в облаке, каждый вызов 10-12 секунд ждешь,
нет чтобы локально поставить, один по образованию психолог-математик, другая экономист , третий физик,
мозги и них в порядке но их никто не учил писать грамотно, взяли RDBMS а там 4Т ограничение и никто не думал,
как ты думаешь качественный продукт выйдет у них ? Если вообще выйдет,

Мой же джун написал скрипт для винды а потом для Мэка потребовался, вот теперь две версии,
нк он ладно не знал, он хотел писать на Питоне но ему сказали что в Винде нет Питона версии 3,0,
ну ландо допустим не знали, но прочитать то можно , потратив по-часа времени,

И как вот такое коментировать без мата ?

Добавлено 10.04.21, 09:26

Цитата applegame @ 10.04.21, 07:34

Цитата korvin @ 06.04.21, 13:59

kopilov, https://twitter.com/joshbloch/status/583813919019573248?s=21

ФП-шники используют связные списки постоянно.

Цитата

linked lists seen to be of more interest in functional languages, eg the default seq implementation in Scala is a linked list.

Это юмор такой? и кто это ФП-шники?

[korvin]

applegame, там речь не про связные списки вообще, а про java.util.LinkedList

https://twitter.com/joshbloch/status/584272581320052736?s=21

Цитата

Don't get me wrong; I love linked lists. They're as useful in C as they are in Scheme. But LinkedList is another matter entirely.

[applegame]

Цитата korvin @ 10.04.21, 09:39

applegame, там речь не про связные списки вообще, а про java.util.LinkedList

https://twitter.com/joshbloch/status/584272581320052736?s=21

Цитата

Don't get me wrong; I love linked lists. They're as useful in C as they are in Scheme. But LinkedList is another matter entirely.

Ну, я бу не сказал, что двусвязные списки это "another matter entirely". Или я что-то недопонял?
Они конечно реже используются чем односвязные, но тоже хороши, и их использовал для оптимизации обхода бинарного дерева.

[Qraizer]

Цитата sergioK @ 10.04.21, 08:30

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

И слава богу, что нет. Желаю тебе, чтоб никогда и не было. Это очень скучное и неблагодарное дело. Если когда-либо сталкивался с продуктами с требованиями работоспособности 24/7, то это ерунда по сравнению с требованиями к высококритичному ПО.

Добавлено 10.04.21, 16:09
Просто для оценки планок. Когда-нибудь приходилось выкладывать в систему контроля версий объектный код и ассемблерные листинги с трассировкой на сырцы? Благо многие компиляторы это почти умеют сами. Почти. Учитывал ли реакцию твоего кода на INF и NaN? И вообще, приходилось ли обеспечивать сохранение работоспособности кода при любых невалидных воздействиях извне и немедленно возвращать свои выходы в номинальные диапазоны по прекращению невалидных воздействий? Приходилось ли собирать 100% структурное покрытие кода по MC/DC? Всего кода, не только твоего авторства. Объектного, не исходного. (Последнее, правда, обязательно только для уровня критичности level A.) Приходилось ли отказываться от стандартных библиотек и писать свои аналоги? Ради как раз 100% покрытия. Приходилось ли отказываться от некоторых возможностей языка, которые как раз и введены в основном ради отказоустойчивости? И всё из-за пресловутых 100%. Использовались ли методы доказательства корректности кода с опорой на тесты как доказательную базу? Именно доказательную, а не вероятностную. Общая алгебра, теория групп. Использовались ли математические методы доказательства правильности разработанных алгоритмов? Использовались ли методы доказательства корректности реализаций этих алгоритмов? Даташиты, официальные мануалы, стандарты языков и стандарты кодирования + теория множеств и формальная логика. Не превышал ли суммарный объём работ по документированию продукта на два порядка работы по разработке и тестированию этого кода? Тесты писаны вручную и без использования любых средств автоматизации, основанных на изучении кода? Тесты, созданные на основе задокументированного поведения кода, которое в свою очередь выполнено на человеческом языке, исполнялись и получали результаты на основе реального поведения объектного кода, из системы контроля версий который? Подвергались ли любые инструменты, как собственной разработки, так и сторонние, включая компиляторы, загрузчики, генераторы отчётности итп, процедурам квалификации, на основе результатов которых на них выдавалось заключение о том, что они подходящи для применения в сфере высококритичного ПО, и полученным с их помощью результатам можно доверять при условии невыхода условий их эксплуатации за указанные в заявке на квалификацию рамки? На закуску: приходилось ли проектировать системы с учётом возможных неизвестных аппаратных багов в процессорах?

Добавлено 10.04.21, 16:37
Я ж говорю, колибри не полетит. А что за дроздов... уверен, sergioK, и непротекающий водопровод ты сумеешь спроектировать с логгированием всех подозрительных событий, и безопасный к взрывам газопровод в квартиру проведёшь, и отказоустойчивую аутентификацию наладишь. Почти уверен. И стоить это будет $49.95 за копию. Нехрен ни к селу ни к городу троллей цитировать, ты ж и сам знаешь, что это всё враки.

Сообщение отредактировано: Qraizer - 10.04.21, 20:41

[sergioK]

Цитата Qraizer @ 10.04.21, 15:58

Учитывал ли реакцию твоего кода на INF и NaN? И вообще, приходилось ли обеспечивать сохранение работоспособности кода при любых невалидных воздействиях извне и немедленно возвращать свои выходы в номинальные диапазоны по прекращению невалидных воздействий?

я не пишу на low level, мне это зачем, будет надо разберусь,

Добавлено 11.04.21, 05:14

Цитата Qraizer @ 10.04.21, 15:58

Учитывал ли реакцию твоего кода на INF и NaN? И вообще, приходилось ли обеспечивать сохранение работоспособности кода при любых невалидных воздействиях извне и немедленно возвращать свои выходы в номинальные диапазоны по прекращению невалидных воздействий?

Я с железом не пишу, в ранках своих задач да приходилось,
Что ты хочешь сказать? Качественный код можно не писать? Можно так более менее или хуже?
Я уже рассказвывл историю с операцией сыну, как бы ты среагировал в такой систуации?
Будешь думать про волопровод 49,5$ ?

Ты ответь, без бабы мансов потом про дрозда, продолжим

[korvin]

Цитата applegame @ 10.04.21, 15:29

Ну, я бы не сказал, что двусвязные списки это "another matter entirely"

Ну я бы не сказал, что фразу "But LinkedList is another matter entirely" стоит продолжать пытаться читать как-то по-другому, чем "But LinkedList is another matter entirely".

"You're probably better off with ArrayDeque. Measure and find out "
https://twitter.com/joshbloch/status/756538672724533248?s=20

"Resizable-array implementation of the Deque interface. Array deques have no capacity restrictions; they grow as necessary to support usage. They are not thread-safe; in the absence of external synchronization, they do not support concurrent access by multiple threads. Null elements are prohibited. This class is likely to be faster than Stack when used as a stack, and faster than LinkedList when used as a queue."
doc

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

Сообщение отредактировано: korvin - 11.04.21, 05:53

[applegame]

Цитата korvin @ 11.04.21, 05:44

Ну я бы не сказал, что фразу "But LinkedList is another matter entirely" стоит продолжать пытаться читать как-то по-другому, чем "But LinkedList is another matter entirely".

Там фраза чуть длиннее:

Цитата

Don't get me wrong; I love linked lists. They're as useful in C as they are in Scheme. But LinkedList is another matter entirely.

Лично я полагаю, что "LinkedList" отличается от "linked list", которые "I love", только тем, что первые двусвязные, а вторые односвязные. Тут и не пахнет "another matter entirely", так как эти списки весьма похожи.

Цитата

This class is likely to be faster than Stack when used as a stack, and faster than LinkedList when used as a queue.

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

Цитата korvin @ 11.04.21, 05:44

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

Можно и то и другое. Двусвязные списки нельзя сделать эффективно персистентными (Persistent data structure), как, собственно, и обычные масивы. Только CoW. Поэтому они бесполезны в ФП.

Добавлено 11.04.21, 10:32
Почитал про ArrayList и ArrayDeque, внутри обычные массивы. А значит существуют случаи, когда LinkedList будет быстрее. Например если у нас миллион элементов в списке/очереди.

Сообщение отредактировано: applegame - 11.04.21, 10:37

[Qraizer]

Цитата sergioK @ 11.04.21, 04:52

я не пишу на low level, мне это зачем, будет надо разберусь,

Первая стадия пошла. А если серьёзно, кто тебя будет спрашивать-то? Или ты считаешь, что с датчиков приходят классы с инвариантами?

Цитата sergioK @ 11.04.21, 04:52

Что ты хочешь сказать? Качественный код можно не писать? Можно так более менее или хуже?

Что корректность твоего кода не должна зависеть от корректности окружения, с которым он взаимодействует. Пришла тебе от термодатчика температура пациента 1180,8° (нарушение единичного события) или там пульс INT_MIN (по IEEE это вполне себе целочисленная неопределённость). Причина – плохой контакт на разъёме. Ну как, вторая стадия уже на подходе?

Цитата sergioK @ 11.04.21, 04:52

Я уже рассказвывл историю с операцией сыну, как бы ты среагировал в такой систуации?

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

Добавлено 11.04.21, 16:25
Если ты к тому, что а вдруг тебе бы пришлось этот софт писать, беги от подобных заказов. Стадии ещё не кончились, впереди ещё три. И сесть может быть и не сядешь, но как себя поведут твои начальники и заказчики, предсказывать не берусь.

Добавлено 11.04.21, 16:30

Цитата sergioK @ 11.04.21, 04:52

Будешь думать про волопровод 49,5$?

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

[sergioK]

Цитата Qraizer @ 11.04.21, 16:24

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

Да понятия не имеею как они приходят, наверно есть способы как с этим работать
Я с вебом работаю у меня все приходит как надо,

Добавлено 12.04.21, 04:23

Цитата Qraizer @ 11.04.21, 16:24

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

Я про наличие сертификата у софту слышу впервые в жизни, ISO никаких гарантий на надежность не требует,
ну даже если он есть у них, крупная больница все таки, то что ? Куда бы ты писал и что ?
А кто вообще решает критичный ли софт, если кого то убили то да, а если поцарапали то нет ?
ISO гарантий не требует,

Сообщение отредактировано: sergioK - 12.04.21, 18:38

[korvin]

Цитата applegame @ 11.04.21, 10:19

Лично я полагаю, что "LinkedList" отличается от "linked list", которые "I love", только тем, что первые двусвязные, а вторые односвязные.

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

Цитата applegame @ 11.04.21, 10:19

Можно и то и другое.

Пример, приведи.

Цитата applegame @ 11.04.21, 10:19

как, собственно, и обычные масивы.

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

Цитата applegame @ 11.04.21, 10:19

А значит существуют случаи, когда LinkedList будет быстрее. Например если у нас миллион элементов в списке/очереди.

За счёт чего LinkedList будет быстрее на большом количестве элементов?

[applegame]

Цитата korvin @ 12.04.21, 05:22

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

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

Цитата korvin @ 12.04.21, 05:22

Пример, приведи.

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

Цитата korvin @ 12.04.21, 05:22

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

"Достаточно" понятие растяжимое. Доступ по индексу у такого "массива" будет не константный.

Цитата korvin @ 12.04.21, 05:22

За счёт чего LinkedList будет быстрее на большом количестве элементов?

Не на всех операциях, но добавление элемента у LinkedList всегда O(1), а у ArrayList/ArrayDeque в худшем случае O(n).

[kopilov]

Цитата applegame @ 12.04.21, 07:21

Не на всех операциях, но добавление элемента у LinkedList всегда O(1), а у ArrayList/ArrayDeque в худшем случае O(n).

Да, я примерно этот аргумент и использовал…

Цитата korvin @ 12.04.21, 05:22

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

О, эти рассуждения вида «что хотел сказать / имел ввиду автор»

Цитата sergioK @ 11.04.21, 04:52

я не пишу на low level, мне это зачем,

а теперь возващаемся к моему вопросу: если не пишешь на low level, зачем писать системные функции, вроде realloc?

[applegame]

Цитата kopilov @ 12.04.21, 07:43

О, эти рассуждения вида «что хотел сказать / имел ввиду автор»

Автор, судя по всему, просто некомпетентный лопух. Односвязные списки в скале он видите ли любит, а LinkedList в жава это "совсем другое дело".
Односвязные списки в ФП - вынужденная мера из-за требования иммутабельности, а в плане производительности они полное говно.
Даже сраную Deque в ФП приходится городить на паре односвязных списков, из-за чего удаление элемента с хвоста может встать в O(n), а у обычного двусвязного списка эта операция всегда занимает O(1).
Лично я не люблю односвязные списки, я мирюсь с ними.

Сообщение отредактировано: applegame - 12.04.21, 07:56

[korvin]

Цитата applegame @ 12.04.21, 07:21

Если двусвязный список сделать встроенным в язык типом

То что? Его всё равно нужно как-то реализовать.

Цитата applegame @ 12.04.21, 07:21

при добавлении новых элементов просто копировать его целиком

Цитата applegame @ 12.04.21, 07:21

Бесполезно

ЧТД

Цитата applegame @ 12.04.21, 07:21

"Достаточно" понятие растяжимое. Доступ по индексу у такого "массива" будет не константный.

Но близкий к константному: log_base. Для дефолтного base=32 и массива из миллиона элементов доступ будет стоить 4.

Цитата applegame @ 12.04.21, 07:21

Не на всех операциях, но добавление элемента у LinkedList всегда O(1), а у ArrayList/ArrayDeque в худшем случае O(n).

Ты ещё пойди поймай этот худший случай. И ты не учитываешь, что у LinkedList по сравнению с ArrayDeque:
1) создаётся объект ноды на каждый элемент, что нагружает GC;
2) каждая нода хранит 3 указателя, что увеличивает потребление памяти в 3 раза независимо от количества элементов (в случае с AD зависит от size/capacity, заполненный даже наполовину AD имеет меньший оверхед по памяти);
3) ноды могут распологаться в памяти где попало, что отменяет возможную векторизацию при доступе.

Цитата applegame @ 12.04.21, 07:55

Автор, судя по всему, просто некомпетентный лопух.

Joshua Bloch — некомпетентный лопух? Ну-ну. )

Сообщение отредактировано: korvin - 12.04.21, 09:15

[Qraizer]

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

Добавлено 12.04.21, 12:49
P.S. ISO можешь сразу в топку, имеющиеся у тебя сертификаты на стенку для историй на пенсии. Не с этими стандартами в высококритичность, они подходят не более чем для бизнеса или максимум военки.

[applegame]

Цитата korvin @ 12.04.21, 08:42

То что? Его всё равно нужно как-то реализовать.

А в чем проблема его реализовать? Нет никакой проблемы его реализовать.

Цитата korvin @ 12.04.21, 08:42

ЧТД

Какое из твоих утверждений ЧТД?

Цитата korvin @ 12.04.21, 08:42

Но близкий к константному: logbase. Для дефолтного base=32 и массива из миллиона элементов доступ будет стоить 4.

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

Цитата korvin @ 12.04.21, 08:42

Ты ещё пойди поймай этот худший случай. И ты не учитываешь, что у LinkedList по сравнению с ArrayDeque:

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

Цитата korvin @ 12.04.21, 08:42

Joshua Bloch — некомпетентный лопух? Ну-ну. )

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

Сообщение отредактировано: applegame - 12.04.21, 17:23

[sergioK]

Цитата applegame @ 12.04.21, 17:19

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

Да приколист, он взявший имя автора известной книги по Яве, IMHO

Добавлено 12.04.21, 19:26

Цитата applegame @ 12.04.21, 17:19

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

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

Добавлено 12.04.21, 19:42

Цитата Qraizer @ 12.04.21, 12:47

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

Ну да именно о материях причем абстактных, как ты любишь, если бы еще понятным языком писал
Я бы может и понял о чем речь, я не критичных систем не пишу уже лет 10,
хотя некоторые считают что их пишут только на С/C++,

Добавлено 12.04.21, 19:51

Цитата Qraizer @ 12.04.21, 12:47

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

В военке как раз и самые высокие стандрты,

Добавлено 12.04.21, 19:58

Цитата Qraizer @ 09.04.21, 18:19

Кроме нас, его верифицировать имеют право только ещё несколько контор в Москве.

Вас это кого? И кто сказал что правы имеено вы, а не тот кто задумал некий код под свою
конкретную задачу?

Сообщение отредактировано: sergioK - 12.04.21, 19:58

[Qraizer]

Цитата sergioK @ 12.04.21, 19:22

Я бы может и понял о чем речь, я не критичных систем не пишу уже лет 10,
хотя некоторые считают что их пишут только на С/C++,

Ты их и не писал никогда. И – да, только на C/C++. Ещё немного на ассемблере, но совсем чуть-чуть, когда надо кристалл инициализировать, например. Ещё Аду кое-где пытаются использовать, но там считанные проценты проектов: немного экономят в разработке, жутко теряют в эксплуатации.

Цитата sergioK @ 12.04.21, 19:22

В военке как раз и самые высокие стандрты,

Ты будешь удивлён...

Цитата sergioK @ 12.04.21, 19:22

Вас это кого? И кто сказал что правы имеено вы, а не тот кто задумал некий код под свою
конкретную задачу?

Тот, кто задумал, не выбирает, ему указывают. На того, у кого есть разрешение на работу в этой сфере. Разрешением является наличие сертификата. Ничего необычного, всё как у всех, сертификаты вот только разные. У кого есть подходящие, известно, и список небольшой; кому оно надо, знает куда смотреть, чтоб выйти с предложением контракта. Так на нас и вышли, например. Кто – не скажу, он под санкциями, мы туда не хотим, а гугл, паразит, быстро индексирует. Заказчик же в свою очередь тоже подрядчик своего заказчика, а он хорошо известен в Росавиации.

Цитата sergioK @ 12.04.21, 19:22

если бы еще понятным языком писал

Вот с этого и надо было начинать.

[sergioK]

Цитата Qraizer @ 13.04.21, 18:45

Цитата sergioK @ 12.04.21, 19:22

Я бы может и понял о чем речь, я не критичных систем не пишу уже лет 10,
хотя некоторые считают что их пишут только на С/C++,

Ты их и не писал никогда. И – да, только на C/C++.

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

Цитата

Safety-critical systems are those systems whose failure could result in loss of life, significant property damage, or damage to the environment.

https://smallbusinessprogramming.com/safety...er-should-know/


Система распознавания графика работы сердца может быть написана хоть на VB, или распознавания рака,
баг в такой система может стоить жизни, система управления биржей тоже не всегда на С/С++, сбой
может привести с банкротсву, или поиска криминальних деятелей через их мобильники, сделал баг, он за это время
грабанул кого или по хуже еще, А 24/7 полно систем не на С/С++, не говоря уже о готовый решениях типо облака,


Никогда не слышал чтобы на софт был нужен сертификат, спросил друга он 25лет в RT + embedded +
networking + security, он тоже не слышал, требования ставит заказчик

Причем тут кристал или датчик, то что ты говоришь называеться интеграция в твоем случае Software and hardware или firmware.
Ты мне про какую то другую реальность рассказываешь, тебе очевидную а мне нет,

Добавлено 13.04.21, 20:22

Цитата Qraizer @ 13.04.21, 18:45

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

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

Добавлено 13.04.21, 20:25

Цитата Qraizer @ 13.04.21, 18:45

В военке как раз и самые высокие стандрты,

Ты будешь удивлён...

Цитата sergioK @ 12.04.21, 19:22

Тем что они не высокие ? То есть ракета может сбит мирный Боинг, и ничего страшного?

[Qraizer]

Цитата sergioK @ 13.04.21, 20:08

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

Значит это не высококритичный софт. Без обид. Как вариант – это он такой до первого судебного разбирательства, но это вряд ли. Если в вашей деятельности нет хотя бы одной из выше мной перечисленной активити, у вас обычный бизнес. И я перечислил отнюдь не все характерные отличия модели высококритичной разработки от всем хорошо известной бизнес-разработки, только наиболее характерные. Вообще-то в отраслевых стандартах около 170-и пунктов, напротив каждого из которых аудиторы должны будут поставить галку, и по каждому пункту выпускается документация, которую аудит тоже проверяет перед расстановкой галок. Хотя бы одной галки нет, сертификата не будет. Наших пунктов тут около 60. Прицепом ещё 30, 20 из которых мы, выполнив, по контракту сняли с себя и дальше их ведёт заказчик. + на нас лежит часть ещё 10-и пунктов, потому что они неотъемлемы от всего процесса в целом. Количество документации я выше приводил, на её выпуск уходит на 2 порядка больше ресурсов проекта, чем на код и железки. И это первый шлагбаум на пути тех, кто погонится за рублём и вдруг возомнит, что потянет эту сферу.

Цитата sergioK @ 13.04.21, 20:08

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

Ты идёшь в правильном направлении, за государство вот в частности, но вообще-то это просто совпадение. Просто обычно ни у кого, кроме государства, денег нет на софт такой категории. И в целом ты, конечно, в чём-то прав. Отсутствие денег у нашей медицины не секрет, и вполне объясняет не отнесение сферы медицины к области высококритичной ИТ-разработки. Неунас с этим куда прозрачнее.
Но во всём остальном мимо. ...

Цитата sergioK @ 13.04.21, 20:08

Никогда не слышал чтобы на софт был нужен сертификат

... Мы не проверяем, как работает машина, мы проверяем, как она проектируется и разрабатывается. Это как раз и отличает методы работы в высококритичной области от методов бизнеса: сертифицируется не продукт, а жизненный цикл его разработки. Сертифицируется не продукт, а процесс его создания. Весь. Вообще весь. С момента, как вообще у кого-то возникла идея о том, что неплохо было бы изобрести этот новый продукт с вот такими уникальными (а иначе зачем? дорогие "велосипеды" никому не нужны) качествами и вплоть до момента схода с конвейера первой модели серийного его производства. Это абсолютно отличная от подходов бизнеса модель. Есть даже такие документы, как описывающий процесс планирования цикла проектирования изделия, например. Прикинь.
А вот проверкой "исправна ли машина" действительно занимаются специально обученные люди. Но занимаются они уже готовыми серийными изделиями и тратят куда меньше денег и времени. Процесс разработки может идти лет десять, и вовлечены в него оказываются тысячи людей, проверкой изделия занимается человек 10 в течение суток. Фактически это просто регулярные СТО, просто техника чуток посложнее. И когда до них доходит очередь, все причастные к сертифицированию процесса уже давно закончили все свои этапы, ибо первый образец просто не выпустят без наличия такого сертификата.

Добавлено 13.04.21, 23:21

Цитата sergioK @ 13.04.21, 20:08

Тем что они не высокие ? То есть ракета может сбит мирный Боинг, и ничего страшного?

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

Сообщение отредактировано: Qraizer - 13.04.21, 23:21

[sergioK]

Цитата Qraizer @ 13.04.21, 22:45

Значит это не высококритичный софт. Без обид. Как вариант – это он такой до первого судебного разбирательства, но это вряд ли.

Это же очень субьетивно,
Кто решает что критично а что нет, светофор не сработал авария трое погибщих,
закурил на бензоколонке датчик не сработал, из-за ошибке в программе или сигнализация,
это крититично или нет ?

Добавлено 14.04.21, 06:09

Цитата Qraizer @ 13.04.21, 22:45

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

Я что-то пропустил, где перечислил и что?
Я не адвокат, но я знаю что критичный продукт это тот где могут пострадать люди
или ущерб большой, какая разница не чем его писали то ?
У нас случай был банк поменял Вино версию XP на 2000, произошел сбой, вернули версию,
подлатые вроде заплатили банку, но это по слухам, адвокаты вроде договорились, больше ни очем подобном я
не слышал,

Сообщение отредактировано: sergioK - 14.04.21, 06:13

[D_KEY]

Вы просто используете разную терминологию.

[sergioK]

Цитата D_KEY @ 14.04.21, 06:13

Вы просто используете разную терминологию.

Вот мне тоже так показалось, это как на Аляске life stats after 40,
все думают что речть про возраст, а там про температуру речь,

[kopilov]

Цитата sergioK @ 14.04.21, 06:03

Я что-то пропустил, где перечислил и что?

Цитата Qraizer @ 10.04.21, 15:58

Просто для оценки планок. Когда-нибудь приходилось выкладывать в систему контроля версий объектный код и ассемблерные листинги с трассировкой на сырцы? Благо многие компиляторы это почти умеют сами. Почти. Учитывал ли реакцию твоего кода на INF и NaN? И вообще, приходилось ли обеспечивать сохранение работоспособности кода при любых невалидных воздействиях извне и немедленно возвращать свои выходы в номинальные диапазоны по прекращению невалидных воздействий? Приходилось ли собирать 100% структурное покрытие кода по MC/DC? Всего кода, не только твоего авторства. Объектного, не исходного. (Последнее, правда, обязательно только для уровня критичности level A.) Приходилось ли отказываться от стандартных библиотек и писать свои аналоги? Ради как раз 100% покрытия. Приходилось ли отказываться от некоторых возможностей языка, которые как раз и введены в основном ради отказоустойчивости? И всё из-за пресловутых 100%. Использовались ли методы доказательства корректности кода с опорой на тесты как доказательную базу? Именно доказательную, а не вероятностную. Общая алгебра, теория групп. Использовались ли математические методы доказательства правильности разработанных алгоритмов? Использовались ли методы доказательства корректности реализаций этих алгоритмов? Даташиты, официальные мануалы, стандарты языков и стандарты кодирования + теория множеств и формальная логика. Не превышал ли суммарный объём работ по документированию продукта на два порядка работы по разработке и тестированию этого кода? Тесты писаны вручную и без использования любых средств автоматизации, основанных на изучении кода? Тесты, созданные на основе задокументированного поведения кода, которое в свою очередь выполнено на человеческом языке, исполнялись и получали результаты на основе реального поведения объектного кода, из системы контроля версий который? Подвергались ли любые инструменты, как собственной разработки, так и сторонние, включая компиляторы, загрузчики, генераторы отчётности итп, процедурам квалификации, на основе результатов которых на них выдавалось заключение о том, что они подходящи для применения в сфере высококритичного ПО, и полученным с их помощью результатам можно доверять при условии невыхода условий их эксплуатации за указанные в заявке на квалификацию рамки? На закуску: приходилось ли проектировать системы с учётом возможных неизвестных аппаратных багов в процессорах?

Qraizer, а можно я присоединюсь к вопросу: вы — это кто? Ну или где можно посмотреть список контор, которые выдают сертификаты на высококритичный софт

[Qraizer]

Цитата sergioK @ 14.04.21, 06:03

Кто решает что критично а что нет

Есть сферы, где критично всё. Хотя и с разными уровнями. Там просто не бывает невысококритичного ПО. За остальные случаи я уже говорил: это решает заказчик, исходя из своих соображений эксплуатации целевого продукта. И дай ему бог не ошибиться.

Цитата sergioK @ 14.04.21, 06:03

Я что-то пропустил, где перечислил и что?

Не пропустил. Ты оттуда цитировал.

Цитата sergioK @ 14.04.21, 06:03

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

Это верно, но это не обязательно высококритичный продукт. Кроме того, возможные жертвы – это не единственный критерий. У нас как-то был проект от некоего оператора, не буду называть три большие буквы, которые хотели от нас полный цикл верификации виндового стека криптографии по упрощённой модели, ибо объём документации, понятное дело, ограничен. Кстати, тестирование должно выполняться без доступа к исходным кодам. Обычно его-таки дают, так дешевле, да и верификация в общем без анализа и рассмотрения многих аспектов требований и кода нереальна, но нужно всегда быть готовым к тому, что подсмотреть в коде ничего нельзя, есть только документация на него. Не уверен, я в нём не участвовал, хотя и консультировал по части архитектуры кода, работающего у винды на уровне ядра, но вроде бы это требовалось как часть процесса сертификации их банковских сервисов. С POSIX-ом им было проще, там открытый код. И да, это было давно, лет 10 как.

Добавлено 14.04.21, 11:29

Цитата kopilov @ 14.04.21, 07:19

вы — это кто?

https://checko.ru/company/aviaok-1036154001289 Информация в источниках может быть не вполне актуальной, сейчас мы из ООО кастуемся к АО. Спектр деятельности широкий, но помимо легко угадываемых по разделу дополнительной информации тут, они практически неактивны, поставщиков таких услуг и без нас хватает. Там просто все лицензии перечислены.

Цитата kopilov @ 14.04.21, 07:19

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

Конкретно в нашей сфере он один и хорошо известен. Возможно не обману, если упомяну РосАтом в сфере ядерной и атомной энергетики, но это неточно. Больше не знаю. Хотя Минздрав хотелось бы упомянуть, но ИМХО «это утопия» ©.

Добавлено 14.04.21, 11:44

Цитата Qraizer @ 14.04.21, 11:11

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

Кстати, уже постил куда-то, сбаяню. Мой любимый пример.
В документации сказано: «функция void sort(int *vec, size_t size) должна выполнять сортировку массива vec, размером size. Сортировка осуществляется по возрастанию, результат замещает исходный vec.» Требуется разработать набор тестовых сценариев для проверки этого требования. Естественно так, чтобы их можно было рассматривать как доказательную базу корректности реализации sort() согласно описанию её поведения. Если кому интересно, могут попробовать.
Пример, конечно искусственный, но он хорошо демонстрирует разницу в подходах к тестированию у нас и у бизнеса.

[sergioK]

Цитата Qraizer @ 14.04.21, 11:11

Цитата sergioK @ 14.04.21, 06:03

Кто решает что критично а что нет

Есть сферы, где критично всё. Хотя и с разными уровнями. Там просто не бывает невысококритичного ПО. За остальные случаи я уже говорил: это решает заказчик, исходя из своих соображений эксплуатации целевого продукта. И дай ему бог не ошибиться.

Цитата sergioK @ 14.04.21, 06:03

Я что-то пропустил, где перечислил и что?

Не пропустил. Ты оттуда цитировал.

Цитата sergioK @ 14.04.21, 06:03

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

Это верно, но это не обязательно высококритичный продукт. Кроме того, возможные жертвы – это не единственный критерий. У нас как-то был проект от некоего оператора, не буду называть три большие буквы, которые хотели от нас полный цикл верификации виндового стека криптографии по упрощённой модели, ибо объём документации, понятное дело, ограничен. Кстати, тестирование должно выполняться без доступа к исходным кодам. Обычно его-таки дают, так дешевле, да и верификация в общем без анализа и рассмотрения многих аспектов требований и кода нереальна, но нужно всегда быть готовым к тому, что подсмотреть в коде ничего нельзя, есть только документация на него. Не уверен, я в нём не участвовал, хотя и консультировал по части архитектуры кода, работающего у винды на уровне ядра, но вроде бы это требовалось как часть процесса сертификации их банковских сервисов. С POSIX-ом им было проще, там открытый код. И да, это было давно, лет 10 как.

Добавлено 14.04.21, 11:29

Цитата kopilov @ 14.04.21, 07:19

вы — это кто?

https://checko.ru/company/aviaok-1036154001289 Информация в источниках может быть не вполне актуальной, сейчас мы из ООО кастуемся к АО. Спектр деятельности широкий, но помимо легко угадываемых по разделу дополнительной информации тут, они практически неактивны, поставщиков таких услуг и без нас хватает. Там просто все лицензии перечислены.

Цитата kopilov @ 14.04.21, 07:19

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

Конкретно в нашей сфере он один и хорошо известен. Возможно не обману, если упомяну РосАтом в сфере ядерной и атомной энергетики, но это неточно. Больше не знаю. Хотя Минздрав хотелось бы упомянуть, но ИМХО «это утопия» ©.

Добавлено 14.04.21, 11:44

Цитата Qraizer @ 14.04.21, 11:11

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

Кстати, уже постил куда-то, сбаяню. Мой любимый пример.
В документации сказано: «функция void sort(int *vec, size_t size) должна выполнять сортировку массива vec, размером size. Сортировка осуществляется по возрастанию, результат замещает исходный vec.» Требуется разработать набор тестовых сценариев для проверки этого требования. Естественно так, чтобы их можно было рассматривать как доказательную базу корректности реализации sort() согласно описанию её поведения. Если кому интересно, могут попробовать.
Пример, конечно искусственный, но он хорошо демонстрирует разницу в подходах к тестированию у нас и у бизнеса.

У нас был курс алгоритмов учили такому, у нас таким математики занимаються, при унивеситетах,
но никак не в коммерческих компаниях,



С сайта

Цитата

Крупный поставщик
Организация поставила товаров или оказала услуг на сумму более 50 636 687 руб.

Я опять что-то не понимаю ?
это меньше 1 миилиона долларов, так ? , за 18лет работы ? но у нас это называеться киоск,
У нас ларек пивной в год больше дает, ничего личного

Цитата

Не входит в реестр недобросовестных поставщиков

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

А это что значит ?

Цитата

По данным ФНС, среднесписочная численность работников: 111

В фирме 111 работников ?

Цитата

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

1

И тут я тебе понять не могу, ну ясно, что все это требует лицензиий, только софт то причем тут ?

Сообщение отредактировано: sergioK - 14.04.21, 17:08

[Qraizer]

Цитата sergioK @ 14.04.21, 16:40

У нас был курс алгоритмов учили такому, у нас таким математики занимаються, при унивеситетах

А у нас вчерашние студенты. Что делать, статус ИТ-столицы обязывает

Цитата sergioK @ 14.04.21, 16:40

У нас ларек пивной в год больше дает, ничего личного

А он платит при этом миллионы человеко-часов 111-и работникам при белой бухгалтерии? А он использует при этом исключительно лицензионное ПО, потому как в противном случае ни один квалификационный сертификат не будет действительным? Документ, описывающий процесс развёртывания инструмента и полную методику работы с ним в наших процессах с приложенной лицензией на него как гарантом его подлинности, является хоть и далеко ещё не достаточным, но как ни крути неотъемлемым условием для получения квалификационного заключения по нему. И лицензии на подобного рода продукты из-за их малого рыночного спроса стоят нихрена себе. Просто для оценки вложений: в этом году нами была приобретена ещё одна лицензия на Rational Test Realtime за 2000000₱, а общий ордер на специализированное ПО, потраченный нами, нашим заказчиком и его головным распорядителем, за прошлый год составили около 125000000.

Цитата sergioK @ 14.04.21, 16:40

...

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

[sergioK]

Цитата Qraizer @ 15.04.21, 00:46

Цитата sergioK @ 14.04.21, 16:40

У нас ларек пивной в год больше дает, ничего личного

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

У нас нет не белой бугалтерии и не лицензионного ПО, во-первых законы работают,
во вторых можно систему обмануть можно только себе дороже, а в третих за ПО получают возврат, налогов и поддержку на случай сбоя,
за пиратское по можешь штраф около 300,000$ или срок, а если вдруг сбой дасть то бизнес понесет убытки,
Какой смысл стелять себе в ногу то ?

А теперь название темы посмотри , может не надо уходить так далеко, можно новую тему открыть ,
если есть желание



Добавлено 15.04.21, 05:06

Цитата Qraizer @ 15.04.21, 00:46

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

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

Добавлено 15.04.21, 05:24

Цитата Qraizer @ 15.04.21, 00:46

А он платит при этом миллионы человеко-часов 111-и работникам при белой бухгалтерии?

У нас человеко-часов при дейсвующем бизнесе никто не считает, ну мне не известно,
в одном из 111 в другом бизнесе 11, не факт что первый круче, да и не математика это считать
можно по разному, полно всяких трюков(законных),

Сообщение отредактировано: sergioK - 15.04.21, 05:24

[kopilov]

sergioK, а кто первым ушёл от темы? Qraizer по нашей с тобой просьбе («вы — это кто?») дал ссылку на компанию, опосредованную (на независимый каталог — видимо, потому, что гугл, паразит, быстро индексирует). А ты уже начал выводы строить.
Ну и, раз такая пьянка, я тоже немного карты раскрою

Добавлено 15.04.21, 08:25

Цитата sergioK @ 15.04.21, 04:56

У нас ларек пивной в год больше дает, ничего личного

Ага, это не личное, это общественное: бухать наш народ любит

[Qraizer]

Цитата sergioK @ 15.04.21, 04:56

У нас человеко-часов при дейсвующем бизнесе никто не считает, ну мне не известно

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

Цитата sergioK @ 15.04.21, 04:56

У нас нет не белой бугалтерии и не лицензионного ПО, во-первых законы работают

Давай только без тролльства. Я ж не за вас, а за пресловутый ларёк, который ты упомянул.
И я не говорил, что наши прибыли баснословны. Это вообще к предмету высококритичности не имеет отношения, государственные кампании вообще на это могут положить и сосать бюджет, пока дают. Пока у государства бюджет терпение не лопнет. Мы же – частная кампания, в отличие от наших заказчиков, к слову, и позволить себе отрицательный баланс не можем. Так что приведённая инфа говорит об эффективности нашей работы очень даже убедительно. Ну, по крайней мере тем, кто понимает. Из негосударственных я знаю только ещё одну кампанию в этой сфере, и она московская.

Добавлено 15.04.21, 14:19

Цитата kopilov @ 15.04.21, 08:02

...на независимый каталог — видимо, потому, что гугл, паразит, быстро индексирует...

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

Добавлено 15.04.21, 14:25
Ну так как насчёт задачки? Никто тестированием не занимался, что ли? Если сложно, можно попробовать попроще: "функция int sqeq(float a, float b, float c, float *x1, float *x2) должна решать квадратное уравнение с коэффициентами a, b и c. Выходные параметры x1 и x2 заполняются корнями уравнения, возвращаемое значение 1, если x1 и x2 успешно рассчитаны, или 0 в противном случае." С этой задачи у нас обычно начинается обучение джунов.

Сообщение отредактировано: Qraizer - 15.04.21, 14:29

[sergioK]

Цитата Qraizer @ 15.04.21, 14:12

Ну не свой, а вон тот, про дроздов и строителей.

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

Вот и придумали шутку про дроздов, а в каждой шутке доля правды, as smaller as better

Добавлено 15.04.21, 19:51

Цитата Qraizer @ 15.04.21, 14:12

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

В вашей это в какой ? ты же програмист или нет ?

Добавлено 15.04.21, 20:04

Цитата Qraizer @ 15.04.21, 14:12

я после второй прививки немного свободен.

И какая связь ? после второй прививки нельзя работать?

Добавлено 15.04.21, 20:15

Цитата Qraizer @ 15.04.21, 00:46

Что делать, статус ИТ-столицы обязывает

Таганрог это столица IT ? Или это была ирония ?

[korvin]

Цитата applegame @ 12.04.21, 17:19

А в чем проблема его реализовать? Нет никакой проблемы его реализовать.

В том, что любая операция добавления/изменения приводит к созданию полной копии списка.

Цитата applegame @ 12.04.21, 17:19

Какое из твоих утверждений ЧТД?

Оно было одно:

Цитата

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

Цитата applegame @ 12.04.21, 17:19

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

Не намного.

Цитата applegame @ 12.04.21, 17:19

Возможно, что LinkedList - просто корявая реализация двусвязного списка

1) то что я перечислил, не особенности реализации LinkedList, а особенности двусвязных списков как структуры данных в принципе.
2) я тебе с самого начала говорил, что в твитте речь про LinkedList, но ты продолжил что-то додумывать.

Цитата applegame @ 12.04.21, 17:19

Мои двусвязные списки (не на жабе, конечно) используют пулы

Пулы чего?

Цитата applegame @ 12.04.21, 17:19

и добавляют по два указателя к каждой ноде.

Вот и получается x3: (указатель на объект + prev + next) вместо одного указателя на объект.

Цитата applegame @ 12.04.21, 17:19

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

Ты сделал предположение по каким-то своим фантазиям, которые упорно продолжаешь фантазировать.

Сообщение отредактировано: korvin - 17.04.21, 09:28

[applegame]

Цитата korvin @ 17.04.21, 07:45

В том, что любая операция добавления/изменения приводит к созданию полной копии списка.

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

Цитата korvin @ 17.04.21, 07:45

Оно было одно:

Цитата

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

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

Цитата korvin @ 17.04.21, 07:45

Не намного.

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

Цитата korvin @ 17.04.21, 07:45

1) то что я перечислил, не особенности реализации LinkedList, а особенности двусвязных списков как структуры данных в принципе.
2) я тебе с самого начала говорил, что в твитте речь про LinkedList, но ты продолжил что-то додумывать.

В твите речь не только о LinkedList, но ты продолжаешь игнорировать половину твита.

Цитата korvin @ 17.04.21, 07:45

Пулы чего?

Пулы нод, для минимизации времени аллокации/освобождения памяти под ноду.

Цитата korvin @ 17.04.21, 07:45

Вот и получается x3: (указатель на объект + prev + next) вместо одного указателя на объект.

Указатель на объект в любом случае есть. Поэтому получается +2*sizeof(size_t) на элемент, а не x3. В C/C++/D часто можно хранить в ноде сам объект, а не указатель на него, что позволяет сэкономить еще один указатель.

Цитата korvin @ 17.04.21, 07:45

Ты сделал предположение по каким-то своим фантазиям, которые упорно продолжаешь фантазировать.

Какие фантазии? Автор прямо заявил, что любит односвязные списки, а LinkedList - это что-то совершенно другое. На мой вопрос, что именно "это совершенно другое" ты, видимо, ответить не в состоянии. Java мутабельный язык и в нём не прокатывает аргумент о проблемах персистентности. А в остальном получается, что LinkedList и односвязные списки - близнецы братья. Поэтому я и делаю вывод, что автор сморозил ерунду.

Сообщение отредактировано: applegame - 18.04.21, 08:40

[korvin]

Цитата applegame @ 18.04.21, 08:20

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

При чём тут кортежи? Если ты используешь кортежи вместо массивов/списков, то ты используешь их неправильно.

Цитата applegame @ 18.04.21, 08:20

Ленивость - это вообще ортогональное явление. Сами списки не могут быть ленивыми - это бессмыслица. Ленивыми могут быть операции над самими списками или их элементами

ll = [ print 1 , print 2 , print 3 ]

Какие операции тут ленивые?

https://ideone.com/L5Toq1

Ленивые списки на Scheme

(define-syntax lazy-cons
  (syntax-rules ()
    ((_ head tail) (cons (delay head) (delay tail)))))
 
(define (lazy-head ll)
  (force (car ll)))
 
(define (lazy-tail ll)
  (force (cdr ll)))
 
(define-syntax lazy-list
  (syntax-rules ()
    ((_ x)      (lazy-cons x '()))
    ((_ x . xs) (lazy-cons x (lazy-list . xs)))))
 
;;; ----------------------------------------------------------------
 
(define ll (lazy-list (print 1) (print 2) (print 3)))
 
(lazy-head (lazy-tail ll))

https://ideone.com/BexV68

и на Java. Синтаксического сахара только не хватает

import java.util.function.Supplier;
 
/* Name of the class has to be "Main" only if the class is public. */
class Ideone {
 
    public static void main (String[] args) throws java.lang.Exception {
        var ll = Lazy.list( () -> print(1), () -> print(2), () -> print(3) );
        ll.tail().head();
    }
 
    private static Unit print(Object o) {
        System.out.println(o);
        return Unit.UNIT;
    }
}
 
final class Lazy {
 
    public static <T> Promise<T> delay(Supplier<T> expr) {
        return new Promise<>(expr);
    }
 
    public static <T> List<T> cons(Supplier<T> headExpr, Supplier<List<T>> tailExpr) {
        return new List<>(new Promise<>(headExpr), new Promise<>(tailExpr));
    }
 
    public static <T> List<T> nil() {
        @SuppressWarnings("unchecked")
        var nil = (List<T>) List.NIL;
        return nil;
    }
 
    @SafeVarargs
    public static <T> List<T> list(Supplier<T>... values) {
        if (values == null || values.length == 0) {
            return nil();
        }
        return list(values, 0);
    }
 
    private static <T> List<T> list(Supplier<T>[] values, int headCursor) {
        if (headCursor == values.length) {
            return nil();
        }
        return new List<>(new Promise<>(values[headCursor]), new Promise<>(() -> list(values, headCursor+1)));
    }
 
    private Lazy() {
        throw new UnsupportedOperationException("utility class");
    }
}
 
final class List<T> {
 
    static final List<?> NIL = new List<>(null, null);
 
    private final Promise<T> head;
    private final Promise<List<T>> tail;
 
    List(Promise<T> head, Promise<List<T>>tail) {
        this.head = head;
        this.tail = tail;
    }
 
    public T head() {
        return head.force();
    }
 
    public List<T> tail() {
        return tail.force();
    }
}
 
final class Promise<T> {
 
    private static final Object undefined = new Object();
 
    private final Supplier<T> delayedExpression;
 
    @SuppressWarnings("unchecked")
    private T value = (T) undefined;
 
    Promise(Supplier<T> expr) {
        this.delayedExpression = expr;
    }
 
    public T force() {
        if (value == undefined) {
            value = delayedExpression.get();
        }
        return value;
    }
}
 
final class Unit {
 
    public static final Unit UNIT = new Unit();
 
    private Unit() {}
}

https://ideone.com/r0ttxo

Цитата applegame @ 18.04.21, 08:20

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

Ты путаешь тёплое с мягким.
1) никто в ФП не парится с хеш-таблицами
2) чистые функциональные хеш-таблицы реализуются точно также, как и функциональные массивы — с использованием деревьев и частичным копированием — и имеют точно такую же сложность.

Цитата applegame @ 18.04.21, 08:20

В твите речь не только о LinkedList, но ты продолжаешь игнорировать половину твита.

Но речи о single-linked-list vs double-linked-list там нет, так что нет, не игнорирую.

Цитата applegame @ 18.04.21, 08:20

Пулы нод, для минимизации времени аллокации/освобождения памяти под ноду.

Т.е. ты
1) практически делаешь работу аллокатора
2) никак не решаешь отсутствие векторизации
3) усложняешь структуру данных / её использование, вместо того, чтобы попробовать другую структуру, не имеющую таких проблем
отличное решение, молодец.

Цитата applegame @ 18.04.21, 08:20

Указатель на объект в любом случае есть. Поэтому получается +2*sizeof(size_t) на элемент, а не x3.

1(указатель на объект) + 2 = 3, поэтому x3. Если ты почему-то думал, что x3 = 1+3, то нет.

Цитата applegame @ 18.04.21, 08:20

Автор прямо заявил, что любит односвязные списки

Нет, он написал

Цитата

Don't get me wrong; I love linked lists. They're as useful in C as they are in Scheme.

Ладно Scheme, но с чего ты взял, что «linked lists ... in C» означает «односвязные списки»? В C нет двусвязных? Может, ему, например, нравятся интрузивные двусвязные списки в Си?

Цитата applegame @ 18.04.21, 08:20

Java мутабельный язык

Ты теперь ещё и терминологию какую-то выдумываешь.
В Java нельзя описывать иммутабельные объекты? Это запрещено на уровне JVM? Как же Scala и Clojure работают?
Может их не рекомендуют к использованию? Да нет, наоборот, рекомендуют. Вот и в стандартной библиотеке давно появилось StreamAPI для работы с коллекциями в функциональном стиле, а неизменяемые обёртки для стандартных коллекций в JDK существуют с незапамятных времён.

Добавлено 20.04.21, 21:10

Цитата sergioK @ 12.04.21, 19:22

Да приколист, он взявший имя автора известной книги по Яве, IMHO

Это и есть автор известной книги по Яве, а также части JDK, в том числе и LinkedList.

Цитата sergioK @ 12.04.21, 19:22

Стандартный класс, который использует полмира уже лет 20, не нравиться

Какие полмира? Кто его использует? Все хоть сколько-нибудь адекватные люди если и используют его, то крайне редко. Ты тоже любишь пофантазировать?
https://discuss.kotlinlang.org/t/why-kotlin...ntation/15991/2

Цитата sergioK @ 12.04.21, 19:22

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

И я не понимаю, зачем, если есть замечательные ArrayList и ArrayDeque.

Добавлено 20.04.21, 21:18
ArrayList vs LinkedList benchmark

Сообщение отредактировано: korvin - 20.04.21, 22:11

[sergioK]

Цитата korvin @ 20.04.21, 20:29

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

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

Добавлено 21.04.21, 05:39

Цитата korvin @ 20.04.21, 20:29

И я не понимаю, зачем, если есть замечательные ArrayList и ArrayDeque.

Ты на втором курсе data structure изучал ?
Array имеет фиксированный размер памяти, LL нет,
кто применять и где зависить от тебя и понимания задачи, все разговоры
о ом что LL устарел чистой воды тролинг, или не понимание.

[korvin]

Цитата sergioK @ 21.04.21, 05:08

А LinkedList нужен когда ды ты считываешь данные неопередельной длины, особенно большие обьемы,

Нет, не нужен.

Цитата sergioK @ 21.04.21, 05:08

Ты на втором курсе data structure изучал ?

А ты data structures только на уровне базового курса университета знаешь?

Цитата sergioK @ 21.04.21, 05:08

Array имеет фиксированный размер памяти, LL нет,

Ты вообще, в курсе, что такое ArrayList?

Цитата sergioK @ 21.04.21, 05:08

что применять и где зависить от тебя и понимания задачи, все разговоры

Не только от этого, но и от характеристик самой структуры данных.

Цитата sergioK @ 21.04.21, 05:08

о ом что LL устарел чистой воды тролинг, или не понимание.

Это у тебя полное непонимание того, как работает JVM, память и процессор.

[applegame]

Цитата korvin @ 20.04.21, 20:29

При чём тут кортежи? Если ты используешь кортежи вместо массивов/списков, то ты используешь их неправильно.

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

Цитата korvin @ 20.04.21, 20:29

Какие операции тут ленивые?

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

Цитата korvin @ 20.04.21, 20:29

Ты путаешь тёплое с мягким.
1) никто в ФП не парится с хеш-таблицами
2) чистые функциональные хеш-таблицы реализуются точно также, как и функциональные массивы — с использованием деревьев и частичным копированием — и имеют точно такую же сложность.

Не путаю. Просто ты в каждом ответе норовишь съехать куда-то в сторону.
1) Не парятся потому что выбора у них нет. А в языках с поддержкой мутабельности еще как парятся.
2) См. ответ на пункт 1.
Вывод: иммитация массива на деревьях в ФП - вынужденная мера, это лучшее, что там можно сделать. Это слабое место иммутабельного ФП. И памяти оно ест больше и к кэшу процессора недружелюбно и доступ неконстантный. И-за этого в узких местах приходится городить костыли на языках с поддержкой мутабельности.

Цитата korvin @ 20.04.21, 20:29

Т.е. ты
1) практически делаешь работу аллокатора
2) никак не решаешь отсутствие векторизации
3) усложняешь структуру данных / её использование, вместо того, чтобы попробовать другую структуру, не имеющую таких проблем
отличное решение, молодец.

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

Цитата korvin @ 20.04.21, 20:29

Но речи о single-linked-list vs double-linked-list там нет, так что нет, не игнорирую.

Ну а о чем там тогда речь? Почему "LinkedList is another matter entirely"? Раз ты процитировал этот кусок, то хотелось бы услышать твое понимание слов автора.

Цитата korvin @ 20.04.21, 20:29

Ладно Scheme, но с чего ты взял, что «linked lists ... in C» означает «односвязные списки»? В C нет двусвязных? Может, ему, например, нравятся интрузивные двусвязные списки в Си?

Ну в общем-то из-за Scheme я так и понял. Ну и как из фразы "They're as useful in C as they are in Scheme" можно вообще сделать вывод, что в C автор имел ввиду не те же списки, что и в Scheme? Альтернативный английский? Ну и если эти linked list так полезны в C, а LinkedList это "another matter entirely", то вероятно в Java должен существовать правильный linked list, аналогичный таковому в C и Scheme. Он существует?

Цитата korvin @ 20.04.21, 20:29

Ты теперь ещё и терминологию какую-то выдумываешь.

А ты типа не понял о чем речь? Или таки сделал вид, что не понял? Ок, разъясняю: "мутабельным языком" я назвал язык имеющий встроенную поддержку мутабельных переменных. Так понятнее? Ну и как обычно ты сворачиваешь с основной темы. Давай уже назад к "иммутабельным/ленивым" двусвязным спискам. По твоему мнению их можно сделать таковыми или нет? Если нет, то что именно мешает?

Цитата korvin @ 20.04.21, 20:29

В Java нельзя описывать иммутабельные объекты? Это запрещено на уровне JVM? Как же Scala и Clojure работают?
Может их не рекомендуют к использованию? Да нет, наоборот, рекомендуют. Вот и в стандартной библиотеке давно появилось StreamAPI для работы с коллекциями в функциональном стиле, а неизменяемые обёртки для стандартных коллекций в JDK существуют с незапамятных времён.

Ну это вообще из серии "сам придумал - сам опровергнул".

Сообщение отредактировано: applegame - 21.04.21, 09:00

[korvin]

Цитата applegame @ 21.04.21, 08:50

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

Состоятелен, потому что юз-кейсы у списка и кортежа принципиально разные.

Цитата applegame @ 21.04.21, 08:50

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

Без копирования? Ну-ну.

Цитата applegame @ 21.04.21, 08:50

Очевидно print.

Очевидно, 1) print здесь элемент списка, а не «операция» над элементом списка, 2) в примерах на Scheme и Java print не является ленивой функцией.

Цитата applegame @ 21.04.21, 08:50

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

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

Цитата applegame @ 21.04.21, 08:50

Просто ты в каждом ответе норовишь съехать куда-то в сторону.

Вообще-то съезжать в сторону начал ты с самого начала.

Цитата applegame @ 21.04.21, 08:50

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

Я думаю, что ты некомпетентен, но думаешь, будто компетентен. Вот и скинь ссылку на «правильную» с твоей точки зрения инфу.
А лучше сразу свой связный список с мемори пулом и примером юз-кейса для тестирования/замера.

Цитата applegame @ 21.04.21, 08:50

Ну а о чем там тогда речь?

Речь о том, что класс LinkedList оказался на практике почти бесполезен.

Цитата applegame @ 21.04.21, 08:50

Ну в общем-то из-за Scheme я так и понял.

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

Цитата applegame @ 21.04.21, 08:50

Ну и как из фразы "They're as useful in C as they are in Scheme" можно вообще сделать вывод, что в C автор имел ввиду не те же списки, что и в Scheme?

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

Цитата applegame @ 21.04.21, 08:50

Ну и если эти linked list так полезны в C, а LinkedList это "another matter entirely", то вероятно в Java должен существовать правильный linked list, аналогичный таковому в C и Scheme. Он существует?

В JDK — нет. В сторонних библиотеках коллекций — возможно.

Вот, например, в org.apache.commons есть двусвязный список с этим твои кэшированием нод

Цитата applegame @ 21.04.21, 08:50

А ты типа не понял о чем речь?

Я-то понял, только зачем ты терминологию выдумываешь?

Цитата applegame @ 21.04.21, 08:50

По твоему мнению их можно сделать таковыми или нет? Если нет, то что именно мешает?

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

Цитата applegame @ 21.04.21, 08:50

Ну это вообще из серии "сам придумал - сам опровергнул".

Кто ж разберёт твои фантазии.

[sergioK]

Цитата korvin @ 21.04.21, 07:20

Цитата sergioK @ 21.04.21, 05:08

Ты на втором курсе data structure изучал ?

А ты data structures только на уровне базового курса университета знаешь?

Нет, не только

Добавлено 21.04.21, 20:04

Цитата korvin @ 21.04.21, 07:20

Ты вообще, в курсе, что такое ArrayList?

Я таких ArrayList не один десяток написал , разных имплементаций ,
ArrayList умножает память на 3/2 и перегрузить это нельзя в отличии от вектора,
и это одна имлементация интерфэйса java.util.List другая это Linked List,
пользуешь когда не знаешь сколько элементов будет.

[applegame]

Цитата korvin @ 21.04.21, 11:21

Состоятелен, потому что юз-кейсы у списка и кортежа принципиально разные.

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

Цитата korvin @ 17.04.21, 07:45

В том, что любая операция добавления/изменения приводит к созданию полной копии списка.

Цитата korvin @ 21.04.21, 11:21

Без копирования? Ну-ну.

Память у тебя как у рыбки:

Цитата applegame @ 12.04.21, 07:21

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

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

Цитата korvin @ 21.04.21, 11:21

Очевидно, 1) print здесь элемент списка, а не «операция» над элементом списка, 2) в примерах на Scheme и Java print не является ленивой функцией.

Ну если уж доёбываться, то элемент списка не сам print а результат каррирования print. Можно переделать твой пример, чтобы была операция над элементами: https://ideone.com/hPXX7o
Суть не меняется, ленивый не список, а вычисления.

Цитата korvin @ 21.04.21, 11:21

2) в примерах на Scheme и Java print не является ленивой функцией.

Вот сам придумываешь какие-то странные термины, что такое "ленивая функция"? Чем она отличается от "неленивой"?

Цитата korvin @ 21.04.21, 11:21

Вообще-то съезжать в сторону начал ты с самого начала.

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

Цитата korvin @ 21.04.21, 11:21

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

Ты явно путаешь принципиальную возможность создать такой список и возможность создать его средствами самого иммутабельного ФП-языка. Повторю еще раз: двусвязный список при желании можно встроить в любой иммутабельный ФП язык. В Erlang это можно сделать например при помощи NIF: создаем сначала мутабельный список, заполняем ноды данными, после чего делаем иммутабельным. В общем-то аналогично кортежам, которые в том же эрланге являются, по сути, иммутабельными массивами.
Ленивость же, как я говорил, вообще ортогональна всему этому. В том же D, я могу сделать тебе ленивый рендж, хоть односвязный (ForwardRange), хоть двусвязный (BidirectionalRange), хоть вообще массив (RandomAccessRange). Хошь мутабельный, хошь иммутабельный.

Цитата korvin @ 21.04.21, 11:21

Речь о том, что класс LinkedList оказался на практике почти бесполезен.

Интересует почему. Какое принципиальное отличие от односвязных списков в Scheme или сферических в вакууме списков в C?

Цитата korvin @ 21.04.21, 11:21

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

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

Цитата korvin @ 21.04.21, 11:21

Вот, например, в org.apache.commons есть двусвязный список с этим твои кэшированием нод

Молодец, просвещайся дальше. Даю подсказку: ноды еще можно не по одной аллоцировать, а сразу непрерывными блоками по несколько штук, причем можно сразу и место для данных аллоцировать внутри ноды (интрузивные списки, о которых я писал ранее, а после и ты). Особо упоротые оптимизаторы, длину этих блоков еще и с размером строки кэша процессора норовят выровнять.

Цитата korvin @ 21.04.21, 11:21

Я-то понял, только зачем ты терминологию выдумываешь?

А в чем проблема? Не нравится мой термин, предложи свой. Тем более если ты понял, то зачем цепляться? Лишь бы что-нибудь возразить?

[applegame]

Цитата korvin @ 21.04.21, 11:21

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

Сделал на D. И синтаксический сахар есть.
1. Вместо head - front, вместо tail - popFront. Также есть back и popBack - аналоги для другого конца списка.
Список иммутабелен. Добавление элементов (append) создает копию списка, popFront и popBack не создают копию.
Для демонстрации иммутабельности, добавляю не сразу все элементы к списку, а за два раза. Обратите внимание, что все переменные в main константные, кастов в программе нет, так что они реально иммутабельные.
Элементы вычисляются лениво. Для подтверждения этого создал структуру Int, иммитирующую обычное целое, с перегруженным оператором сложения, который печатает в консоль текст подтверждающий, что сложение реально произошло.

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

Играться тут: https://glot.io/snippets/fxwh6ktfxg

Код:

Скрытый текст

import std.stdio;
 
struct Int {
    int value;
    Int opBinary(string op: "+")(Int other) const {
        writefln("%s + %s = %s", value, other.value, value + other.value);
        return Int(value + other.value);
    }
}
 
void main() {
    const l0 = DList!Int();
    const l1 = l0.append(
        Int(1) + Int(1),
    );
    const l2 = l1.append(
        Int(2) + Int(2),
        Int(3) + Int(3),
        Int(4) + Int(4)
    );
    writeln(l2.popFront().front);
}
 
struct DList(T) {
    struct Node {
        T delegate() payload;
        Node* prev, next;
    }
 
    private Node* m_first, m_last;
 
    bool empty() const { return m_first == null; }
    T front() const { assert(!empty); return m_first.payload(); }
    T back() const { assert(!empty); return m_last.payload(); }
    const(DList) popFront() const {
        assert(!empty);
        return m_first == m_last ? const DList() : const DList(m_first.next, m_last);
    }
    const(DList) popBack() const {
        assert(!empty);
        return m_first == m_last ? const DList() : const DList(m_first, m_last.prev);
    }
 
    const(DList) append(ARGS...)(lazy ARGS args) const {
        auto list = dup();
        static foreach(arg; args) {
            if(empty) {
                list.m_first = list.m_last = new Node(&arg);
            } else {
                list.m_last.next = new Node(&arg, list.m_last);
                list.m_last = list.m_last.next;
            }
        }
        return list;
    }
 
    private DList dup() const {
        auto list = DList();
        if(!empty) {
            auto prev = new Node(m_first.payload);
            list.m_first = prev;
            const(Node)* cur = m_first.next;
            while(cur != m_last.next) {
                auto node = new Node(cur.payload, prev);
                prev.next = node;
                prev = node;
                cur = cur.next;
            }
            list.m_last = prev;
        }
        return list;
    }
}

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

Сообщение отредактировано: applegame - 21.04.21, 21:47

[korvin]

Цитата sergioK @ 21.04.21, 19:57

Я таких ArrayList не один десяток написал , разных имплементаций ,

Зачем? Руки чесались? )

Цитата sergioK @ 21.04.21, 19:57

ArrayList умножает память на 3/2 и перегрузить это нельзя в отличии от вектора,

А LinkedList умножает память на 3.

Цитата sergioK @ 21.04.21, 19:57

и это одна имлементация интерфэйса java.util.List другая это Linked List,
пользуешь когда не знаешь сколько элементов будет.

Вот тебе бенчмарк на добавление «не знаешь сколько элементов»:

Скрытый текст

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.Blackhole;
import ru.sources.collections.Collections;
 
import java.util.Collection;
import java.util.concurrent.TimeUnit;
import java.util.function.IntFunction;
 
@BenchmarkMode(Mode.AverageTime)
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@Fork(
        value = 3,
        jvm = "/Library/Java/JavaVirtualMachines/adoptopenjdk-15.jdk/Contents/Home/bin/java",
        jvmArgsAppend = {
                "-server",
                "-disablesystemassertions",
                //"-XX:+UseSerialGC",
                //"-XX:+UseParallelGC",
                //"-XX:+UseZGC",
                "-XX:+UseShenandoahGC",
                "-Xms8g",
                "-Xmx8g"
        })
@State(Scope.Thread)
public class CollectionsBenchmark {
 
    private static final String LINKED_LIST = "LinkedList";
    private static final String ARRAY_LIST  = "ArrayList";
 
    //@Param({"10", "100"})
    //@Param({"100", "10000", "1000000"})
    @Param({"1000", "100000", "10000000"})
    private int itemsToAdd;
 
    @Param({LINKED_LIST, ARRAY_LIST})
    private String type;
 
    private IntFunction<Collection<?>> subject;
 
    @Setup
    public void setup() {
        switch (type) {
            case LINKED_LIST -> subject = Collections::linkedList;
            case ARRAY_LIST  -> subject = Collections::arrayList;
        }
    }
 
    @Benchmark
    public void addMany(Blackhole blackhole) {
        blackhole.consume(subject.apply(itemsToAdd));
    }
}

subjects

import java.util.ArrayList;
import java.util.Collection;
import java.util.LinkedList;
 
public final class Collections {
 
    public static Collection<?> linkedList(int items) {
        final var c = new LinkedList<>();
        for (int i = 0; i < items; i++) {
            c.add(i);
        }
        return c;
    }
 
    public static Collection<?> arrayList(int items) {
        final var c = new ArrayList<>();
        for (int i = 0; i < items; i++) {
            c.add(i);
        }
        return c;
    }
}

Вот результаты с разными GC (меньше — лучше):

Serial:

Benchmark                     (itemsToAdd)               (type)  Mode  Cnt       Score       Error  Units
 
CollectionsBenchmark.addMany          1000           LinkedList  avgt   15       5.210 ±     0.053  us/op
CollectionsBenchmark.addMany          1000            ArrayList  avgt   15       3.530 ±     0.028  us/op
 
CollectionsBenchmark.addMany        100000           LinkedList  avgt   15     487.786 ±     7.153  us/op
CollectionsBenchmark.addMany        100000            ArrayList  avgt   15     361.776 ±     3.407  us/op
 
CollectionsBenchmark.addMany      10000000           LinkedList  avgt   15  114308.717 ± 24496.008  us/op
CollectionsBenchmark.addMany      10000000            ArrayList  avgt   15   74059.694 ±  1124.293  us/op

Parallel:

Benchmark                     (itemsToAdd)              (type)  Mode  Cnt       Score       Error  Units
 
CollectionsBenchmark.addMany          1000           LinkedList  avgt   15       5.191 ±     0.038  us/op
CollectionsBenchmark.addMany          1000            ArrayList  avgt   15       3.524 ±     0.042  us/op
 
CollectionsBenchmark.addMany        100000           LinkedList  avgt   15     490.742 ±     7.725  us/op
CollectionsBenchmark.addMany        100000            ArrayList  avgt   15     364.297 ±     7.221  us/op
 
CollectionsBenchmark.addMany      10000000           LinkedList  avgt   15  145307.026 ± 35319.645  us/op
CollectionsBenchmark.addMany      10000000            ArrayList  avgt   15   71625.532 ±  3860.046  us/op

ZGC:

Benchmark                     (itemsToAdd)              (type)  Mode  Cnt       Score        Error  Units
 
CollectionsBenchmark.addMany          1000           LinkedList  avgt   15       5.714 ±     0.548  us/op
CollectionsBenchmark.addMany          1000            ArrayList  avgt   15       5.573 ±     0.298  us/op
 
CollectionsBenchmark.addMany        100000           LinkedList  avgt   15     553.497 ±    38.279  us/op
CollectionsBenchmark.addMany        100000            ArrayList  avgt   15     583.829 ±    33.537  us/op
 
CollectionsBenchmark.addMany      10000000           LinkedList  avgt   15  136561.101 ± 62714.469  us/op
CollectionsBenchmark.addMany      10000000            ArrayList  avgt   15  147221.840 ± 65372.420  us/op

Senandoah:

Benchmark                     (itemsToAdd)              (type)  Mode  Cnt      Score       Error  Units
 
CollectionsBenchmark.addMany          1000           LinkedList  avgt   15      4.516 ±     0.100  us/op
CollectionsBenchmark.addMany          1000            ArrayList  avgt   15      3.904 ±     0.123  us/op
 
CollectionsBenchmark.addMany        100000           LinkedList  avgt   15    453.895 ±     6.612  us/op
CollectionsBenchmark.addMany        100000            ArrayList  avgt   15    359.160 ±     7.098  us/op
 
CollectionsBenchmark.addMany      10000000           LinkedList  avgt   15  59037.699 ±  9332.316  us/op
CollectionsBenchmark.addMany      10000000            ArrayList  avgt   15  56993.428 ±  3011.366  us/op

Ну и где тут преимущества LinkedList на добавление неизвестного заранее количества элементов?
С первыми двумя GC LinkedList заметно сливает, со вторыми ± одинаково получается.

Добавлено 21.04.21, 22:52

Цитата applegame @ 21.04.21, 21:13

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

А по-твоему, списки они сферические в вакууме?

Цитата applegame @ 21.04.21, 21:13

Память у тебя как у рыбки:

Наоборот же, у тебя, не говоря уж, о твоих проблемах с чтением:

Цитата

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

на второй странице.

Цитата applegame @ 21.04.21, 21:13

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

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

Цитата applegame @ 21.04.21, 21:13

Вот сам придумываешь какие-то странные термины, что такое "ленивая функция"? Чем она отличается от "неленивой"?

Э-э… у тебя раздвоение личности? Я тебя спросил, какая операция там ленивая, ты ответил «print». print — это функция, т.е. ты же и назвал её ленивой

Цитата applegame @ 21.04.21, 21:13

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

Я тебе уже давно ответил, даже три пункта перечислил, с которыми ты же согласился, написав, что «Возможно, что LinkedList - просто корявая реализация двусвязного списка, тут спорить не буду ибо не знаю. Мои двусвязные списки (не на жабе, конечно) используют пулы, и добавляют по два указателя к каждой ноде.» (3-я страница). проверь память, я серьёзно.

Причём, вот ещё, например, кейс, вроде бы подходящий для двусвязного списка: LRU-кэш, но там нужно иметь ссылки на ноды, чтобы эффективно переставлять их в начало списка, но LinkedList не предоставляет возможности иметь ссылку на ноду, т.е. для этого кейса не подходит.

Цитата applegame @ 21.04.21, 21:13

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

Я нигде не писал про «принципиальную невозможность».

Цитата applegame @ 21.04.21, 21:13

Какое принципиальное отличие от односвязных списков в Scheme

двусвязность и закрытость для тебя не достаточно принципиальные отличия? Не знаю тогда. Может для тебя вообще все динамические структуры «на одно лицо»?

Цитата applegame @ 21.04.21, 21:13

сферических в вакууме списков в C?

Такая же сферическая в вакууме. Мне как-то не интересно гадать.

Цитата applegame @ 21.04.21, 21:13

Односвязный список и в Африке односвязный, какая разница это C или Scheme?

Во-первых, односвязный список можно реализовать по-разному:
– интрузивный или не интрузивный
– закрытый (объект-контейнер с внутренним приватным списком нод и предоставляющий доступ к элементов только описанными методами, инкапсулирующий манипуляции над нодами) или открытый (просто создаются сразу сами объекты нод)

Цитата applegame @ 21.04.21, 21:13

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

Он именно так и написал, но ты предпочёл поСПГСить.

Цитата applegame @ 21.04.21, 21:13

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

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

Цитата applegame @ 21.04.21, 21:13

А в чем проблема? Не нравится мой термин, предложи свой. Тем более если ты понял, то зачем цепляться? Лишь бы что-нибудь возразить?

Зачем я буду придумывать какой-то свой, если такие языки называют императивными?

Сообщение отредактировано: korvin - 22.04.21, 00:53

[korvin]

DEL (опечатался там)

Сообщение отредактировано: korvin - 22.04.21, 00:54

[korvin]

Цитата sergioK @ 21.04.21, 19:57

ArrayList умножает память на 3/2 и перегрузить это нельзя в отличии от вектора,

Только вектор
1) растёт на константное значение, что при большом количестве операций добавления требует больше реаллокаций и мене эффективно, чем ArrayList
2) synchronized, а значит ещё и имеет оверхед на lock/unlock на каждую операцию, даже если это не нужно, т.е. в большинстве юз-кейсов.

Цитата sergioK @ 21.04.21, 19:57

ArrayList умножает память на 3/2

Ах да, ты ещё забыл, что у объекта Node в LinkedList'е помимо 3-х ссылок (elem, prev, next) есть ещё и object header, который в Java довольно жирный.

Например, для 64bit JVM без сжатия указателей получим на каждый элемент:

objectHeader.classRef = 8
+ objectHeader.mark = 8
+ object.element = 8
+ object.previous = 8
+ object.next = 8
= 40 bytes per node
/ object.element = 8
= 5x

В пять раз больше памяти на ссылки по сравнению с ArrayList, Карл!
– LinkedList на 1млн элементов будет иметь оверхед 32 мегабайта.
– ArrayList на 1млн элементов, с capacity, увеличенной в полтора раза, будет иметь оверхед в 4 мегабайта.

Для 64bit JVM с включённым сжатием указателей получим на каждый элемент:

objectHeader.classRef = 4
+ objectHeader.mark = 8 // это поле всё равно будет 8 байт на 64bit JVM
+ object.element = 4
+ object.previous = 4
+ object.next = 4
= 24 bytes per node
/ object.element = 4
= 6x

— уже в шесть раз больше. Вот так сжали… )
Понятно, что в абсолютных значения оверхед будет меньше:
– LinkedList на 1млн элементов будет иметь оверхед 20 мегабайт.
– ArrayList на 1млн элементов, с capacity, увеличенной в полтора раза, будет иметь оверхед 2 мегабайта.

А ты собрался много данных в LinkedList загружать.
1млрд элементов:
LL — +20 гигабайт с сжатием, а фактически, думаю, хип перевалит за 32 гига (ведь у нас ещё есть сами элементы и данные в них), и JVM отключит сжатие указателей и мы получим 32 гига на одни только ноды LinkedList'а, не считая ещё самих элементов и данных в них.
AL — +2 гига с сжатием. Даже под реаллокации ещё достаточно места до 32-хгигабайтного порога отключения сжатия.
Удачи тебе с LinkedList'ом в этом деле.

Сообщение отредактировано: korvin - 22.04.21, 00:34

[korvin]

applegame, не понимаю, почему у тебя front и back возвращают payload, а не next и prev соответственно.

И как пройти по такому списку вперёд-назад и наоборот? Типа

void forward(const DList!Int l) {
    writeln("-- forward");
    if (l.empty()) {
        return;
    }
    
    writeln(l.front);
    forward(l.popFront());
}
 
void backward(const DList!Int l) {
    writeln("-- backward");
    if (l.empty()) {
        return;
    }
    
    writeln(l.back);
    backward(l.popBack());
}
 
void forwardBackward(const DList!Int l) {
    writeln("-- forwardBackward");
    if (l.empty()) {
        return;
    }
    
    writeln(l.front);
    
    const next = l.popFront();
    
    if (next.empty()) {
        backward(l);
    } else {
        forwardBackward(next);
    }
}
 
void backwardForward(const DList!Int l) {
    writeln("-- backwardForward");
    if (l.empty()) {
        return;
    }
    
    writeln(l.back);
    
    const prev = l.popBack();
    
    if (prev.empty()) {
        forward(l);
    } else {
        backwardForward(prev);
    }
}

вызов forwardBackward должен напечатать (условно)

1
2
3
4
3
2
1

через pop*-методы так не работает.

И вот ещё важный момент: в односвязном ленивом списке суть не в ленивости элементов, а в ленивости построения самого списка (т.е. хвоста), поэтому возможно задать бесконечный список и работать с ним, используя как генератор/inputstream.

Каноничный бесконечный ленивый список чисел фибоначчи на Хаскелле задаётся так:

fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

Напечатать первые 10 чисел:

print $ take 10 fibs

https://ideone.com/bB92Nu

На Scheme моя реализация работает также, без модификаций: https://ideone.com/ysmTzd

На Java чуть сложнее из-за более статических пространств имён, поэтому приходится использовать небольшой костыль Cell, но никаких модификаций самой реализации списка не требуется, и все дополнительные функции (zip, take) реализуются также, как в Haskell и Scheme и всё работает: https://ideone.com/K4Z9QW

Хотя, можно обойтись и без Cell, используя просто саму функцию: https://ideone.com/DDjz1i

Соответственно ленивым у тебя должен быть не столько payload, сколько next и prev.

Сообщение отредактировано: korvin - 22.04.21, 02:19

[sergioK]

Цитата korvin @ 21.04.21, 07:20

Это у тебя полное непонимание того, как работает JVM, память и процессор.

Linked List никуда не умер и нужен для вполне конкретный целей,
хватит тут теории разводить,с умным видом, JVM тут ыообще не причем, он и в STL есть,


Добавлено 22.04.21, 04:18

Цитата korvin @ 22.04.21, 00:31

Ах да, ты ещё забыл, что у объекта Node в LinkedList'е помимо 3-х ссылок (elem, prev, next) есть ещё и object header, который в Java довольно жирный.

Я ничего не забыл, лишних 24 байта, не надо меня тут учить data structure ,

Добавлено 22.04.21, 04:26

Цитата korvin @ 22.04.21, 00:31

1) растёт на константное значение, что при большом количестве операций добавления требует больше реаллокаций и мене эффективно, чем ArrayList
2) synchronized, а значит ещё и имеет оверхед на lock/unlock на каждую операцию, даже если это не нужно, т.е. в большинстве юз-кейсов.

1) Ты сам реализуешь так как тебе нужно, теоретик млин
2) Если не подходит для данной задачи не используй, то что
в ArrayList insureCapacity private - чистой воды косяк,

Сообщение отредактировано: sergioK - 22.04.21, 04:37

[kopilov]

Цитата sergioK @ 22.04.21, 04:10

Linked List никуда не умер и нужен для вполне конкретный целей,
Я ничего не забыл, лишних 24 байта, не надо меня тут учить data structure

Это прекрасно, а как с джунами в итоге поступили? И один ли ты кул гай д`Артаньян?

Сообщение отредактировано: kopilov - 22.04.21, 08:15

[korvin]

Цитата sergioK @ 22.04.21, 04:10

хватит тут теории разводить,с умным видом

Какие теории, болезный? Я тебе вон бенчмарк скинул с твоим «практическим» примером, загрузить большое, неизвестное число объектов, где по-твоему нужно LinkedList использовать, а оказалось — не нужно.

Цитата sergioK @ 22.04.21, 04:10

JVM тут ыообще не причем, он и в STL есть,

1) во-первых, JVM тут при том, что с неё начался разговор.
2) во-вторых: https://www.youtube.com/watch?v=YQs6IC-vgmo

Цитата sergioK @ 22.04.21, 04:10

Я ничего не забыл, лишних 24 байта, не надо меня тут учить data structure ,

Ты прав, тут — не надо. Тебе бы в университет вернуться, знания подтянуть. А потом на работу нормальную устроиться джуном, практического опыта набраться. А то поназагружают миллиарды объектов в LinkedList, а потом в OutOfMemory долбятся, псевдопрактики, блин.

Цитата sergioK @ 22.04.21, 04:10

1) Ты сам реализуешь так как тебе нужно

А на практике никак не нужно. Ни при каких обстоятельствах.

Цитата sergioK @ 22.04.21, 04:10

2) Если не подходит для данной задачи не используй

Спасибо, капитан. Только он ни для какой задачи не нужен.

Цитата sergioK @ 22.04.21, 04:10

в ArrayList insureCapacity private - чистой воды косяк,

Чё, серьёзно? https://docs.oracle.com/javase/8/docs/api/j...reCapacity-int-

Цитата

public void ensureCapacity(int minCapacity)

Сообщение отредактировано: korvin - 22.04.21, 08:29

[applegame]

Цитата korvin @ 21.04.21, 22:21

на второй странице.

Несколько дней споришь, а когда загнали в угол, ты внезапно нашел лазейку: оказывается ты имел ввиду, что нельзя "просто" создать. А "сложно" можно? А 100 строк это "просто" или "сложно"?
Ну ладно, главное, что согласился в конце-концов.

Цитата korvin @ 21.04.21, 22:21

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

ЧТД.

Цитата korvin @ 21.04.21, 22:21

Э-э… у тебя раздвоение личности? Я тебя спросил, какая операция там ленивая, ты ответил «print». print — это функция, т.е. ты же и назвал её ленивой

У тебя что-то с логикой. Никаких о каких ленивых функциях я не говорил. Функция не бывает ленивой, бывает ленивое выполнение функции. И в твоем примере на хаскеле, выполнение функции print как раз таки ленивое, о чем я и говорил. Согласен с претензией, что я неточно выразился говоря о ленивых операциях над элементами списка. Точнее было сказать: ленивое вычисление значений элементов списка, которое, в свою очередь, может быть, а может и не быть операцией над элементами другого списка.

Цитата korvin @ 21.04.21, 22:21

двусвязность и закрытость для тебя не достаточно принципиальные отличия?

Конечно недостаточно. Двусвязные списки по производительности не будут отличаться от односвязных на операциях добавления/удаления в начало списка и итерации, при прочих равных. Потому что двусвязный список, по сути, включает в себя односвязный. Разве что памяти требует больше. Впрочем, XOR-списки никто не отменял.
Порывшись немного в интернетах на тему почему же LinkedList в Java умудряется сливать ArrayList и даже ArrayDeque на операциях добавления миллионов элементов, я прихожу к выводу, что это связано с какой-то наивной реализацией этого списка и особенностями работы JVM. И есть все основания полагать, что односвязный список реализованный также наивно, будут работать точно также плохо.

Цитата korvin @ 21.04.21, 22:21

Во-первых, односвязный список можно реализовать по-разному:
– интрузивный или не интрузивный
– закрытый (объект-контейнер с внутренним приватным списком нод и предоставляющий доступ к элементов только описанными методами, инкапсулирующий манипуляции над нодами) или открытый (просто создаются сразу сами объекты нод)

Ну и какой же из вариантов имел в ввиду автор говоря о списках полезных в C? О чем ты вообще тут толкуешь? Автор ни словом ни обмолвился ни о деталях реализации, даже просто оптимизацию не упомянул. Может он вообще не разбирается в этом? Кстати, интересно, в Java (JVM) возможны интрузивные списки? Ну и что там "во-вторых"?

Цитата korvin @ 21.04.21, 22:21

Он именно так и написал, но ты предпочёл поСПГСить.

По мне так наоборот, чтобы прийти к выводу, что "он именно так и написал" приходится СПГСить.

Цитата korvin @ 21.04.21, 22:21

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

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

Цитата korvin @ 21.04.21, 22:21

Зачем я буду придумывать какой-то свой, если такие языки называют императивными?

Я говорил именно о поддержке мутабельности, а не о поддержке императивности. Мутабельность и императивность - ортогональные сущности. F# - императивный язык? А OCaml? А Erlang/Elixir? Тема для отдельного холивара.

[korvin]

Цитата applegame @ 22.04.21, 08:33

ЧТД.

Доказать, что можно реализовать любую бесполезную фигню? Ну, молодец, важное доказательство.

Цитата applegame @ 22.04.21, 08:33

Впрочем, XOR-списки никто не отменял.

Цитата

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

Ясно-понятно.

Цитата applegame @ 22.04.21, 08:33

что это связано с какой-то наивной реализацией

А у двусвязного списка реализация бывает наивной и не наивной? Интересно, какая реализация наивная, а какая — нет?

Цитата applegame @ 22.04.21, 08:33

Автор ни словом ни обмолвился ни о деталях реализации

Наконец-то до тебя дошло. Может, теперь ты прекратишь что-то додумывать?

Цитата applegame @ 22.04.21, 08:33

Кстати, интересно, в Java (JVM) возможны интрузивные списки?

Конечно. Пример нужен?

Цитата applegame @ 22.04.21, 08:33

По мне так наоборот, чтобы прийти к выводу, что "он именно так и написал" приходится СПГСить.

К вывод «он именно так и написал» не нужно приходить, это не вывод, а значение-по-умолчанию, как синие занавески. Бритва Оккама же.

Цитата applegame @ 22.04.21, 08:33

Все случаи (не считая программирования в Elixir) когда лично я задействовал связный список (односвязный или двусвязный, не важно) были связаны с необходимостью удалять ноды из середины списка или с участием ноды одновременно в нескольких структурах данных. То есть я "манипулировал нодами". В общем и целом трудно сказать, слишком много факторов. С одной стороны при переполнении массива, нужно реаллоцировать и копировать все элементы (или указатели на них) в новое место. С другой стороны, когда список "разогрелся", то максимальное количество элементов перестает расти и болтается внутри массива не требуя никаких реаллокаций и копирований.

Ну вот, а LL прямой доступ к ноде не даёт, только линейный поиск с начала, что в итоге намного дороже, чем реаллокация в AL: https://www.youtube.com/watch?v=Y4XkWSAm2XU

Цитата applegame @ 22.04.21, 08:33

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

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

Цитата applegame @ 22.04.21, 08:33

Мутабельность и императивность - ортогональные сущности

Э, нет. Вся суть императивного программирования в прямом и явном изменении (мутировании) состояния. Это оно и есть, то, что ты хочешь сказать.

Цитата applegame @ 22.04.21, 08:33

F# - императивный язык? А OCaml?

Это «мультипарадигмальные» языки, поддерживающие ФП, ООП, ИП. В общем-то как и многие современные/популярные ЯП.

[applegame]

Цитата korvin @ 22.04.21, 02:05

applegame, не понимаю, почему у тебя front и back возвращают payload, а не next и prev соответственно.

Потому что front - это head. Он возвращает значение первого элемента в списке. back - тоже самое с конца.

Цитата korvin @ 22.04.21, 02:05

через pop*-методы так не работает.

У меня была ошибка в коде, вот исправленная версия: https://glot.io/snippets/fxx0z9kiam

Скрытый текст

import std.stdio;
 
struct Int {
    int value;
    Int opBinary(string op: "+")(Int other) const {
        writefln("%s + %s = %s", value, other.value, value + other.value);
        return Int(value + other.value);
    }
}
 
void main() {
    const l0 = DList!Int();
    const l1 = l0.append(
        Int(1) + Int(1),
    );
    const l2 = l1.append(
        Int(2) + Int(2),
        Int(3) + Int(3),
        Int(4) + Int(4)
    );
    writeln(l2.popFront().front);
}
 
struct DList(T) {
    struct Node {
        T delegate() payload;
        Node* prev, next;
    }
 
    private Node* m_first, m_last;
 
    bool empty() const { return m_first == null; }
    T front() const { assert(!empty); return m_first.payload(); }
    T back() const { assert(!empty); return m_last.payload(); }
    const(DList) popFront() const {
        assert(!empty);
        return m_first == m_last ? const DList() : const DList(m_first.next, m_last);
    }
    const(DList) popBack() const {
        assert(!empty);
        return m_first == m_last ? const DList() : const DList(m_first, m_last.prev);
    }
 
    const(DList) append(ARGS...)(lazy ARGS args) const {
        auto list = dup();
        static foreach(arg; args) {
            if(list.empty) {
                list.m_first = list.m_last = new Node(&arg);
            } else {
                list.m_last.next = new Node(&arg, list.m_last);
                list.m_last = list.m_last.next;
            }
        }
        return list;
    }
 
    private DList dup() const {
        auto list = DList();
        if(!empty) {
            auto prev = new Node(m_first.payload);
            list.m_first = prev;
            const(Node)* cur = m_first.next;
            while(cur != null && cur != m_last) {
                auto node = new Node(cur.payload, prev);
                prev.next = node;
                prev = node;
                cur = cur.next;
            }
            list.m_last = prev;
        }
        return list;
    }
}

Цитата korvin @ 22.04.21, 02:05

И как пройти по такому списку вперёд-назад и наоборот?

Вот так? https://glot.io/snippets/fxx116i54y

Скрытый текст

import std.stdio;
 
void forward(const DList!int l) {
    if (l.empty()) return;
    writeln(l.front);
    forward(l.popFront());
}
 
void backward(const DList!int l) {
    if (l.empty()) return;
    writeln(l.back);
    backward(l.popBack());
}
 
void forwardBackward(const DList!int l) {
    forward(l);
    backward(l.popBack());
}
 
void backwardForward(const DList!int l) {
    backward(l);
    forward(l.popFront());
}
 
void main() {
    const list = DList!int().append(1, 2, 3, 4);
    writeln("forwardBackward");
    forwardBackward(list);
    writeln("backwardForward");
    backwardForward(list);
}
 
struct DList(T) {
    struct Node {
        T delegate() payload;
        Node* prev, next;
    }
 
    private Node* m_first, m_last;
 
    bool empty() const { return m_first == null; }
    T front() const { assert(!empty); return m_first.payload(); }
    T back() const { assert(!empty); return m_last.payload(); }
    const(DList) popFront() const {
        assert(!empty);
        return m_first == m_last ? const DList() : const DList(m_first.next, m_last);
    }
    const(DList) popBack() const {
        assert(!empty);
        return m_first == m_last ? const DList() : const DList(m_first, m_last.prev);
    }
 
    const(DList) append(ARGS...)(lazy ARGS args) const {
        auto list = dup();
        static foreach(arg; args) {
            if(list.empty) {
                list.m_first = list.m_last = new Node(&arg);
            } else {
                list.m_last.next = new Node(&arg, list.m_last);
                list.m_last = list.m_last.next;
            }
        }
        return list;
    }
 
    private DList dup() const {
        auto list = DList();
        if(!empty) {
            auto prev = new Node(m_first.payload);
            list.m_first = prev;
            const(Node)* cur = m_first.next;
            while(cur != null && cur != m_last) {
                auto node = new Node(cur.payload, prev);
                prev.next = node;
                prev = node;
                cur = cur.next;
            }
            list.m_last = prev;
        }
        return list;
    }
}

[applegame]

Цитата korvin @ 22.04.21, 09:05

Доказать, что можно реализовать любую бесполезную фигню? Ну, молодец, важное доказательство.

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

Цитата korvin @ 22.04.21, 09:05

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

Да, хорошая альтернатива. Я даже полагал, что ArrayDeque как раз и реализован как unrolled list, поэтому и уделывает LinkedList аки тузик грелку даже на массовом добавлении элементов:

Цитата applegame @ 11.04.21, 10:19

Но есть серьезное подозрение, что внутри этого ArrayDeque используется, сюрприз-сюрприз, двусвязный список массивов Может даже тот самый LinkedList.

Но реальность оказалась гораздо хуже

Цитата korvin @ 22.04.21, 09:05

А у двусвязного списка реализация бывает наивной и не наивной? Интересно, какая реализация наивная, а какая — нет?

Прямая, в лоб, без каких-либо оптимизаций, вроде кеширования нод или списка массивов (unrolled list). То есть тупо аллоцируем ноды по одной с двумя указателями.

Цитата korvin @ 22.04.21, 09:05

Наконец-то до тебя дошло. Может, теперь ты прекратишь что-то додумывать?

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

Цитата korvin @ 22.04.21, 09:05

Конечно. Пример нужен?

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

Цитата korvin @ 22.04.21, 09:05

Э, нет. Вся суть императивного программирования в прямом и явном изменении (мутировании) состояния. Это оно и есть, то, что ты хочешь сказать.

Не согласен. Совсем. Тот же Elixir тотально иммутабелен, но содержит изрядную долю императивщины. Я считаю, что фундаментальный признак императивности - последовательное выполнение списка действий. Википедия похоже считает также Императивное программирование. ИП часто сопровождается мутабельностью, но это не является обязательным признаком.

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

[korvin]

Цитата applegame @ 22.04.21, 10:27

Я даже полагал, что ArrayDeque как раз и реализован как unrolled list, поэтому и уделывает LinkedList аки тузик грелку даже на массовом добавлении элементов:

Ну, он не уделывает прям как тузик, чуть хуже ArrayList'а вроде получается, я уже удалил результаты с ArrayDeque, могу восстановить, но не думаю, что это настолько интересно.

Цитата applegame @ 22.04.21, 10:27

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

Это именно так, просто можно ж написать абстрактный класс и наследоваться от него, поля объекта родительского класса же встраиваются в объект дочернего, а не создаётся полноценный дочерний объект, это была бы композиция. )

Цитата applegame @ 22.04.21, 10:27

Википедия похоже считает также Императивное программирование.

Цитата

…
– данные, полученные при выполнении инструкции, могут записываться в память.
…
– использование именованных переменных;
– использование оператора присваивания;
…

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

Цитата

In computer science, imperative programming is a programming paradigm that uses statements that change a program's state.

Цитата applegame @ 22.04.21, 10:27

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

Чушь, но это уже точно отдельный холивар.

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

Скрытый текст

public final class OpenLinkedList<T> {
 
    public static <T> OpenLinkedList<T> node(T data) {
        return new OpenLinkedList<>(data, null, null);
    }
 
    private T data;
    private OpenLinkedList<T> prev;
    private OpenLinkedList<T> next;
 
    private OpenLinkedList(T data, OpenLinkedList<T> prev, OpenLinkedList<T> next) {
        this.data = data;
        this.prev = prev;
        this.next = next;
    }
 
    public T data() {
        return data;
    }
 
    public OpenLinkedList<T> prev() {
        return prev;
    }
 
    public OpenLinkedList<T> next() {
        return next;
    }
 
    public void setPrev(OpenLinkedList<T> list) {
        this.prev = list;
    }
 
    public void setNext(OpenLinkedList<T> list) {
        this.next = list;
    }
}

Тестируемый код:

    public static Object openLinkedList(int items) {
        if (items <= 0) {
            return null;
        }
        var list = OpenLinkedList.node(0);
        for (int i = 1; i < items; i++) {
            final var node = OpenLinkedList.node(i);
            list.setNext(node);
            node.setPrev(list);
            list = node;
        }
        return list;
    }

Результат:

Benchmark                     (itemsToAdd)          (type)  Mode  Cnt      Score       Error  Units
CollectionsBenchmark.addMany          1000      LinkedList  avgt   15      4.823 ±     0.935  us/op
CollectionsBenchmark.addMany          1000       ArrayList  avgt   15      3.642 ±     0.095  us/op
CollectionsBenchmark.addMany          1000  OpenLinkedList  avgt   15      4.012 ±     0.072  us/op
 
CollectionsBenchmark.addMany        100000      LinkedList  avgt   15    638.813 ±   409.703  us/op
CollectionsBenchmark.addMany        100000       ArrayList  avgt   15    350.063 ±    10.558  us/op
CollectionsBenchmark.addMany        100000  OpenLinkedList  avgt   15    599.069 ±   331.634  us/op
 
CollectionsBenchmark.addMany      10000000      LinkedList  avgt   15  61113.971 ± 16824.651  us/op
CollectionsBenchmark.addMany      10000000       ArrayList  avgt   15  56662.442 ±  2182.296  us/op
CollectionsBenchmark.addMany      10000000  OpenLinkedList  avgt   15  65001.029 ± 15023.551  us/op

Как видно, связный список можно использовать только если ты
[MODE=Петросян]
разрабатываешь серьёзный банковский софт для Société Générale
[/MODE]

[applegame]

Цитата korvin @ 22.04.21, 02:05

И вот ещё важный момент: в односвязном ленивом списке суть не в ленивости элементов, а в ленивости построения самого списка (т.е. хвоста), поэтому возможно задать бесконечный список и работать с ним, используя как генератор/inputstream.

Ну я бы не назвал это односвязными списками. Строго говоря, это вообще не списки. ЕМНИП, каноническое определение списка в computer science включает в себя его конечность. А то, о чем ты говоришь это stream или infinite sequence. Коллекция элементов отсутствует как таковая. Связный список - это просто одна из реализаций списков, а не внешний интерфейс.

Цитата korvin @ 22.04.21, 02:05

Каноничный бесконечный ленивый список чисел фибоначчи на Хаскелле задаётся так:

fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

Напечатать первые 10 чисел:

print $ take 10 fibs

Это просто реккурентная функция обернутая в интерфейс списка, а не связный список. В D такое пишется, на мой взгляд, понятнее:
https://glot.io/snippets/fxx3k64atg

auto fibs = recurrence!((a, n) => a[n-1] + a[n-2])(1, 1);
writeln(fibs.take(10));

Цитата korvin @ 22.04.21, 02:05

Соответственно ленивым у тебя должен быть не столько payload, сколько next и prev.

Ну что значит "должен"? Ленивые вычисления - это всего лишь вычисления отложенные на потом. Никакой магии. Я пошел по самому очевидному для меня пути.

[korvin]

Вот с интрузивным списком совсем другой разговор:

Benchmark                     (itemsToAdd)               (type)  Mode  Cnt      Score       Error  Units
CollectionsBenchmark.addMany          1000           LinkedList  avgt   15     14.542 ±    17.000  us/op
CollectionsBenchmark.addMany          1000            ArrayList  avgt   15      3.680 ±     0.089  us/op
CollectionsBenchmark.addMany          1000       OpenLinkedList  avgt   15      4.068 ±     0.175  us/op
CollectionsBenchmark.addMany          1000  IntrusiveLinkedList  avgt   15      2.561 ±     0.027  us/op
 
CollectionsBenchmark.addMany        100000           LinkedList  avgt   15    471.286 ±    13.920  us/op
CollectionsBenchmark.addMany        100000            ArrayList  avgt   15    362.478 ±     9.120  us/op
CollectionsBenchmark.addMany        100000       OpenLinkedList  avgt   15    443.950 ±    11.291  us/op
CollectionsBenchmark.addMany        100000  IntrusiveLinkedList  avgt   15    255.955 ±     3.964  us/op
 
CollectionsBenchmark.addMany      10000000           LinkedList  avgt   15  61587.330 ± 22176.828  us/op
CollectionsBenchmark.addMany      10000000            ArrayList  avgt   15  56342.958 ±  2432.139  us/op
CollectionsBenchmark.addMany      10000000       OpenLinkedList  avgt   15  73251.613 ± 21086.066  us/op
CollectionsBenchmark.addMany      10000000  IntrusiveLinkedList  avgt   15  28434.662 ±  2616.126  us/op

Добавлено 22.04.21, 11:16

Цитата applegame @ 22.04.21, 11:10

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

Почему? Обычные односвязные списки, строящиеся по мере итерации по ним.

Цитата applegame @ 22.04.21, 11:10

ЕМНИП, каноническое определение списка в computer science включает в себя его конечность.

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

Цитата applegame @ 22.04.21, 11:10

Коллекция элементов отсутствует как таковая.

Она присутствует, просто строится по мере необходимости, а не сразу.

Цитата applegame @ 22.04.21, 11:10

Это просто реккурентная функция обернутая в интерфейс списка, а не связный список.

Обычный ленивый связный список ))

Цитата applegame @ 22.04.21, 11:10

Ну что значит "должен"?

То и значит. Буквально.

[applegame]

Цитата korvin @ 22.04.21, 10:51

…
– данные, полученные при выполнении инструкции, могут записываться в память.
…
– использование именованных переменных;
– использование оператора присваивания;
…

Дык все это есть и в ФП языках. Например Elixir. Можно конечно долго разглагольствовать, что дескать вот это вот на самом деле не присваивание, но выглядит оно именно как присваивание:

a = foo(a)
b = foo(b)
{a, b} = {b, a}

Иммутабельная императивщина.

Цитата korvin @ 22.04.21, 10:51

In computer science, imperative programming is a programming paradigm that uses statements that change a program's state.

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

import std.stdio;
void main() {
  foreach(const i; 0..10) writeln(i);
}

Сообщение отредактировано: applegame - 22.04.21, 11:30

[korvin]

Я предлагаю немного усложнить бенчмарк: сделать не только формирование коллекции, но и какое-то её использование.
Например: создавать упорядоченный набор значений (для простоты — числа по возрастанию), т.е. при добавлении каждого нового элемента, добавлять его не в конец, а в такую позицию, чтобы итоговый список/массив оставался упорядоченным. А в конце построить «сырой» массив int[] из элементов (UPD, нефиг зря память тратить =) ) посчитать сумму всех элементов, чтобы проитерироваться по всем элементам.

Для AL: используем бинарный поиск, потом add(index, item), который будет всегда требовать сдвига элементов и в некоторых случаях — реаллокации
Для LL: сначала проверяем первый и последний элементы, для быстрой вставки в начало и конец, иначе используем ListIterator для нахождения нужно места и вставки «во внутрь»
Для OpenLL: в целом, повторяет LL, но можно, например, отдельно хранить ноду середины, чтобы уменьшить количество проходов.
Для IntrusiveLL: повторяем алгоритм OpenLL.

Бэнчи запускаем для трёх кейсов:
– все генерируемые элементы изначально правильно упорядочены, т.е. вставка всегда идёт в начало — тут, по логике AL должен быть хуже всех.
– все генерируемые элементы изначально обратно упорядочены, т.е. вставка всегда идёт в конец.
– все элементы генерируются псевдослучайно, будем задавать одинаковый seed для ГСЧ.

Как вам такой кейс? Всё ли справедливо? Будет ли интересно?

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

Добавлено 22.04.21, 11:38

Цитата applegame @ 22.04.21, 11:28

Иммутабельная императивщина.

Не знаком с Elixir, где тут иммутабельность?

Цитата applegame @ 22.04.21, 11:28

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

Может. В чём тут проблема/противоречие?

Цитата applegame @ 22.04.21, 11:28

Хошь покажу имеративную программу без единой мутабельной переменной? Держи

И что это должно показать? Что состояние std.stdio не меняется?

Сообщение отредактировано: korvin - 22.04.21, 11:49

[applegame]

Цитата korvin @ 22.04.21, 11:10

Обычный ленивый связный список ))

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

Добавлено 22.04.21, 11:54

Цитата korvin @ 22.04.21, 11:34

Не знаком с Elixir, где тут иммутабельность?

Везде. Просто в эликсире можно, так сказать, "ребиндить" имена переменных. То есть в одной строке переменная указывает на одни данные, в другой ее можно перебиндить и она будет указывать уже на другие данные. А сами данные строго иммутабельны. В хаскеле и окамле похожее через let можно сделать, ЕМПИН.

Цитата korvin @ 22.04.21, 11:34

Может. В чём тут проблема/противоречие?

Не противоречие, а бессмыслица. Изменение состояние программы - это не признак императивного программирования. Это признак программирования вообще, в том числе и ФП. Даже генератор чисел фибоначчи написанный на Хаскеле (самый ФП язык из всех ФП языков) меняет свое состояние по мере вывода чисел на экран. Банальная функция с хвостовой рекурсией тоже меняет свое состояние (привет ген_серверам эрланга).

Цитата korvin @ 22.04.21, 11:34

И что это должно показать? Что состояние std.stdio не меняется?

Это показывает, что мутабельность/иммутабельность - не обязательный признак императивности. Если изменение stdio считать за признак императивности, то и хаскельный генератор фибоначчи императивен.

Добавлено 22.04.21, 12:12

Цитата korvin @ 22.04.21, 11:10

Обычный ленивый связный список ))

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

Сообщение отредактировано: applegame - 22.04.21, 12:12

[D_KEY]

Цитата applegame @ 22.04.21, 11:41

Просто в эликсире можно, так сказать, "ребиндить" имена переменных. То есть в одной строке переменная указывает на одни данные, в другой ее можно перебиндить и она будет указывать уже на другие данные. А сами данные строго иммутабельны.

Т.е. это "другие" a и b? Тогда не понимаю, в чем проблема.

Добавлено 22.04.21, 12:38

Цитата applegame @ 22.04.21, 11:41

Изменение состояние программы - это не признак императивного программирования. Это признак программирования вообще, в том числе и ФП.

А мне вот кажется, ты ошибаешься

Добавлено 22.04.21, 12:40
applegame, ещё ты почему-то смешиваешь языки и парадигмы. То, что в каком-то языке с поддержкой ФП, есть поддержка ИП, не делает фичи ИП фичами ФП.

[korvin]

applegame, так, пажди, ёмана, это просто создание нового скоупа, тут нет ничего императивного, то что оно записывается линейно, а не вложено — это просто синтаксический сахар, чтобы не было больших лестниц, а по сути это:

let a = 1 in
  let b = 2 in
    let (b, a) = (a, b) in
      ....

что в свою очередь тривиально преобразуется в лямбда-выражение.

Никакой императивщины тут нет.

Вот, например, в Go похожее выражение:

var a, b int
a = 1
b = 2
a, b = b, a

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

[applegame]

Цитата D_KEY @ 22.04.21, 12:36

applegame, ещё ты почему-то смешиваешь языки и парадигмы. То, что в каком-то языке с поддержкой ФП, есть поддержка ИП, не делает фичи ИП фичами ФП.

Да нет, тебе показалось. Вот главные вопросы:
Что является главным отличием ИП от ФП?
Является ли иммутабельность/мутабельность этим главным отличием?
Ну и как бонус:
Может ли ИП существовать без мутабельности?

Добавлено 22.04.21, 13:34

Цитата korvin @ 22.04.21, 13:01

applegame, так, пажди, ёмана, это просто создание нового скоупа, тут нет ничего императивного, то что оно записывается линейно, а не вложено — это просто синтаксический сахар, чтобы не было больших лестниц, а по сути это:

Ага, это был прикол. Но таки в моем примере запросто может появиться императивщина. В Elixir/Erlang функции запросто могут быть грязными с сайд эффектами, а в моем коде идет вызов функции foo(), причем два раза и в определенной ПОСЛЕДОВАТЕЛЬНОСТИ.
Я в целом считаю, что даже в хацкеле как только ты задействовал do-нотацию, считай начал писать императивно.

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

[korvin]

Цитата applegame @ 22.04.21, 13:31

Но таки в моем примере запросто может появиться императивщина. В Elixir/Erlang функции запросто могут быть грязными с сайд эффектами, а в моем коде идет вызов функции foo(), причем два раза и в определенной ПОСЛЕДОВАТЕЛЬНОСТИ.

Вложенный вызов чистых функций в «чистом» функциональном языке

x = foo (bar (gee (qux 42)))

— тоже некоторая «последовательность», и что? Функциональный код не перестаёт таковым быть. А наличие побочных эффектов — да, делает код императивным, а побочные эффекты — это изменение состояния. Снова приходим к тому, что это ключевое отличие.

Цитата applegame @ 22.04.21, 13:31

Я в целом считаю, что даже в хацкеле как только ты задействовал do-нотацию, считай начал писать императивно.

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

[applegame]

Цитата korvin @ 22.04.21, 14:51

— тоже некоторая «последовательность», и что?

Это не последовательность, это композиция функций. ФП абстрагируется от порядка выполнения максимально, пока не придется столкнуться с реальным императивным миром и тут-то волшебные замки рушатся. Вот тебе
другой пример:
foo(bar(), baz())
Что выполнится раньше: bar() или baz()?

Цитата korvin @ 22.04.21, 14:51

Снова приходим к тому, что это ключевое отличие.

Это ФП или ИП? И есть ли тут мутабельное состояние?

bool contains(T)(const T[] arr, const T e) pure {
  foreach(const x; arr) if(x == e) return true;
  return false;
}

Цитата korvin @ 22.04.21, 14:51

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

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

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

[D_KEY]

Цитата applegame @ 22.04.21, 13:31

Что является главным отличием ИП от ФП?

Если кратко, то
ИП - это подход с последовательным выполнением инструкций, которые модифицируют данные(состояние), теоретическая модель - машина Тьюринга.
ФП - это подход с вычислением функций, теоретическая модель - лямбда исчисления Черча.

Добавлено 22.04.21, 15:44

Цитата applegame @ 22.04.21, 13:31

Является ли иммутабельность/мутабельность этим главным отличием?

Одним из. Главным или нет - не понимаю вопроса.

Цитата

Может ли ИП существовать без мутабельности?

Думаю, что нет

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

Цитата applegame @ 22.04.21, 15:39

Вот тебе
другой пример:
foo(bar(), baz())
Что выполнится раньше: bar() или baz()?

В ФП вопрос не имеет смысла, в ИП зависит от языка или даже компилятора.

Добавлено 22.04.21, 16:09

Цитата applegame @ 22.04.21, 15:39

Это ФП или ИП?

Это функция. Судя по всему, чистая. Значит могла бы быть и в ФП. Правда если всматриваться в тело функции, то можно увидеть инструкции, т.е. формально, наверное, не чистое ФП. Такой подход свойственнен гибридным языкам

[applegame]

Цитата D_KEY @ 22.04.21, 15:42

ИП - это подход с последовательным выполнением инструкций, которые модифицируют данные(состояние), теоретическая модель - машина Тьюринга.

А я вот останавливаюсь на последовательном выполнении инструкций. Мутабельное состояние мне представляется необязательным.

Цитата D_KEY @ 22.04.21, 15:42

В ФП вопрос не имеет смысла

Именно.

Цитата D_KEY @ 22.04.21, 15:42

Это функция. Судя по всему, чистая. Значит могла бы быть и в ФП. Правда если всматриваться в тело функции, то можно увидеть инструкции, т.е. формально, наверное, не чистое ФП. Такой подход свойственнен гибридным языкам

Ну а мутабельное состояние-то есть?

Сообщение отредактировано: applegame - 22.04.21, 17:31

[Qraizer]

Цитата sergioK @ 15.04.21, 19:47

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

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

Цитата sergioK @ 15.04.21, 19:47

Вот и придумали шутку про дроздов, а в каждой шутке доля правды, as smaller as better

Это потому что никто в суды не подавал. А если и подавал, то всё обычно решалось в досудебном порядке, чтоб никто ничего никому внешне не попортил, ни в репутации, ни на физиономии. Нынче другие времена, и суды вполне себе, бывает, выигрываются. И – да, мы о бизнесе. В области высококритичного ПО понятия лицензий просто нет. Там никто не будет просить прочитать и согласиться. Там всё куда проще: спасибо за деньги, вот вам копия, циркулярный №XXX-YYY, документация во вложении; и там чёрным по-человеческому все-все-все планы, методики, правила, мануалы итд итп — всё, что касается эксплуатации такого ПО и в рамках чего поставщик отвечает за качество.
Когда-то, не спорю, программы были маленькими и простыми. Потому что компьютеры обладали малыми ресурсами, а у программистов были в использовании простые инструменты. Увы, приходилось многое перекладывать на плечи юзеров. Нынче ситуация далеко не та, время дроздов в контексте той поговорки ушло где-то уже на рубеже веков, а с тех пор ещё 20 лет прошло.

Цитата sergioK @ 15.04.21, 19:47

В вашей это в какой ? ты же програмист или нет ?

Авионика. По должности да, более подходящих в ЕТКС нет. По сфере деятельности нет. Самое короткое описание – "технический специалист". И список длиною в пол-листа в должностной инструкции. Хотя программированием занимаюсь, но не высококритичного кода как такового, а различного инструментария для его верификации и сертификации. Включая проектирование, создание и саппорт испытательных стендов с исходным аппаратным и исполнительным окружением flight-кода under inspection, тестового окружения на базе ПК и различных инструментов статистического анализа, генерации итоговой документации, управления артефактами, автоматизации процессов итп.

Добавлено 22.04.21, 18:46

Цитата sergioK @ 15.04.21, 19:47

И какая связь ? после второй прививки нельзя работать?

Можно. Но не хочется, хочется кофе и спать.

Цитата sergioK @ 15.04.21, 19:47

Таганрог это столица IT ? Или это была ирония ?

В какой-то мере да. Видосик не смотрел? Посмотри, меня тоже улыбало.

[korvin]

Цитата applegame @ 22.04.21, 15:39

Вот тебе
другой пример:
foo(bar(), baz())
Что выполнится раньше: bar() или baz()?

Странный вопрос. Для чистого ФП разницы нет (разве что одна из функций bar, baz значительно дольше вычисляется, чем другая). Для императивного зависит от порядка вычисления аргументов функции и стратегии вычисления (call-by-value vs call-by-name).

Цитата applegame @ 22.04.21, 15:39

Это ФП или ИП? И есть ли тут мутабельное состояние?

bool contains(T)(const T[] arr, const T e) pure {
  foreach(const x; arr) if(x == e) return true;
  return false;
}

Это может быть как ФП, так и ИП, внезапно.

Вот тебе другой пример:

    public static void main(String[] args) {
        System.out.println(foo(1));
    }
 
    private static int foo(int i) {
        return bar(gee(++i));
    }
 
    private static int bar(int x) {
        return ++x+1;
    }
 
    private static int gee(int x) {
        return ++x*2;
    }

— это композиция функций? ФП, значит?

Цитата applegame @ 22.04.21, 15:39

Ох уж эта высокомерная надменность.

Никакой надменности, простая констатация фактов.

Цитата applegame @ 22.04.21, 15:39

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

Это общепринятое определение.

----------------------------------------------------------------

Сделал немного бенчей, за отсутствие багов не ручаюсь, возможно как-нибудь позже проведу тестирование.

Процесс такой: составление упорядоченного набора чисел, потом фильтрация по (x < max/2), потом суммирование.
Вариантов распределения входных значений 5:
– по возрастанию
– по убыванию
– по возрастанию до середины, потом по убыванию (например: 1 2 3 4 5 4 3 2 1)
– по убыванию до середины, потом по возрастанию (например: 5 4 3 2 1 2 3 4 5)
– псевдослучайное

ожидаемо ArrayList слил во всех кейсах, кроме первого (добавление в конец):

Benchmark                      (itemMapperType)  (itemsToAdd)           (type)  Mode  Cnt    Score   Error  Units
 
CollectionsBenchmark2.addMany         ascending        100000           LinkedList  avgt   10    1998.600 ±  825.551  us/op
CollectionsBenchmark2.addMany         ascending        100000            ArrayList  avgt   10    1158.352 ±  630.132  us/op
 
CollectionsBenchmark2.addMany        descending        100000           LinkedList  avgt   10    1984.810 ±  819.924  us/op
CollectionsBenchmark2.addMany        descending        100000            ArrayList  avgt   10  380804.497 ± 4571.318  us/op
 
CollectionsBenchmark2.addMany         asc->desc        100000           LinkedList  avgt   10    2121.230 ±  736.523  us/op
CollectionsBenchmark2.addMany         asc->desc        100000            ArrayList  avgt   10  191833.039 ± 3449.825  us/op
 
CollectionsBenchmark2.addMany         desc->asc        100000           LinkedList  avgt   10    1876.418 ±  727.067  us/op
CollectionsBenchmark2.addMany         desc->asc        100000            ArrayList  avgt   10  168997.600 ± 4365.277  us/op
 
CollectionsBenchmark2.addMany            random        100000           LinkedList  avgt   10    3463.063 ±  908.374  us/op
CollectionsBenchmark2.addMany            random        100000            ArrayList  avgt   10  195038.198 ± 3059.551  us/op

Однако, если поменять алгоритм наполнения ArrayList на добавление всегда в конец с сортировкой в финале, то сливает уже LinkedList, кроме последнего метода:

Benchmark                      (itemMapperType)  (itemsToAdd)           (type)  Mode  Cnt    Score   Error  Units
 
CollectionsBenchmark2.addMany         ascending        100000           LinkedList  avgt   10    1998.600 ±  825.551  us/op
CollectionsBenchmark2.addMany         ascending        100000       ArrayList.Sort  avgt   10    1167.463 ±  521.571  us/op
 
CollectionsBenchmark2.addMany        descending        100000           LinkedList  avgt   10    1984.810 ±  819.924  us/op
CollectionsBenchmark2.addMany        descending        100000       ArrayList.Sort  avgt   10    1348.757 ±  585.568  us/op
 
CollectionsBenchmark2.addMany         asc->desc        100000           LinkedList  avgt   10    2121.230 ±  736.523  us/op
CollectionsBenchmark2.addMany         asc->desc        100000       ArrayList.Sort  avgt   10    1791.563 ±  622.418  us/op
 
CollectionsBenchmark2.addMany         desc->asc        100000           LinkedList  avgt   10    1876.418 ±  727.067  us/op
CollectionsBenchmark2.addMany         desc->asc        100000       ArrayList.Sort  avgt   10    1348.264 ±  629.691  us/op
 
CollectionsBenchmark2.addMany            random        100000           LinkedList  avgt   10    3463.063 ±  908.374  us/op
CollectionsBenchmark2.addMany            random        100000       ArrayList.Sort  avgt   10   19608.787 ±  316.377  us/op

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

И как бонус, сравнение LL с OpenLL, IntrusiveLL и TreeMap (SortedMap):

Benchmark                      (itemMapperType)  (itemsToAdd)           (type)  Mode  Cnt    Score   Error  Units
 
CollectionsBenchmark2.addMany         ascending        100000           LinkedList  avgt   10    1998.600 ±  825.551  us/op
CollectionsBenchmark2.addMany         ascending        100000       OpenLinkedList  avgt   10    1590.634 ±  771.149  us/op
CollectionsBenchmark2.addMany         ascending        100000              TreeMap  avgt   10   16178.317 ±  352.460  us/op
CollectionsBenchmark2.addMany         ascending        100000  IntrusiveLinkedList  avgt   10     958.116 ±  459.509  us/op
 
CollectionsBenchmark2.addMany        descending        100000           LinkedList  avgt   10    1984.810 ±  819.924  us/op
CollectionsBenchmark2.addMany        descending        100000       OpenLinkedList  avgt   10    1560.737 ±  783.328  us/op
CollectionsBenchmark2.addMany        descending        100000              TreeMap  avgt   10   15963.631 ±  658.773  us/op
CollectionsBenchmark2.addMany        descending        100000  IntrusiveLinkedList  avgt   10     940.864 ±  433.400  us/op
 
CollectionsBenchmark2.addMany         asc->desc        100000           LinkedList  avgt   10    2121.230 ±  736.523  us/op
CollectionsBenchmark2.addMany         asc->desc        100000       OpenLinkedList  avgt   10    1584.023 ±  841.150  us/op
CollectionsBenchmark2.addMany         asc->desc        100000              TreeMap  avgt   10   11919.388 ±  287.896  us/op
CollectionsBenchmark2.addMany         asc->desc        100000  IntrusiveLinkedList  avgt   10     947.756 ±  473.614  us/op
 
CollectionsBenchmark2.addMany         desc->asc        100000           LinkedList  avgt   10    1876.418 ±  727.067  us/op
CollectionsBenchmark2.addMany         desc->asc        100000       OpenLinkedList  avgt   10    1503.495 ±  891.668  us/op
CollectionsBenchmark2.addMany         desc->asc        100000              TreeMap  avgt   10    8444.099 ±  744.990  us/op
CollectionsBenchmark2.addMany         desc->asc        100000  IntrusiveLinkedList  avgt   10     917.276 ±  511.321  us/op
 
CollectionsBenchmark2.addMany            random        100000           LinkedList  avgt   10    3463.063 ±  908.374  us/op
CollectionsBenchmark2.addMany            random        100000       OpenLinkedList  avgt   10    1700.960 ±  795.577  us/op
CollectionsBenchmark2.addMany            random        100000              TreeMap  avgt   10   33226.797 ± 1511.600  us/op
CollectionsBenchmark2.addMany            random        100000  IntrusiveLinkedList  avgt   10    1301.572 ±  462.545  us/op

Видно, что
1) LL сливает двум «кустарным» спискам.
2) TreeMap сливает всем, что может выглядеть немного неожиданно, ведь для задачи «собрать упорядоченную коллекцию» она выглядит весьма подходящей структурой.

segioK, я, конечно, не специалист по бенчмаркам и всё такое, но если ты всё ещё считаешь, что java.util.LinkedList для чего-то будет лучшим выбором, предлагай кейс, а иначе прекрати нести чушь.

[D_KEY]

Цитата applegame @ 22.04.21, 17:30

А я вот останавливаюсь на последовательном выполнении инструкций.

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

Цитата

Ну а мутабельное состояние-то есть?

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

[korvin]

Цитата D_KEY @ 22.04.21, 21:30

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

Присоединяюсь к вопросу.

applegame, чем это:

bool contains(T)(const T[] arr, const T e) pure {
  foreach(const x; arr) if(x == e) return true;
  return false;
}

отличается от

contains []     e = False
contains (x:xs) e = x == e || contains xs e

?

Сообщение отредактировано: korvin - 22.04.21, 22:04

[sergioK]

Цитата korvin @ 22.04.21, 08:26

Какие теории, болезный? Я тебе вон бенчмарк скинул с твоим «практическим» примером, загрузить большое, неизвестное число объектов, где по-твоему нужно LinkedList использовать, а оказалось — не нужно.

Да плевал я на твой бенчмарк, и таких же выкскпертов из интернета, теоретики млин,
все это 20лет назад известно, insert и delete будет 0(1) у массива не будет,
queue когда в минуту приходит 15-20 тыс обьетов, массивом не сделаешь.

[korvin]

Цитата sergioK @ 22.04.21, 22:30

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

Бьорн Страуструп — «выксперт из интернета, теоретик»? Хаха

Цитата sergioK @ 22.04.21, 22:30

queue когда в минуту приходит 15-20 тыс обьетов, массивом не сделаешь.

Чё, серьёзно? )) Да ты хуже джуна. Нормальный джун хотя бы понимает, что он джун.

[sergioK]

Цитата korvin @ 22.04.21, 08:26

Чё, серьёзно?

Посмотри что она делает, и сравни с вектором

Добавлено 22.04.21, 22:58

Цитата Qraizer @ 22.04.21, 18:44

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

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

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

Что за ролик то про столицу IT ?

Сообщение отредактировано: sergioK - 22.04.21, 23:03

[korvin]

sergioK, кто тебя вообще на работу взял? Джуны, видимо

Benchmark       (itemsToAdd)      (type)  Mode  Cnt      Score      Error  Units
Queues.addMany       1000000  LinkedList  avgt   15  10204.559 ± 1692.646  us/op
Queues.addMany       1000000  ArrayQueue  avgt   15   5026.365 ±  609.288  us/op

LinkedList в два раза менее производительный, чем ArrayDeque в качестве очереди.
Ты не «практик», ты — практикант. Максимум.

Добавлено 22.04.21, 23:03

Цитата sergioK @ 22.04.21, 22:48

и сравни с вектором

Нахер с этим говном сравнивать? Его никакой адекватный человек использовать не станет.

[sergioK]

Цитата korvin @ 22.04.21, 23:02

LinkedList в два раза менее производительный, чем ArrayDeque в качестве очереди.
Ты не «практик», ты — практикант. Максимум.

Ты не хами для начала, Это если не надо память реалацировать, и машина мощная ,
и частота входа/выхода данные большая,

Добавлено 23.04.21, 06:26

Цитата korvin @ 21.04.21, 22:21

А LinkedList умножает память на 3.

на размер обьекта + 24байта
изучай

Сообщение отредактировано: sergioK - 23.04.21, 06:27

[applegame]

Цитата korvin @ 22.04.21, 21:08

Это может быть как ФП, так и ИП, внезапно.

Внутри функции махровое ИП: цикл + ранний return. И никакого мутабельного состояния. Вывод: ИП без мутабельности возможно и полезно.

Цитата korvin @ 22.04.21, 21:08

— это композиция функций? ФП, значит?

Если забить на грязность main, то да: вполне себе ФП.

Цитата korvin @ 22.04.21, 21:08

Это общепринятое определение.

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

Цитата D_KEY @ 22.04.21, 21:30

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

Такой же как и в ФП: получение результата.

Цитата D_KEY @ 22.04.21, 21:30

Но это просто функция.

И что? Программа на C/С++/D это тоже просто функция. Она даже может быть чистой, просто возвращая int в качестве результата.

Цитата D_KEY @ 22.04.21, 21:30

Программу-то полноценную если ты начнешь писать без мутабельности, то не скатишься ли ты к функциональному стилю, по сути?

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

Цитата korvin @ 22.04.21, 22:03

applegame, чем это:

bool contains(T)(const T[] arr, const T e) pure {
  foreach(const x; arr) if(x == e) return true;
  return false;
}

отличается от

contains []     e = False
contains (x:xs) e = x == e || contains xs e

?

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

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

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

[applegame]

Цитата korvin @ 22.04.21, 22:39

Бьорн Страуструп — «выксперт из интернета, теоретик»? Хаха

При всем уважении, Страуструп придумал такое говно как С++. А в комитете выступает как тормоз прогресса, блокируя современные тенденции ЯП. Так что я бы на твоем месте перестал аппелировать к авторитетам, и к Страуструпу в частности. По крайней мере в области программирования, где утверждения можно относительно легко проверить и доказать.
Это, конечно, никак не отменяет того, что Сирожа несет ересь и отрицает очевидное.

Сообщение отредактировано: applegame - 23.04.21, 08:01

[D_KEY]

Цитата applegame @ 23.04.21, 07:49

Такой же как и в ФП: получение результата.

Так смысл-то какой в таком определении ИП?

Цитата

Программа на C/С++/D это тоже просто функция. Она даже может быть чистой, просто возвращая int в качестве результата.

И что? Ты опять пытаешь языки и парадигмы?

Цитата

Я обычно пишу в гибридном стиле и избегаю ненужной мутабельности

Ну это ты молодец. Но это ничего не говорит о верности твоей демаркации.

Цитата

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

Вообще строго говоря это бесполезно. Если твои инструкции не меняют память и не имеют побочных эффектов, то каким образом происходят вычисления и передаются результаты?


Добавлено 23.04.21, 08:43

Цитата applegame @ 23.04.21, 07:49

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

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

[applegame]

Цитата D_KEY @ 23.04.21, 08:39

Так смысл-то какой в таком определении ИП?

Это не определение ИП, это ответ на твой бесмыссленный вопрос о смысле.

Цитата D_KEY @ 23.04.21, 08:39

И что? Ты опять пытаешь языки и парадигмы?

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

Цитата D_KEY @ 23.04.21, 08:39

Ну это ты молодец. Но это ничего не говорит о верности твоей демаркации.

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

Цитата D_KEY @ 23.04.21, 08:39

Вообще строго говоря это бесполезно. Если твои инструкции не меняют память и не имеют побочных эффектов, то каким образом происходят вычисления и передаются результаты?

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

Цитата D_KEY @ 23.04.21, 08:39

Проблема в том, что это не имеет значения для данного кода.

Это имеет значение для парадигмы. И после этого ты меня обвиняешь в путании. Может ты считаешь что мой пример на D и корвиновский на Haskell написаны в одной и той же парадигме (ФП или ИП)?

Цитата D_KEY @ 23.04.21, 08:39

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

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

Цитата D_KEY @ 23.04.21, 08:39

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

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

Сообщение отредактировано: applegame - 23.04.21, 09:19

[Qraizer]

Цитата applegame @ 23.04.21, 07:57

При всем уважении, Страуструп придумал такое говно как С++.

И на этом говне работает всё ныне используемое. Не исключая Эликсиров, ДжаваМашин, ВебКитов, Андроидов и даже, о ужас, инди и триплА игр.

Добавлено 23.04.21, 13:26

Цитата applegame @ 23.04.21, 07:57

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

Кстати, а какие? Мне известны лишь обратные примеры.

[kopilov]

Цитата Qraizer @ 23.04.21, 13:25

И на этом говне работает всё ныне используемое.

Просто оно перешло стадию компоста и приближается к стадии чернозёма

[applegame]

Цитата Qraizer @ 23.04.21, 13:25

Кстати, а какие? Мне известны лишь обратные примеры.

Возможно ошибаюсь, но вроде именно он зарубил нормальный static if.

[D_KEY]

Цитата applegame @ 23.04.21, 09:12

Цитата D_KEY @ 23.04.21, 08:39

Так смысл-то какой в таком определении ИП?

Это не определение ИП, это ответ на твой бесмыссленный вопрос о смысле.

Так я к тому, что не ответ

Цитата

а приступишь непосредственно к аргументации?

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

Цитата

ФП тоже получается, по-твоему, бесполезно?

В ФП используется модель вычисления функций, в ИП - выполнение инструкций, читающих/модифицирующих память. Если инструкции этого не делают, то они бесполезны.

Цитата

Цитата D_KEY @ 23.04.21, 08:39

Проблема в том, что это не имеет значения для данного кода.

Это имеет значение для парадигмы

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

Цитата

Может ты считаешь что мой пример на D и корвиновский на Haskell написаны в одной и той же парадигме (ФП или ИП)?

Мне кажется, что их можно так интерпретировать.

Цитата

Что мой пример не императивен?

Смотри, это зависит от определения императивности. Ты же пытаешься наоборот , из примера вывести определение. Или я тебя не понимаю.

Цитата

ты пытаешься смешать парадигмы, программы и исполнителей этих программ

Не думаю, что это так.

Цитата

Я же как раз таки пытаюсь абстрагироваться от всего, кроме непосредственно парадигмы.

По-моему ты просто дал своё определение ИП. А я не могу понять для чего

Добавлено 23.04.21, 16:57

Цитата applegame @ 23.04.21, 09:12

Цитата D_KEY @ 23.04.21, 08:39

Проблема в том, что это не имеет значения для данного кода.

Это имеет значение для парадигмы.

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

Сообщение отредактировано: D_KEY - 24.04.21, 14:34

[korvin]

Цитата sergioK @ 23.04.21, 06:13

Ты не хами для начала

Где ты хамство увидел? Может, вот тут:

Цитата sergioK @ 22.04.21, 04:10

хватит тут теории разводить,с умным видом

?
или тут:

Цитата sergioK @ 22.04.21, 04:10

1) Ты сам реализуешь так как тебе нужно, теоретик млин

?

Цитата sergioK @ 23.04.21, 06:13

Это если не надо память реалацировать

В бэнчмарке ArrayDeque инициализируется дефолтным capacity и память реалоцируется.

Цитата sergioK @ 23.04.21, 06:13

и машина мощная ,

Мощная --- это какая?

Цитата sergioK @ 23.04.21, 06:13

на размер обьекта + 24байта
изучай

Что там изучать? Так ты миллиард объектов уже загрузил в LinkedList?

Цитата applegame @ 23.04.21, 07:57

Так что я бы на твоем месте перестал аппелировать к авторитетам, и к Страуструпу в частности.

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

Цитата applegame @ 23.04.21, 07:49

Если забить на грязность main, то да: вполне себе ФП.

А если б у бабушки...

Цитата applegame @ 23.04.21, 07:49

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

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

Цитата applegame @ 23.04.21, 07:49

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

Есть и она точно такая же: очередной элемент будет проверен после предыдущего.

Цитата applegame @ 23.04.21, 07:49

Порядок действий никак не прописан в этом примере и не имеет никакого значения.

Прописан, через ||, и имеет значение. Ровно такое же, причём.

Цитата applegame @ 23.04.21, 07:49

В ФП порядок действий как таковой отсутствует.

Присутствует: нельзя вычислить значение функции, не вычислив её аргумента.

Добавлено 23.04.21, 23:18

Цитата applegame @ 23.04.21, 07:57

Так что я бы на твоем месте перестал аппелировать к авторитетам, и к Страуструпу в частности.

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

Про sergioK известно лишь то, что он часто несёт чушь, не умеет читать документацию, не может самостоятельно разобраться с REST, Hibernate и IDEA, высказывает утверждения уровня студента начальных курсов университета, но при этом мнит себя крутым специалистом.

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

Сообщение отредактировано: korvin - 23.04.21, 23:20

[korvin]

Цитата sergioK @ 23.04.21, 06:13

изучай

Ты лучше вот это поизучай:

Benchmark                      (itemMapperType)  (itemsToAdd)               (type)  Mode  Cnt      Score     Error  Units
 
CollectionsBenchmark2.addMany         ascending        100000           LinkedList  avgt   30   2220.032 ± 406.027  us/op
CollectionsBenchmark2.addMany         ascending        100000       ArrayList.Sort  avgt   30   1376.964 ± 263.260  us/op
CollectionsBenchmark2.addMany         ascending        100000  IntrusiveLinkedList  avgt   30    903.436 ± 189.932  us/op
CollectionsBenchmark2.addMany         ascending        100000         IntArrayList  avgt   30    410.626 ± 101.004  us/op
 
CollectionsBenchmark2.addMany        descending        100000           LinkedList  avgt   30   1969.813 ± 341.063  us/op
CollectionsBenchmark2.addMany        descending        100000       ArrayList.Sort  avgt   30   1323.195 ± 235.250  us/op
CollectionsBenchmark2.addMany        descending        100000  IntrusiveLinkedList  avgt   30    858.479 ± 178.213  us/op
CollectionsBenchmark2.addMany        descending        100000         IntArrayList  avgt   30    557.475 ± 110.512  us/op
 
CollectionsBenchmark2.addMany         asc->desc        100000           LinkedList  avgt   30   2206.215 ± 343.007  us/op
CollectionsBenchmark2.addMany         asc->desc        100000       ArrayList.Sort  avgt   30   1747.033 ± 267.812  us/op
CollectionsBenchmark2.addMany         asc->desc        100000  IntrusiveLinkedList  avgt   30    850.826 ± 189.609  us/op
CollectionsBenchmark2.addMany         asc->desc        100000         IntArrayList  avgt   30    776.621 ± 159.228  us/op
 
CollectionsBenchmark2.addMany         desc->asc        100000           LinkedList  avgt   30   1929.114 ± 346.647  us/op
CollectionsBenchmark2.addMany         desc->asc        100000       ArrayList.Sort  avgt   30   1311.586 ± 286.175  us/op
CollectionsBenchmark2.addMany         desc->asc        100000  IntrusiveLinkedList  avgt   30    712.091 ± 151.001  us/op
CollectionsBenchmark2.addMany         desc->asc        100000         IntArrayList  avgt   30    590.441 ± 125.438  us/op

IntArrayList — com.carrotsearch.hppc.IntArrayList — в четыре раза лучше LinkedList'а.

Сообщение отредактировано: korvin - 24.04.21, 00:32

[korvin]

Цитата sergioK @ 22.04.21, 04:10

хватит тут теории разводить,с умным видом, JVM тут ыообще не причем, он и в STL есть,

И вот это поизучай:

❯❯❯ g++ -O2 -std=c++17 -o lists main.cpp
 
❯❯❯ time ./lists 100000000 stdlist
Result: 3749999975000000
./lists 100000000 stdlist  14.97s user 0.91s system 99% cpu 15.892 total
 
❯❯❯ time ./lists 100000000 stdvector
Result: 3749999975000000
./lists 100000000 stdvector  0.61s user 0.42s system 99% cpu 1.040 total

src

#include <iostream>
#include <list>
#include <string>
#include <vector>
 
void usage(std::string, std::string);
int64_t std_list(int64_t);
int64_t std_vector(int64_t);
 
int main(int argc, char** argv)
{
    if (argc != 3)
    {
        usage(std::string(argv[0]), "invalid arguments");
        return 1;
    }
 
    const int64_t n = std::stoi(std::string(argv[1]));
    if (n < 1)
    {
        usage(std::string(argv[0]), "invalid nitems");
        return 2;
    }
 
    std::string type(argv[2]);
 
    int64_t result;
    if (type == "stdlist")
    {
        result = std_list(n);
    }
    else if (type == "stdvector")
    {
        result = std_vector(n);
    }
    else
    {
        usage(std::string(argv[0]), "unsupported type");
        return 3;
    }
 
    std::cout << "Result: " << result << std::endl;
}
 
void usage(std::string app, std::string err)
{
    std::cerr << err << std::endl;
    std::cerr << "Usage: " << app << " <nitems> <type>" << std::endl;
    std::cerr << "nitems: positive integer" << std::endl;
    std::cerr << "type:" << std::endl;
    std::cerr << "\tstdlist" << std::endl;
    std::cerr << "\tstdvector" << std::endl;
}
 
int64_t std_list(int64_t n)
{
    std::list<int64_t> xs;
 
    for (auto i = 0; i < n; ++i)
    {
        xs.push_back(i);
    }
 
    xs.remove_if([n](int x) {
        return x < n/2;
    });
 
    int64_t sum = 0;
    for (auto x : xs)
    {
        sum += x;
    }
 
    return sum;
}
 
int64_t std_vector(int64_t n)
{
    std::vector<int64_t> xs;
 
    for (auto i = 0; i < n; ++i)
    {
        xs.push_back(i);
    }
 
    auto filter = std::remove_if(xs.begin(), xs.end(), [n](int x) {
        return x < n/2;
    });
 
    xs.erase(filter, xs.end());
 
    int64_t sum = 0;
    for (auto x : xs)
    {
        sum += x;
    }
 
    return sum;
}

Так что там с загрузкой неизвестного большого количества данных в linked list?

[sergioK]

Цитата korvin @ 24.04.21, 01:41

Цитата sergioK @ 22.04.21, 04:10

хватит тут теории разводить,с умным видом, JVM тут ыообще не причем, он и в STL есть,

И вот это поизучай:

❯❯❯ g++ -O2 -std=c++17 -o lists main.cpp
 
❯❯❯ time ./lists 100000000 stdlist
Result: 3749999975000000
./lists 100000000 stdlist  14.97s user 0.91s system 99% cpu 15.892 total
 
❯❯❯ time ./lists 100000000 stdvector
Result: 3749999975000000
./lists 100000000 stdvector  0.61s user 0.42s system 99% cpu 1.040 total

src

#include <iostream>
#include <list>
#include <string>
#include <vector>
 
void usage(std::string, std::string);
int64_t std_list(int64_t);
int64_t std_vector(int64_t);
 
int main(int argc, char** argv)
{
    if (argc != 3)
    {
        usage(std::string(argv[0]), "invalid arguments");
        return 1;
    }
 
    const int64_t n = std::stoi(std::string(argv[1]));
    if (n < 1)
    {
        usage(std::string(argv[0]), "invalid nitems");
        return 2;
    }
 
    std::string type(argv[2]);
 
    int64_t result;
    if (type == "stdlist")
    {
        result = std_list(n);
    }
    else if (type == "stdvector")
    {
        result = std_vector(n);
    }
    else
    {
        usage(std::string(argv[0]), "unsupported type");
        return 3;
    }
 
    std::cout << "Result: " << result << std::endl;
}
 
void usage(std::string app, std::string err)
{
    std::cerr << err << std::endl;
    std::cerr << "Usage: " << app << " <nitems> <type>" << std::endl;
    std::cerr << "nitems: positive integer" << std::endl;
    std::cerr << "type:" << std::endl;
    std::cerr << "\tstdlist" << std::endl;
    std::cerr << "\tstdvector" << std::endl;
}
 
int64_t std_list(int64_t n)
{
    std::list<int64_t> xs;
 
    for (auto i = 0; i < n; ++i)
    {
        xs.push_back(i);
    }
 
    xs.remove_if([n](int x) {
        return x < n/2;
    });
 
    int64_t sum = 0;
    for (auto x : xs)
    {
        sum += x;
    }
 
    return sum;
}
 
int64_t std_vector(int64_t n)
{
    std::vector<int64_t> xs;
 
    for (auto i = 0; i < n; ++i)
    {
        xs.push_back(i);
    }
 
    auto filter = std::remove_if(xs.begin(), xs.end(), [n](int x) {
        return x < n/2;
    });
 
    xs.erase(filter, xs.end());
 
    int64_t sum = 0;
    for (auto x : xs)
    {
        sum += x;
    }
 
    return sum;
}

Так что там с загрузкой неизвестного большого количества данных в linked list?

Ты применяешь std_list не по месту, https://www.geeksforgeeks.org/advantages-an...of-linked-list/
больше я бесплатно обьяснять не буду ,

Сообщение отредактировано: sergioK - 24.04.21, 03:20

[korvin]

Цитата sergioK @ 24.04.21, 03:18

Ты применяешь std_list не по месту

Цитата sergioK @ 21.04.21, 05:08

А LinkedList нужен когда ды ты считываешь данные неопередельной длины, особенно большие обьемы,

а свои джуновские статейки лучше забудь.

[applegame]

Цитата D_KEY @ 23.04.21, 16:47

Так я к тому, что не ответ

Ну какой был вопрос такой и ответ. Я не знаю чего ты ожидал.

Цитата D_KEY @ 23.04.21, 16:47

Аргументации чего? Ты выкинул из конвенционально принятого определения ИП половину, а аргументы какие-то должен приводить я?

Скажем так. Спор сводится фактически к одному моему утверждению: Можно ли писать императивно не используя мутабельных переменных?.
Причем не синтетические примеры, а реальный полезный код.
Можно, конечно скатываться в терминологическую демагогию, как это делаешь ты: ну типа раз в определении ИП написано "мутабельный", значит ответ очевиден: низзя. А на остальное насрать. В таком случае можешь просто не участвовать в данном споре, потому что мне интересна оправданность необходимости мутабельности в ИП. Действительно ли иммутабельность кардинально меняет парадигму и код, внезапно, превращается в функциональный?
Рассуждения о пользе этого спора вообще смехотворны, мы тут не поиском истины занимаемся, а делимся мыслями и точками зрения. Ведь вне зависимости от того согласитесь ли вы со мной или нет, ничего не поменяется вообще
Беседа, по-сути, философская. Хотя некоторые аспекты диалога с korvin, уже ближе к реальности.

Цитата D_KEY @ 23.04.21, 16:47

Смотри, это зависит от определения императивности. Ты же пытаешься наоборот , из примера вывести определение. Или я тебя не понимаю.

Я рассуждаю так. Вот код, в нем есть последовательность инструкций, но нет мутабельности. Получается, что код не подходит под "конвенционально принятое" определение ФП (не должно быть последовательности инструкций). И не подходит под "конвенционально принятое" определение ИП (должна быть мутабельность).
Подумав я решил, что иммутабельность в ФП - это не какая-то самоцель, а следствие из самой сущности ФП. Нет необходимости где-то держать промежуточные результаты, потому что их попросту не существует, а что тогда мутировать? Получается, что иммутабельность не должна входить в определение ФП вообще, она автоматически следует из отсутствия промежуточных результатов.
Далее, рассматривая ИП, я пришел к выводу, что промежуточные результаты совсем не обязательно должны быть мутабельными. Что мешает на очередном шаге создавать новую иммутабельную переменную, вместо мутации старой? Ничего не мешает, более того, я постоянно так делаю, и при этом код не превращается в функциональный, так как последовательность иструкций никуда не девается. Получается, что обязательность мутабельности как бы "искусственно" прицеплена к определению, без каких либо логических причин. А как же эта мутабельность вообще попала в определение ИП? Ведь вряд ли кто-то действительно беспричинно ее туда запихал. Но это можно объяснить просто историей императивного программирования.
Отсюда делаю. вывод: "конвенционально принятое" определение ИП устарело. Ключевое - это последовательность инструкций. А, если подняться еще выше по уровню абстракции, то ИП тесно связано с течением времени. Время - это не просто очередная координата пространства, а фундаментальная особая составляющая ИП. В отличие от ФП.

Цитата korvin @ 23.04.21, 22:47

А если б у бабушки...

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

Цитата korvin @ 23.04.21, 22:47

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

Ты ошибаешься, возможно путаешь иммутабельность и возможность объявлять константы. const в том же Си появилась, внезапно, в C89, благодаря тому самому Страуструпу, который добавил его сначала в свой Си с классами. Я помню времена, когда строковые литералы в сяшке имели тип char*. В школьном бейсике вообще не было никаких константных переменных. В php нормальной иммутабельности не было ни в 4-ой, ни в 5-ой версии, сейчсас не знаю. В JS const появился в ES6. Интересно, что даже сейчас const ни в C, ни в C++, ни в JS не является полноценной поддержкой иммутабельности, так как const не гарантирует иммутабельность (в отличие от immutable в D). Короче, о иммутабельности в прикладном программировании серъезно начали задумываться сравнительно недавно. ФП, конечно, возникло давно, но оно едва-едва начало выползать из академических кругов.

Цитата korvin @ 23.04.21, 22:47

Есть и она точно такая же: очередной элемент будет проверен после предыдущего.

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

Цитата korvin @ 23.04.21, 22:47

Присутствует: нельзя вычислить значение функции, не вычислив её аргумента.

Нет не присутствует. Сравни императивную версию:

a = foo(x)
bar(a)

с функциональной

bar(foo(x))

На первый взгляд кажется, что разницы нет, но на самом деле есть. В императивном варианте функция foo будет выполнена до начала выполнения функции bar. В функциональной же версии foo может быть выполнена уже после начала выполнения bar (например в середине или даже паралелльно), да и вообще пофиг когда она выполнится. Мысли абстрактней, в ФП композиция функций - это просто новая функция, а не последовательность вызовов функций.
В реальности, конечно, последовательность будет, потому что исполнитель любой ФП-программы императивен и любая задача все равно так или иначе будет разбитна на шаги компилятором/интерпретатором. Этот эффект используется в Haskell, там, где нужна императивность, например в некоторых монадах. Но это не относится к самой парадигме ФП, это несовершенство реализации.

Сообщение отредактировано: applegame - 24.04.21, 18:13

[D_KEY]

Цитата applegame @ 24.04.21, 18:01

Отсюда делаю. вывод: "конвенционально принятое" определение ИП устарело.

Я бы сделал другой вывод. Применение термина ИП к практике современного программирования потеряло актуальность. Ну и подходов-то не два Да и в чистом виде мало кто применяет только какой-то один.

[applegame]

Цитата korvin @ 24.04.21, 09:17

а свои джуновские статейки лучше забудь.

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

[korvin]

Цитата applegame @ 24.04.21, 18:01

Ты ошибаешься, возможно путаешь иммутабельность и возможность объявлять константы. const в том же Си появилась, внезапно, в C89, благодаря тому самому Страуструпу, который добавил его сначала в свой Си с классами. Я помню времена, когда строковые литералы в сяшке имели тип char*. В школьном бейсике вообще не было никаких константных переменных.

Нет, не ошибаюсь. Но раз ты не понял, о чём я, то подскажу: opaque struct + функции чтения.

Цитата applegame @ 24.04.21, 18:01

Вообще-то нет.

Вообще-то да.

Цитата applegame @ 24.04.21, 18:01

Этож одна из фишек этого вашего ФП, типа смотрите, компилятор может все нафиг распараллелить.

Параллельность к этому примеру вообще не в тему.

Цитата applegame @ 24.04.21, 18:01

В ФП можно раздербанить список на элементы и запустить кучу потоков, которые будут параллельно выполнять сравнение. При этом твой код никак не изменится.

В моём примере нет списка.

Цитата applegame @ 24.04.21, 18:01

a = foo(x)
bar(a)

bar(foo(x))

На первый взгляд кажется, что разницы нет, но на самом деле есть. В императивном варианте функция foo будет выполнена до начала выполнения функции bar. В функциональной же версии foo может быть выполнена уже после начала выполнения bar (например в середине или даже паралелльно), да и вообще пофиг когда она выполнится. Мысли абстрактней, в ФП композиция функций - это просто новая функция, а не последовательность вызовов функций.

И вот ты снова путаешь синтаксис и семантику.
Чисто функциональный код на Хаскелле:

do
  a <- foo x
  bar a

do-нотация является ни чем иным, как синтаксическим сахаром для монадной функции bind (оператор '>>=' и '>>' ):

foo x >>= \a -> bar a

который в свою очередь является просто композицией функций, определённой в используемой монаде:

(\a -> bar a) (unwrap (foo x))

При этом

bar(foo(x))

foo вычислится гарантировано до вызова bar при аппликативном порядке вычислений (а это все неленивые ФП языки, F#, Ocaml, Clojure и т.д.)

а

a = foo(x)
bar(a)

может вычислиться в другом порядке при нормальном порядке вычислений или просто отложенных вычислениях, например, в Си/Паскале foo может вернуть какой-то объект Promise.

Цитата applegame @ 25.04.21, 08:23

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

Значит, sergioK и вправду джун, раз не понимает даже статей, на которые сам ссылается. )

Сообщение отредактировано: korvin - 25.04.21, 09:31

[applegame]

Цитата korvin @ 25.04.21, 09:31

Нет, не ошибаюсь. Но раз ты не понял, о чём я, то подскажу: opaque struct + функции чтения.

Это ты называешь поддержкой иммутабельности в языке? Я вообще никогда не встречал, чтобы кто-то использовал opaque типы ради иммутабельности. Это же трешовый костыль вроде immutable.js. Ты бы еще просто запрет программисту менять объект назвал поддержкой иммутабельности в языке.

Цитата korvin @ 25.04.21, 09:31

В моём примере нет списка.

Тут нет списка?

Цитата korvin @ 22.04.21, 22:03

contains []     e = False
contains (x:xs) e = x == e || contains xs e

Что касается оператора ||, то хотя в конкретной реализации (например GHC) сначала действительно будет вычислено значение левого операнда, надо понимать, что это просто деталь реализации. || - это ведь просто функция двух аргументов и ты сам совершенно правильно говорил, что порядок вычисления этих аргументов не имеет значения в ФП:

Цитата korvin @ 22.04.21, 21:08

Странный вопрос. Для чистого ФП разницы нет (разве что одна из функций bar, baz значительно дольше вычисляется, чем другая).

Судя по тому, что я нашел в интернетах, Haskell не запрещает реализации вычисляющие операнды в любом порядке.

Цитата korvin @ 25.04.21, 09:31

И вот ты снова путаешь синтаксис и семантику.

То что do-нотация является сахаром к монаде - это не семантика, это детали реализации. Семантика же заключается в последовательном выполнении. И do-нотация, кмк, отходит от ФП в сторону ИП.

Цитата korvin @ 25.04.21, 09:31

foo вычислится гарантировано до вызова bar при аппликативном порядке вычислений (а это все неленивые ФП языки, F#, Ocaml, Clojure и т.д.)

Это опять же деталь реализации. Мы же не о конкретном языке говорим. ФП подразумевает нестрогую модель вычислений: порядок выполнения функций неважен.

Цитата korvin @ 25.04.21, 09:31

может вычислиться в другом порядке при нормальном порядке вычислений или просто отложенных вычислениях, например, в Си/Паскале foo может вернуть какой-то объект Promise.

Пример с Promise неудачен, функция foo-то все равно выполнена до начала выполнения функции bar. Что касается нормального порядка вычислений, то это опять же деталь реализации. Компилятор может сделать редукцию, свертку констант и так далее, а может и не сделать. Результат гарантированно будет таким же как и при реально последовательном выполнении, иначе это неправильный компилятор.
В общем, ты везде ссылаешься на конкретные реализации, причем разные в разных ФП-языках.

Сообщение отредактировано: applegame - 25.04.21, 19:45

[sergioK]

Цитата korvin @ 25.04.21, 09:31

Значит, sergioK и вправду джун, раз не понимает даже статей, на которые сам ссылается. )

Не не понимаю, я ничего кроме hello world никогда не писал

[korvin]

Цитата applegame @ 25.04.21, 19:44

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

Мало ли что ты не встречал.

Цитата applegame @ 25.04.21, 19:44

Это же трешовый костыль

В чём тут трешевость и костыльность?

Цитата applegame @ 25.04.21, 19:44

Ты бы еще просто запрет программисту менять объект назвал поддержкой иммутабельности в языке.

WUT?

Цитата applegame @ 25.04.21, 19:44

надо понимать, что это просто деталь реализации

И что, что это деталь реализации? Порядок задан? Задан.

Цитата applegame @ 25.04.21, 19:44

Судя по тому, что я нашел в интернетах, Haskell не запрещает реализации вычисляющие операнды в любом порядке.

И что? Calling conventions тоже разные бывают.

Цитата applegame @ 25.04.21, 19:44

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

Нет, это то, чем она является.

Цитата applegame @ 25.04.21, 19:44

Семантика же заключается в последовательном выполнении

Нет, не заключается.

Цитата applegame @ 25.04.21, 19:44

И do-нотация, кмк, отходит от ФП в сторону ИП.

Не отходит.

Что, по-твоему, означает эта запись:

do
    a <- foo x
    b <- bar y
    return $ gee a b

?

Цитата applegame @ 25.04.21, 19:44

Пример с Promise неудачен, функция foo-то все равно выполнена до начала выполнения функции bar.

И что, что она выполнена до? Что будет, если поменять их местами? Чем по-твоему это отличается от Хаскелла, например? Чем это отличается от ФП, если реальное вычисление может быть выполнено в любом порядке?

Цитата applegame @ 25.04.21, 19:44

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

Что ты вообще несёшь?

Ответь лучше на вопрос: почему в ИП порядок имеет значение? Что будет, если в

a = foo(x)
b = bar(y)
gee(a, b)

поменять местами вызовы foo и bar:

b = bar(y)
a = foo(x)
gee(a, b)

?

Добавлено 25.04.21, 22:20
И ещё вопрос: для ФПшной композиции порядок важен?

foo x = x + x
bar x = (x, x)

foo . bar

и

bar . foo

— одно и то же или нет?

А тут:

foo x = x + 1
bar x = x * 2
 
foo . bar
bar . foo

?

Сообщение отредактировано: korvin - 25.04.21, 22:20

[korvin]

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

Например http://csg.csail.mit.edu/pubs/memos/Memo-493/memo-493.pdf

Сообщение отредактировано: korvin - 25.04.21, 23:02

[scrambrella]

Цитата Qraizer @ 10.04.21, 15:58

Использовались ли математические методы доказательства правильности разработанных алгоритмов?
На закуску: приходилось ли проектировать системы с учётом возможных неизвестных аппаратных багов в процессорах?

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

[applegame]

Цитата korvin @ 25.04.21, 21:57

Мало ли что ты не встречал.

А ты встречал чтобы кто-нибудь в C/С++ задействовал opaque типы ради иммутабельности? Пруфы пожалуйста.

Цитата korvin @ 25.04.21, 21:57

В чём тут трешевость и костыльность?

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

Цитата korvin @ 25.04.21, 21:57

И что, что это деталь реализации? Порядок задан? Задан.

В GHC задан, в другом компиляторе может быть не задан. Ты же надеюсь понимаешь, что мы обсуждаем не конкретные реализации, а ФП в целом? Ты же сам признал, что порядок вычисления аргументов функции в ФП не имеет значения.

Цитата korvin @ 25.04.21, 21:57

Нет, это то, чем она является.

Ну тогда она является императивными машинными кодами, а реального ФП не существует.

Цитата korvin @ 25.04.21, 21:57

Что, по-твоему, означает эта запись:

Как минимум она означает, что foo будет выполнена раньше чем bar. Вся эта ваша монада IO для этого и предназначена: дать возможность в Haskell выполнять код последовательно, потому что IO - это связь с внешним миром, который императивен.

Цитата korvin @ 25.04.21, 21:57

И что, что она выполнена до? Что будет, если поменять их местами? Чем по-твоему это отличается от Хаскелла, например? Чем это отличается от ФП, если реальное вычисление может быть выполнено в любом порядке?

Если поменять местами строчки, оно просто не скомпилируется. Тем что во всякой императивщине отложенность прописывается явно, то есть программист сам решает в каком порядке делать вычисления, а в Хаскелле програмисту пофиг (до тех пор пока не столкнется с императивной реальностью) в каком порядке оно будет считаться. От ФП отличается тем, что в ИП программист точно знает, что конечный результат будет как при последовательном выполнении. А в ФП наплевать на порядок выполнения вообще, компилятор может выполнять функции в любом нужном ему порядке.

Цитата korvin @ 25.04.21, 21:57

Ответь лучше на вопрос: почему в ИП порядок имеет значение? Что будет, если в

a = foo(x)
b = bar(y)
gee(a, b)

поменять местами вызовы foo и bar:

b = bar(y)
a = foo(x)
gee(a, b)

?

Результат может измениться. А вот в чистом ФП (например Хаскеле) ничего измениться не может.

Цитата korvin @ 25.04.21, 21:57

И ещё вопрос: для ФПшной композиции порядок важен?

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

Цитата korvin @ 25.04.21, 23:01

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

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

[korvin]

Цитата applegame @ 26.04.21, 09:16

А ты встречал чтобы кто-нибудь в C/С++ задействовал opaque типы ради иммутабельности? Пруфы пожалуйста.

А если не встречал, то что это доказывает? Я так-то на Си не пишу.

Цитата applegame @ 26.04.21, 09:16

В GHC задан, в другом компиляторе может быть не задан. Ты же надеюсь понимаешь, что мы обсуждаем не конкретные реализации, а ФП в целом? Ты же сам признал, что порядок вычисления аргументов функции в ФП не имеет значения.

"Не имеет значения" и "отсутствует" --- не одно и то же

Цитата applegame @ 26.04.21, 09:16

Как минимум она означает, что foo будет выполнена раньше чем bar. Вся эта ваша монада IO для этого и предназначена: дать возможность в Haskell выполнять код последовательно, потому что IO - это связь с внешним миром, который императивен.

Не обязательно. И do-нотация не завязана на монаду IO, она работает с любой монадой, например монадой списков:

import Data.Char
 
foo = map chr . map (+ ord 'a')
bar = filter even
gee x y = (x, y)
 
main =
    let x = [1,2,3]
        y = [4,5,6]
    in print $ do
        a <- foo x
        b <- bar y
        return $ gee a b

https://ideone.com/0wW9IY

[('b',4),('b',6),('c',4),('c',6),('d',4),('d',6)]

Порядок определяется реализацией монады для конкретного типа, а не do-выражением.

Цитата applegame @ 26.04.21, 09:16

Результат может измениться. А вот в чистом ФП (например Хаскеле) ничего измениться не может.

За счёт чего же результат может измениться? )

Цитата applegame @ 26.04.21, 09:16

Ключевое тут "не изменяет наблюдаемый результат"

А за счёт чего наблюдаемый результат может измениться?

Цитата applegame @ 26.04.21, 09:16

Если поменять местами строчки, оно просто не скомпилируется.

Это в первом случае, где у функций разные типы. А во втором? Там всё прекрасно скомпилируется. А результат поменяется?

Сообщение отредактировано: korvin - 26.04.21, 10:49

[applegame]

Цитата korvin @ 26.04.21, 10:40

А если не встречал, то что это доказывает? Я так-то на Си не пишу.

Я писал много и на Си и на C++. Никто на парится иммутабельностью вообще. Раньше даже const-ом не заморачивались, сейчас юзают const, который тоже не является полноценной заменой иммутабельности. В общем никакой поддержки иммутабельности в самих языках C/С++/JS/PHP и многих других нет. Есть только попытки эмулировать ее теми или иными способами, и эти эмуляции мало кого интересуют. В Rust есть полноценная иммутабельность, в D тоже есть.

Цитата korvin @ 26.04.21, 10:40

"Не имеет значения" и "отсутствует" --- не одно и то же

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

Цитата korvin @ 26.04.21, 10:40

Не обязательно. И do-нотация не завязана на монаду IO, она работает с любой монадой, например монадой списков:

Честно говоря лень уже дальше разбираться. Мое знание Хаскеля достаточно базовое и довольно тяжело копаться даже в несложных кусках.
Погуглив по словам "haskell do imperative" обнаружил кучу упоминаний о том, что на хаскеле можно (но не нужно) писать имеративно, применяя монады, что do-нотация является псевдоимперативной или imperative style и так далее.

Цитата korvin @ 26.04.21, 10:40

За счёт чего же результат может измениться? )

Цитата korvin @ 26.04.21, 10:40

А за счёт чего наблюдаемый результат может измениться?

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

Цитата korvin @ 26.04.21, 10:40

Это в первом случае, где у функций разные типы. А во втором? Там всё прекрасно скомпилируется. А результат поменяется?

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

a = foo(x)
bar(a)

А ты о каком?

Сообщение отредактировано: applegame - 26.04.21, 15:38

[OpenGL]

Цитата applegame @ 26.04.21, 15:29

В Rust есть полноценная иммутабельность

В расте нет, там в этом плане всё точно так же.

[korvin]

Цитата applegame @ 26.04.21, 15:29

Честно говоря лень уже дальше разбираться. Мое знание Хаскеля достаточно базовое и довольно тяжело копаться даже в несложных кусках.
Погуглив по словам "haskell do imperative" обнаружил кучу упоминаний о том, что на хаскеле можно (но не нужно) писать имеративно, применяя монады, что do-нотация является псевдоимперативной или imperative style и так далее.

Отлично, "не читал, но мнение имею", "слышал звон, но не знаю где он". Как-то так.

Цитата applegame @ 26.04.21, 15:29

За счет побочных эффектов, очевидно.

А если б не было побочных эффектов?

Цитата applegame @ 26.04.21, 15:29

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

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

foo x = x + 1
bar x = x * 2
 
gee = foo . bar
qux = bar . foo

gee и qux --- это одинаковые функции или разные?

Впрочем, давай рассмотрим твой кусок:

a = foo(x)
bar(a)

заменим a на сам вызов:

bar(foo(x))

программа из императивной сразу стала функциональной?

Добавлено 26.04.21, 15:58

Цитата applegame @ 26.04.21, 15:29

Я писал много и на Си и на C++. Никто на парится иммутабельностью вообще.

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

Сообщение отредактировано: korvin - 26.04.21, 15:58

[D_KEY]

Цитата applegame @ 26.04.21, 15:29

Цитата korvin @ 26.04.21, 10:40

А за счёт чего наблюдаемый результат может измениться?

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

Так ты же выше отказался от общепринятого определения ИП, убрав оттуда изменение состояния. Откуда тогда побочные эффекты? До сих пор не понимаю, чем тебе не нравится "обычное" определение ИП.

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

Цитата applegame @ 26.04.21, 15:29

Я писал много и на Си и на C++. Никто на парится иммутабельностью вообще.

Почему первое предложение про тебя, а второе про всех?
Вот ты и не парился, когда писал

За const парятся в обязательном порядке.

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

Да даже на системном уровне попадается что-то в духе RCU, например

Сообщение отредактировано: D_KEY - 26.04.21, 16:10

[korvin]

Цитата applegame @ 26.04.21, 15:29

Честно говоря лень уже дальше разбираться. Мое знание Хаскеля достаточно базовое и довольно тяжело копаться даже в несложных кусках.
Погуглив по словам "haskell do imperative" обнаружил кучу упоминаний о том, что на хаскеле можно (но не нужно) писать имеративно, применяя монады, что do-нотация является псевдоимперативной или imperative style и так далее.

А ещё есть шутка, что Хаскелл --- это лучший императивный язык.

https://wiki.haskell.org/Do_notation_considered_harmful

Цитата

Criticism
Haskell's do notation is popular and ubiquitous. However we shall not ignore that there are several problems. Here we like to shed some light on aspects you may not have thought about, so far.

Didactics
The do notation hides functional details. This is wanted in order to simplify writing imperative style code fragments. The downsides are that:

- Since do notation is used almost everywhere IO takes place, newcomers quickly believe that the do notation is necessary for doing IO,
- Newcomers might think that IO is somehow special and non-functional, in contrast to the advertisement for Haskell being purely functional,
- Newcomers might think that the order of statements determines the order of execution.

Обрати внимание на последний пункт. Да и остальные.

Ну и там далее в статье примеры "misunderstanding"

Сообщение отредактировано: korvin - 26.04.21, 16:17

[OpenGL]

А всё-таки, какое имеет отношение opaque struct к иммутабельности?

[applegame]

Цитата OpenGL @ 26.04.21, 15:40

В расте нет, там в этом плане всё точно так же.

Да ладно? Раст позволяет такие вот фокусы?
https://glot.io/snippets/fy2i5lgz8g

import std.stdio;
struct Foo {
    int a;
    this(int x) { a = x; }
}
 
struct Bar {
    Foo* foo;
    this(Foo* f) { foo = f; }
    void print() const {
        writeln(foo.a);
    }
}
 
void main() {
    auto foo = new Foo(10);
    const bar = const Bar(foo);
    bar.print();
    //bar.foo.a = 11; // ошибка компиляции, bar иммутабелен?
    foo.a = 11;       // опаньки, bar мутировал, компилятор не возражает
    bar.print();
}

[OpenGL]

Именно в таком виде нет, т.к. если бы было можно, то легко было бы нарушить правило BC "на объект есть только одна mut ссылка". Но тем не менее это не иммутабельность, т.к. ничто не мешает менять объект, на котором нет mut, посредством Cell:

use std::cell::Cell;
 
struct Foo
{
    field: Cell<i32>,
}
 
impl Foo
{
    fn new() -> Self
    {
        Foo{field: Cell::new(42)}
    }
}
 
fn main() {
    // Иммутабельный объект
    let f = Foo::new();
    println!("{:?}", f.field.get());
    f.field.set(-42);
    // Упс, он поменялся
    println!("{:?}", f.field.get());
}

Вывод:

42
-42

Сообщение отредактировано: OpenGL - 27.04.21, 09:16

[applegame]

Цитата korvin @ 26.04.21, 15:52

Отлично, "не читал, но мнение имею", "слышал звон, но не знаю где он". Как-то так.

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

Цитата korvin @ 26.04.21, 16:11

А ещё есть шутка, что Хаскелл --- это лучший императивный язык.
https://wiki.haskell.org/Do_notation_considered_harmful

Я читал эту статью. Первый раз лет пять назад, когда изучал Хаскель, второй раз позавчера
То что там написано не опровергает того что пишу я. Результат выполнения инструкций в do-нотации будет таким же как если бы они выполнялись последовательно, вне зависимости от того чистые там функции или грязные. Согласен? В точности как в ИП. Статья большая, а ты выбрал одну фразу и выдрал ее из контекста. Молодец, чо.
В шутке про лучший императивный язык, как обычно только доля шутки. На Хаскеле можно извратиться и писать императивно, я видел даже эквивалент обычных циклов, сделанный на монадах. Правда Хаскель скорее все же худший императивный язык

Цитата korvin @ 26.04.21, 15:52

А если б не было побочных эффектов?

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

Цитата korvin @ 26.04.21, 15:52

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

Я ответил на этот вопрос, ты правда никак не отреагировал.

Цитата korvin @ 26.04.21, 15:52

Впрочем, давай рассмотрим твой кусок:

И ты мне предлагаешь проверить память после этого. Обсуждали же уже этот кусок и этот вопрос. Смотри конец поста: Что делать с жунами (сообщение #3846765)

Цитата D_KEY @ 26.04.21, 16:02

Так ты же выше отказался от общепринятого определения ИП, убрав оттуда изменение состояния. Откуда тогда побочные эффекты? До сих пор не понимаю, чем тебе не нравится "обычное" определение ИП.

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

int a = foo(x)
if(a == 0) return 1;
a = a + bar(a);
if(a == 1) return 2;
return 3;

Теперь добавим иммутабельности.

immutable a = foo(x)
if(a == 0) return 1;
immutable a1 = a + bar(a);
if(a1 == 1) return 2;
return 3;

Теперь это функциональщина?
Опять начнешь растекаться мыслью по древу, что тут нельзя точно сказать, что это смесь разных парадигм и так далее?

Цитата D_KEY @ 26.04.21, 16:02

Почему первое предложение про тебя, а второе про всех?
Вот ты и не парился, когда писал

За const парятся в обязательном порядке.

Ты похоже один из тех, кто думает, что const в C/C++ - это и есть иммутабельность.
За const в мейнстриме начали парится с появлением его в C++ и C, то бишь в начале 90-х. С иммутабельностью мало кто парится и по сей день.
Что касается лично меня. Я начал париться за const с 1994-го когда мне в инстутуте объяснили зачем он нужен. На иммутабельность я обратил внимание когда начал писать на D (лет 7 назад), а окончательно уверовал в ее полезность, когда начал изучать ФП на примере Хаскеля (лет 5 назад).

Цитата D_KEY @ 26.04.21, 16:02

Да даже на системном уровне попадается что-то в духе RCU, например

RCU прямого отношения к иммутабельности не имеет. Имутабельность может форсировать RCU, но не наоборот.

Добавлено 27.04.21, 10:08

Цитата OpenGL @ 27.04.21, 09:14

Именно в таком виде нет, т.к. если бы было можно, то легко было бы нарушить правило BC "на объект есть только одна mut ссылка". Но тем не менее это не иммутабельность, т.к. ничто не мешает менять объект, на котором нет mut, посредством Cell:

Мде. Похоже и правда полноценную иммутабельность можно сделать только в языках с GC.

[D_KEY]

Цитата applegame @ 27.04.21, 09:59

То что в моем определении нет необходимости в мутабельных переменных, не означает, что ИП не может иметь побочных эффектов. В общепринятом определении наличие последовательности инструкций - это необходимое, но недостаточное условие для ИП, а в моем это необходимое и достаточное условие.

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

[D_KEY]

Цитата applegame @ 27.04.21, 09:59

Почему мне не нравится общепринятое определение, я тебе уже объяснял, но ты игнорируешь мои объяснения.

Ты не объясняешь, а приводишь странные примеры, в основном Как и ниже, собственно.

Цитата

Теперь это функциональщина?

Зависит от наличия побочных эффектов
Ты приводишь очень маленькие куски кода.

Цитата

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

Так если оно так и есть?

Цитата

Ты похоже один из тех, кто думает, что const в C/C++ - это и есть иммутабельность.

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

[applegame]

Цитата D_KEY @ 27.04.21, 15:36

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

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

Цитата D_KEY @ 27.04.21, 18:02

Ты не объясняешь, а приводишь странные примеры, в основном Как и ниже, собственно.

А в чем их странность? Подобный код встречается сплошь и рядом.

Цитата D_KEY @ 27.04.21, 18:02

Зависит от наличия побочных эффектов

Ха. Хорошо, пусть foo и bar - это чистые функции, этот код написан в ФП-парадигме?

immutable a = foo(x)
if(a == 0) return 1;
immutable a1 = a + bar(a);
if(a1 == 1) return 2;
return 3;

Цитата D_KEY @ 27.04.21, 18:02

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

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

Цитата D_KEY @ 27.04.21, 18:02

Так если оно так и есть?

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

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

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

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

immutable a = foo(x)
if(a == 0) return 1;
immutable a1 = a + bar(a);
if(a1 == 1) return 2;
return 3;

даже если функции считать чистыми, все равно, в определенном смысле, имеет мутабельный стейт. Условно говоря - это контекст (в лице стека, например). В третьей строке в контексте появилась новая переменная a1 - считай мутировал стейт. Какая по сути разница: в коробке лежал синий кубик, мы вытащили его и положили вместо него красный кубик или лежал синий, а красный мы положили рядом? Один фиг содержимое коробки (стейт) изменилось.
В русской википедии в статье о ФП (не ИП, ) есть интересная цитата:

Цитата

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

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

Сообщение отредактировано: applegame - 28.04.21, 08:27

[D_KEY]

Цитата applegame @ 28.04.21, 08:08

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

Если нет побочных эффектов, то последовательность действий фактически важна лишь с точки зрения корректности вычислений. А тут нет никаких отличий от ФП.

[applegame]

Цитата OpenGL @ 27.04.21, 09:14

Но тем не менее это не иммутабельность, т.к. ничто не мешает менять объект, на котором нет mut, посредством Cell:

По поводу Rust. А вот этот вот Cell - это же не конструкция языка, а элемент стандратной библиотеки. Он внутри unsafe? Я к тому, что не является ли этот Cell каким-то способом, так сказать обмануть компилятор?
Ну как скажем в D можно тоже при желании мутировать immutable переменные в unsafe коде через cast.

Добавлено 28.04.21, 09:43

Цитата D_KEY @ 28.04.21, 08:45

Если нет побочных эффектов, то последовательность действий фактически важна лишь с точки зрения корректности вычислений. А тут нет никаких отличий от ФП.

Есть: в чистом ФП само понятие последовательность вычислений не имеет сымсла. Ты остальное-то читал?

[D_KEY]

Цитата applegame @ 28.04.21, 09:40

Есть: в чистом ФП само понятие последовательность вычислений не имеет сымсла.

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

Добавлено 28.04.21, 11:24

Цитата applegame @ 28.04.21, 08:08

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

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

Добавлено 28.04.21, 11:27

Цитата applegame @ 28.04.21, 08:08

даже если функции считать чистыми, все равно, в определенном смысле, имеет мутабельный стейт. Условно говоря - это контекст (в лице стека, например). В третьей строке в контексте появилась новая переменная a1 - считай мутировал стейт. Какая по сути разница: в коробке лежал синий кубик, мы вытащили его и положили вместо него красный кубик или лежал синий, а красный мы положили рядом? Один фиг содержимое коробки (стейт) изменилось.

Если мы убираем побочные эффекты и изменение состояния (на уровне семантики языка), то это все становится лишь деталью реализации.

[korvin]

Цитата applegame @ 28.04.21, 08:08

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

И какая нам польза в этом знании?

[Qraizer]

Цитата applegame @ 23.04.21, 15:01

Возможно ошибаюсь, но вроде именно он зарубил нормальный static if.

А чем if constexpr не устраивает? Я, кстати, пока ни разу не пользовался, так что моё мнение может быть необъективным, но-таки заявлю, что коли зарубил, значит были причины. Концепты, вон, тоже зарубили в своё время, зато сейчас они выглядят логичнее и понятнее. Та и std::filesystem нонешный мне нравится куда как сильнее по сравнению с начальной редакцией, слизанной с буста. Зато спешка с принятием std::wstring_convert и std::wbuffer_convert сказалась весьма неприятно. Я поначалу вслед за Wound тоже был разочарован отказом от него, но проведя собственное "расследование", склоняюсь к тому, что буду скорее на стороне отмены.

Добавлено 28.04.21, 12:38

Цитата applegame @ 24.04.21, 18:01

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

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

Добавлено 28.04.21, 12:45

Цитата applegame @ 24.04.21, 18:01

Отсюда делаю. вывод: "конвенционально принятое" определение ИП устарело. Ключевое - это последовательность инструкций

Точно? Я бы определил императивность как метод, описывающий однозначную последовательность инструкций по получению результатов из входных данных. В отличие от декларативности, наиболее простым примером чего можно привести язык скриптов make. Одним из синонимом императивности является категоричность. По этому критерию ФП не ортогонально ИП, а является его более частным случаем, с дополнительными ограничительными методиками.

Добавлено 28.04.21, 12:49

Цитата sergioK @ 25.04.21, 21:02

Не не понимаю, я ничего кроме hello world никогда не писал

Предлагаю перейти к решению квадратных уравнений.

Добавлено 28.04.21, 12:53

Цитата scrambrella @ 26.04.21, 07:41

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

Ну вот, а вы на sergioK-а наезжаете. sergioK нормальный парень.

Цитата scrambrella @ 26.04.21, 07:41

Программа должна работать на компьютере, который не умеет считать?

Ужос, правда?

Добавлено 28.04.21, 12:56

Цитата D_KEY @ 26.04.21, 16:02

За const парятся в обязательном порядке.

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

Добавлено 28.04.21, 13:03

Цитата applegame @ 27.04.21, 09:59

Поэтому в ИП последовательность инструкций важна, а в ФП нет.

В догонку себе. Это следствие тех дополнительных качеств ФП, а не собственно базовое его отличие от ИП. Оно там просто всегда применимо. Я могу себе представить и в ИП то же самое, но конечно далеко не всегда, а в весьма частных случаях. Хотя тут от компилятора зависит, Intel C++, например, умеет раздербанивать всю программу целиком, и неважно, из скольких единиц трансляции она состоит. Запастись памятью и временем надо лишь.

[Pavia]

Цитата Qraizer @ 28.04.21, 12:34

Ну вот, а вы на sergioK-а наезжаете. sergioK нормальный парень.
Цитата scrambrella @ 26 апреля, 10:41
Программа должна работать на компьютере, который не умеет считать?
Ужос, правда?

На работающем не могут правильно сделать расчёты.
Плохой софт отправил работников почты за решетку
https://habr.com/ru/company/itsoft/blog/554404/
Джанет Скиннер рассказывает, что её разлучили с двумя детьми на девять месяцев, в течение которых она находилась в тюрьме, после того, как Horizon показал недостачу в £59,000. Она также сообщает, что потеряла предложение о работе из-за своей судимости. Время, проведенное ею и другими в тюрьме, невозможно вернуть, и это произошло, потому что программе доверяли на слово.

[OpenGL]

Цитата Qraizer @ 28.04.21, 12:34

Припоминаю спор о видах полиморфизма.

Ссылка есть?

Добавлено 28.04.21, 14:02

Цитата applegame @ 28.04.21, 09:40

По поводу Rust. А вот этот вот Cell - это же не конструкция языка, а элемент стандратной библиотеки. Он внутри unsafe?

Да, Cell, RefCell и остальное юзают внутри unsafe.

[Qraizer]

Цитата sergioK @ 22.04.21, 22:48

Что за ролик то про столицу IT ?

IT-Столица России. Таганрог

[Qraizer]

Цитата OpenGL @ 28.04.21, 13:57

Ссылка есть?

Та где-то тут в Холиварах. Поди найди, при неработающем поиске-то.

[applegame]

Цитата D_KEY @ 28.04.21, 11:18

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

Так это будут уже детали реализации. А нам важен код, а не реализация исполнителя этого кода.

Цитата D_KEY @ 28.04.21, 11:18

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

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

Цитата

x = 3
y = x + 1
z = y + 2

Может создаться ложное впечатление, что это последовательность из трех инструкций, аналогично, например этому коду в языке D:

const x = 3;
const y = x + 1;
const z = y + 2;

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

Цитата

z = y + 2
y = x + 1
x = 3

В императивном коде такой фокус не прокатит.
В D в принципе возможно писать в аналогичном ФП-стиле при помощи лямбд:

alias z = () => y() + 2;
alias y = () => x() + 1;
alias x = () => 3;

Забавно, но в C/C++ это можно это сделать, используя макросы. Вот такое ФП (причем полиморфное, все по-взрослому ):

#define z (y + 2)
#define y (x + 1)
#define x 3

C++ - лучший ФП-язык.

Цитата D_KEY @ 28.04.21, 11:18

Если мы убираем побочные эффекты и изменение состояния (на уровне семантики языка), то это все становится лишь деталью реализации.

Не совсем понимаю, что значит "убираем изменение состояния на уровне семантики языка". Пример можно? В ИП промежуточные результяты создаются явно в коде, в виде переменных, в том числе иммутабельных. Если в коде явно не создавать промежуточных результатов, то наверное получится ФП.

Цитата korvin @ 28.04.21, 12:04

И какая нам польза в этом знании?

Польза большая: нам не нужно знать чистые эти функции или нет, просто считаем, что инструкции выполняются друг за другом.
Например в том же Erlang/Elixir вообще нет понятия чистоты функций. Они могут быть чистыми или грязными - пофиг. То же самое и в do-нотации Haskell.

[korvin]

Цитата applegame @ 29.04.21, 09:31

Польза большая: нам не нужно знать чистые эти функции или нет

Мы знаем, что они чистые.

Цитата applegame @ 29.04.21, 09:31

То же самое и в do-нотации Haskell.

В Хаскелле все функции чистые и do-нотация, как и монады, не имеют отношения к чистоте.

[Qraizer]

А если так?

auto x = []{ return 3; };
auto y = []{ return x() + 1; };
auto z = []{ return y() + 2; };

[applegame]

Цитата korvin @ 29.04.21, 10:06

Мы знаем, что они чистые.

Если знаем, то ИП можно не применять. ИП полезно тем, что не нужно знать. Ты можешь знать если хочется, но тебе это не нужно, пусть об этом знает компилятор.
От твоего знания чистые это функции или нет ИП не превращается в ФП и наоброт. Парадигма кода зависит от семантики языка, и собственно самого кода. От твоего знания что функции bar и foo чистые, ИП код

Цитата

immutable a = foo(x)
if(a == 0) return 1;
immutable a1 = a + bar(a);
if(a1 == 1) return 2;
return 3;

не станет внезапно ФП.

Цитата korvin @ 29.04.21, 10:06

В Хаскелле все функции чистые

Не все. Иначе IO был бы просто невозможен.
Каждая IO-функция получает в качастве параметра, условное состояние внешнего мира, полученное из предыдущей IO-функции, делает IO и возвращает измененное состояние. НО! Если, допустим, функции чтения символа с клавиатуры подсунуть несколько раз одно и то же состояние мира, то она запросто может вернуть разные значения. Чтобы такого не происходило, в Хаскеле IO-функции вместе с сотоянием мира плотно завернуты в монаду, и остальные функции не имеют доступа к этому состоянию и, соответственно, не могут заставить IO-функцию вызваться с одним и тем же состоянием.
Получается, что IO-функция как хитрожопый коррупционер: все знают что делишки грязные, но нет никакой возможности доказать это в рамках языка, формально все чисто. А все потому что все коррупционеры (IO-функции) в сговоре и никому, кроме как друг-другу, свои внутренние дела не раскрывают.
Но они все равно с побочными эффектами, иначе порядок их вызова был бы не важен. Тем они и отличаются от обычных функций.

Цитата korvin @ 29.04.21, 10:06

и do-нотация, как и монады, не имеют отношения к чистоте.

Да, монады упрощают построение цепочек вызовов функций со скрытым внутренним состоянием.
do-нотация имеет отношение к последовательности инструкций. Об этои говорит название нотации (do) и название её элементов (statements).
Некоторые авторы пытаются зачем-то откреститься от этого. Например в пресловутой статье: https://wiki.haskell.org/Do_notation_considered_harmful написано:

Цитата

The order of statements is also not the criterion for the evaluation order. Also here only the data dependencies count.

Что в общем случае является ложью. В качестве примера там берутся чистые функции. Но ведь если бы там были IO-функции с побочными эффектами, То the order of statements очень даже был бы the criterion for the evaluation order, при том что никаких явных data dependencies может вообще не быть.

Добавлено 29.04.21, 14:25

Цитата Qraizer @ 29.04.21, 12:52

А если так?

auto x = []{ return 3; };
auto y = []{ return x() + 1; };
auto z = []{ return y() + 2; };

Так не нужно. Вот если бы можно было так:

auto z = []{ return y() + 2; };
auto y = []{ return x() + 1; };
auto x = []{ return 3; };

то было бы нунифигасебе.

[korvin]

Цитата applegame @ 29.04.21, 14:19

не станет внезапно ФП.

Почему это?

Вот этот код тоже императивный:

foo() +
bar() +
gee() +
qux()

?

А этот:

foo() >>
bar() >>
gee() >>
qux()

?

Может, этот:

foo() ;
bar() ;
gee() ;
qux()

?

Какой из этих примеров — чистая композиция функций (например, на Хаскелле), а какой — императивная последовательность statement'ов (например, на Паскале)?

Цитата applegame @ 29.04.21, 14:19

Не все. Иначе IO был бы просто невозможен.

IO не имеет отношения к языку. Они разделены.

Цитата applegame @ 29.04.21, 14:19

do-нотация имеет отношение к последовательности инструкций. Об этои говорит название нотации (do) и название её элементов (statements).

Не имеет. Тебе уже пример приводили.

Цитата applegame @ 29.04.21, 14:19

Некоторые авторы пытаются зачем-то откреститься от этого. Например в пресловутой статье: https://wiki.haskell.org/Do_notation_considered_harmful написано:

всего-то wiki на сайте языка, наполняемая и модерируемая сообществом хаскеллистов.
При этом и Haskell Report не пишет ни о какой «последовательности инструкций».

Цитата applegame @ 29.04.21, 14:19

Что в общем случае является ложью.

Э нет, это чистая правда и просто факт. Но ты скатился до уровня Серёжи, ему тоже тыкали фактами в нос, а он продолжал витать в своих фантазиях.

Цитата applegame @ 29.04.21, 14:19

Каждая IO-функция получает в качастве параметра, условное состояние внешнего мира, полученное из предыдущей IO-функции, делает IO и возвращает измененное состояние. НО! Если, допустим, функции чтения символа с клавиатуры подсунуть несколько раз одно и то же состояние мира, то она запросто может вернуть разные значения. Чтобы такого не происходило, в Хаскеле IO-функции вместе с сотоянием мира плотно завернуты в монаду, и остальные функции не имеют доступа к этому состоянию и, соответственно, не могут заставить IO-функцию вызваться с одним и тем же состоянием.
Получается, что IO-функция как хитрожопый коррупционер: все знают что делишки грязные, но нет никакой возможности доказать это в рамках языка, формально все чисто. А все потому что все коррупционеры (IO-функции) в сговоре и никому, кроме как друг-другу, свои внутренние дела не раскрывают.
Но они все равно с побочными эффектами, иначе порядок их вызова был бы не важен. Тем они и отличаются от обычных функций.

а все другие монады, прячущие свои внутренности тоже в каком-то сговоре?

Порядок «вызова» IO-функций задаётся обычной чистой функциональной композицией.

Добавлено 29.04.21, 19:12

Цитата applegame @ 29.04.21, 14:19

Но ведь если бы там были IO-функции с побочными эффектами, То the order of statements очень даже был бы the criterion for the evaluation order

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

Сообщение отредактировано: korvin - 29.04.21, 19:13

[D_KEY]

Цитата applegame @ 29.04.21, 09:31

Цитата D_KEY @ 28.04.21, 11:18

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

Так это будут уже детали реализации. А нам важен код, а не реализация исполнителя этого кода.

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

Добавлено 29.04.21, 19:38

Цитата applegame @ 29.04.21, 09:31

Не исключаю, а делаю необязательным. Не надо искажать.

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

Цитата

В чистом ФП (идеальном) в коде нет явных промежуточных результататов, даже иммутабельных

Да почему это важно, если видимый результат никак от этого не зависит?

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

Добавлено 29.04.21, 19:45

Цитата applegame @ 29.04.21, 09:31

В императивном коде такой фокус не прокатит.

Аналогом того кода на haskell в С++ будет:

int x()
{
    return 3;
}
 
int y()
{
    return x() + 1
}
 
int z()
{
    return y() + 2;
}

Для перестановки достаточно заранее объявить функции:

int x();
int y();
int z();

И инструкции тут ни при чем, это особенности областей видимости имен.

Сообщение отредактировано: D_KEY - 29.04.21, 19:45

[applegame]

Цитата korvin @ 29.04.21, 19:11

Почему это?

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

Цитата korvin @ 29.04.21, 19:11

Какой из этих примеров — чистая композиция функций (например, на Хаскелле), а какой — императивная последовательность statement'ов (например, на Паскале)?

Последний - ИП, первые два ФП.

Цитата korvin @ 29.04.21, 19:11

IO не имеет отношения к языку. Они разделены.

Это тут причем? Ты сказал, что все функции в Хаскеле чистые. Раз возможно IO, значит возможны функции с побочными эффектами.

Цитата korvin @ 29.04.21, 19:11

Не имеет. Тебе уже пример приводили.

Пример чего?

Цитата korvin @ 29.04.21, 19:11

всего-то wiki на сайте языка, наполняемая и модерируемая сообществом хаскеллистов.
При этом и Haskell Report не пишет ни о какой «последовательности инструкций».

Опять апеллирование к авторитету.

Цитата korvin @ 29.04.21, 19:11

Э нет, это чистая правда и просто факт. Но ты скатился до уровня Серёжи, ему тоже тыкали фактами в нос, а он продолжал витать в своих фантазиях.

Понеслась волшебная аргументация. Я не знаю как тебе уже объяснять. Если по-твоему вот тут результат не зависит от порядка стейтментов, то я хз кто тут больше похож на Сирожу

main = do
  putStrLn "str1"
  putStrLn "str2"

Цитата korvin @ 29.04.21, 19:11

а все другие монады, прячущие свои внутренности тоже в каком-то сговоре?

Откуда такой вывод? Почему все, если я говорил о хаскельном IO, в том числе и о монаде IO?

Цитата korvin @ 29.04.21, 19:11

Порядок «вызова» IO-функций задаётся обычной чистой функциональной композицией.

В чистой ФП-композиции порядок может быть любым, уже обсуждали и ты вроде согласился. Опять по кругу?

Цитата korvin @ 29.04.21, 19:11

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

Ага, а то что эти критерии коррелируют с порядком стейтментов в do-нотации - это просто совпадение? Не думаю.

Ладно, походу этот холивор порвался.
Лично мне надоело.

Сообщение отредактировано: applegame - 29.04.21, 19:56

[scrambrella]

Функциональное и логическое программирование - единственно верные стили. ООП и ИП в топку. На С/С++ легко писать функционально.

[applegame]

Цитата D_KEY @ 29.04.21, 19:26

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

В общем ладно. Если ты тоже как и Корвин, считаешь, что парадигма этого кода зависит от чистоты функций bar и foo:

immutable a = foo(x)
if(a == 0) return 1;
immutable a1 = a + bar(a);
if(a1 == 1) return 2;
return 3;

То мне не о чем больше с вами спорить.
Делаем функции foo и bar чистыми, и опаньки - это ФП код, делаем с побочными эффектами и снова ИП
Ну ок, оставайтесь при своем мнении.

Сообщение отредактировано: applegame - 29.04.21, 19:53

[D_KEY]

Цитата applegame @ 29.04.21, 19:46

Если по-твоему вот тут результат не зависит от порядка стейтментов, то я хз кто тут больше похож на Сирожу

main = do
  putStrLn "str1"
  putStrLn "str2"

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

[applegame]

Цитата D_KEY @ 29.04.21, 19:58

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

Да ваще, код поменялся до неузнаваемости:

main =
    putStrLn "str1" >>
    putStrLn "str2"

Добавлено 29.04.21, 20:08
Кстати в Erlang/Elixir нет мутабельных переменных, но полно функций с побочными эффектами. Значит таки можно писать императивно (по вашему определению) без мутабельных переменных?

Сообщение отредактировано: applegame - 29.04.21, 20:23

[korvin]

applegame,

main = myMain $ do
  myPutStrLn "first"
  myPutStrLn "second"
  myPutStrLn "third"

third
second
first

impl

import Control.Applicative
 
data MyCoolIO a = MCIO (IO a)
 
instance Functor MyCoolIO where
  fmap f (MCIO xIO)  =  MCIO $ fmap f xIO
 
instance Applicative MyCoolIO where
  pure = MCIO . pure
  (MCIO fIO) <*> (MCIO xIO)  =  MCIO $ fIO <*> xIO
 
instance Monad MyCoolIO where
  return = pure
 
  (MCIO xIO) >>= f          =  MCIO $ xIO >>= \x -> (let (MCIO r) = f x in r)
  (MCIO xIO) >> (MCIO yIO)  =  MCIO $ yIO >>= \y -> (xIO >> return y)
 
myPutStrLn :: String -> MyCoolIO ()
myPutStrLn s = MCIO $ putStrLn s
 
myMain :: MyCoolIO () -> IO ()
myMain (MCIO io) = io

— https://ideone.com/9nbY5V

Давай, расскажи ещё про порядок в do-выражении.

Добавлено 29.04.21, 20:36

Цитата applegame @ 29.04.21, 20:03

Значит таки можно писать императивно (по вашему определению) без мутабельных переменных?

В нашем определении есть изменяемое состояние, а не «мутабельные переменные».

Добавлено 29.04.21, 20:38

Цитата applegame @ 29.04.21, 19:46

Последний - ИП, первые два ФП.

Не угадал.

Добавлено 29.04.21, 20:42

Цитата applegame @ 29.04.21, 19:46

Откуда такой вывод? Почему все, если я говорил о хаскельном IO, в том числе и о монаде IO?

Оттуда, что do-нотация работает с любой монадой, а не только монадой IO.

Цитата applegame @ 29.04.21, 19:46

Раз возможно IO, значит возможны функции с побочными эффектами.

В Хаскелле нет функций с побочными эффектами.

Цитата applegame @ 29.04.21, 19:46

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

Попробуй ещё раз поразмыслить над фразой «синтаксис != семантика».

Цитата applegame @ 29.04.21, 19:46

Пример чего?

Пример использования do-нотации с «чистыми» (не-IO) монадами.

Цитата applegame @ 29.04.21, 19:46

В чистой ФП-композиции порядок может быть любым, уже обсуждали и ты вроде согласился. Опять по кругу?

По-моему, это ты согласился, что (foo . bar) и (bar . foo) — не одно и то же. Или ты так и не понял, что это значит?

Цитата applegame @ 29.04.21, 19:46

Ага, а то что эти критерии коррелируют с порядком стейтментов в do-нотации - это просто совпадение?

Не коррелируют.

[applegame]

Цитата korvin @ 29.04.21, 20:35

Пример использования do-нотации с «чистыми» (не-IO) монадами.

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

Цитата korvin @ 29.04.21, 20:35

Давай, расскажи ещё про порядок в do-выражении.

А что тут рассказывать? Меняем первую и вторую строчку местами:

main = myMain $ do
  myPutStrLn "second"
  myPutStrLn "first"
  myPutStrLn "third"

И, ой! Как такое могло случиться? Результат тоже поменялся:

third
first
second

Чудеса, монада не поменялась, а порядок поменялся.
А ведь они ваще

Цитата korvin @ 29.04.21, 20:35

Не коррелируют.

В общем зря ты мучался, выводил инструкции задом наперед. Давай теперь программу, которая фигачит инструкции в рандомном порядке. Правда функция генерации СЧ сама будет с побочными эффектами. Придется еще сложнее мудрить код.
Впрочем, подозреваю, что это таки возможно. Я даже в чистом императивном коде на D или Nim могу провернуть подобную фигню Правда хз, что это докажет.

Добавлено 29.04.21, 20:47
Ладно, плевать на монады, нотации, и прочую ересь. Надоело.

Вот:

Цитата applegame @ 29.04.21, 20:03

Кстати в Erlang/Elixir нет мутабельных переменных, но полно функций с побочными эффектами. Значит таки можно писать императивно (по вашему определению) без мутабельных переменных?

Опровергайте.

Сообщение отредактировано: applegame - 29.04.21, 21:00

[korvin]

Цитата applegame @ 29.04.21, 20:44

И, ой! Как такое могло случиться? Результат тоже поменялся:
Чудеса, монада не поменялась, а порядок поменялся.

какой же ты, всё-таки, тупой.

import Control.Applicative
import Data.Time.Clock.POSIX (getPOSIXTime)
 
data MyCoolIO a = MCIO (IO a)
 
instance Functor MyCoolIO where
  fmap f (MCIO xIO)  =  MCIO $ fmap f xIO
 
instance Applicative MyCoolIO where
  pure = MCIO . pure
  (MCIO fIO) <*> (MCIO xIO)  =  MCIO $ fIO <*> xIO
 
instance Monad MyCoolIO where
  return = pure
 
  (MCIO xIO) >>= f          =  MCIO $ xIO >>= \x -> (let (MCIO r) = f x in r)
  (MCIO xIO) >> (MCIO yIO)  =  MCIO $ do
    now <- getPOSIXTime
    if even (round now) then xIO >> yIO
    else yIO >>= \y -> (xIO >> return y)
 
myPutStrLn :: String -> MyCoolIO ()
myPutStrLn s = MCIO $ putStrLn s
 
myMain :: MyCoolIO () -> IO ()
myMain (MCIO io) = io
 
main = myMain $ do
  myPutStrLn "first"
  myPutStrLn "second"
  myPutStrLn "third"

Добавлено 29.04.21, 21:23

Цитата applegame @ 29.04.21, 20:44

Опровергайте.

Что опровергать? Ты даже не читаешь, что тебе пишут.

Добавлено 29.04.21, 21:26

Цитата applegame @ 29.04.21, 20:44

Правда хз, что это докажет.

Это доказывает, что ты
1) не читаешь, что тебе пишут
2) не пытаешься понять, что тебе пишут
3) не разбираешься в том, о чём пишешь
4) продолжаешь с завидным упорством игнорировать факты

[applegame]

Цитата korvin @ 29.04.21, 21:22

какой же ты, всё-таки, тупой.

Лентяй. second-то все время посередине. Все ещё зависит от порядка инструкций.
Ты просто выкинь вообще результат do-нотации, и напечатай что попало. Вот это будет супер-доказательство твоей правоты: вообще ничего не будет коррелировать.

Добавлено 29.04.21, 21:34

Цитата korvin @ 29.04.21, 21:22

Это доказывает, что ты
1) не читаешь, что тебе пишут
2) не пытаешься понять, что тебе пишут
3) не разбираешься в том, о чём пишешь
4) продолжаешь с завидным упорством игнорировать факты

Этот корвин порвался, несите другого.

Сообщение отредактировано: applegame - 29.04.21, 21:45

[korvin]

applegame, ясно-понятно, ты таки достиг уровня Серёжи. Не планируешь в Израиль переехать?

[applegame]

Вот сам написал:

myMain x = print "VICTORY!"
 
main = myMain $ do
  print "first"
  print "second"
  print "third"

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

Добавлено 29.04.21, 21:44

Цитата korvin @ 29.04.21, 21:43

applegame, ясно-понятно, ты таки достиг уровня Серёжи. Не планируешь в Израиль переехать?

Нет, я же за Палестину.

Сообщение отредактировано: applegame - 29.04.21, 21:45

[korvin]

Цитата applegame @ 29.04.21, 21:43

Вообще никакой корреляции между порядком и вообще инструкциями и результатом

Молодец. И нахрена ты три страницы утверждал обратное?

Добавлено 29.04.21, 21:48

Цитата applegame @ 29.04.21, 21:43

Нет, я же за Палестину.

Тоже неплохой вариант. Даже лучше.

[applegame]

Цитата korvin @ 29.04.21, 21:47

Молодец. И нахрена ты три страницы утверждал обратное?

Да вот, теперь сам удивляюсь.

Добавлено 29.04.21, 22:00
Тут еще удивительное открытие.
Оказывается в императивных языках с побочными эффектами, от порядка инструкций тоже ничего не зависит. Как так?!

https://glot.io/snippets/fy5bbbksrd

import std.stdio;
 
alias myMain = x => writeln("VICTORY!!!");
 
void main() {
    myMain({
        writeln("first");
        writeln("second");
        writeln("third");
    });
}

[korvin]

Цитата applegame @ 29.04.21, 21:48

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

Т.е. твоё «определение», что ИП — это порядок инструкций и ничего более, оказалось несостоятельным. Поздравляю.

Сообщение отредактировано: korvin - 29.04.21, 22:35

[applegame]

Цитата korvin @ 29.04.21, 22:33

Т.е. твоё «определение», что ИП — это порядок инструкций и ничего более, оказалось несостоятельным. Поздравляю.

Хуже. Твое тоже оказалось несостоятельным. Так что и себя поздравь. И D_KEY-я не забудь. Да вообще всех поздравь, ничьё определение не оказалось состоятельным. Программирования не существует, особенно если инструкции закомментировать. ПА-БЕ-ДААА!

Сообщение отредактировано: applegame - 30.04.21, 04:28

[korvin]

Цитата applegame @ 30.04.21, 04:21

Хуже. Твое тоже оказалось несостоятельным. Так что и себя поздравь. И D_KEY-я не забудь. Да вообще всех поздравь, ничьё определение не оказалось состоятельным. Программирования не существует, особенно если инструкции закомментировать. ПА-БЕ-ДААА!

[OpenGL]

Я правильно понимаю, что ваш спор сводится к тому, считать ли набор локальных переменных у функции состоянием, или нет? Если это состояние, то в определении ИП по applegame состояние никуда не девается, просто оно автоматически следует из
последовательности инструкций, и, следовательно, не обязательно в явном виде подчёркивать его наличие. А если это не состояние, то тогда тем более нет никаких проблем с его определением.

[Qraizer]

Цитата applegame @ 29.04.21, 14:19

Так не нужно. Вот если бы можно было так:

auto z = []{ return y() + 2; };
auto y = []{ return x() + 1; };
auto x = []{ return 3; };

то было бы нунифигасебе.

Следующий наводящий вопрос. А так?

std::function<int()> x, y, z;
 
z = []{ return y() + 2; };
y = []{ return x() + 1; };
x = []{ return 3; };

Добавлено 30.04.21, 11:31

Цитата scrambrella @ 29.04.21, 19:46

На С/С++ легко писать функционально.

Не очень легко. Но в целом запросто.

Добавлено 30.04.21, 11:35

Цитата applegame @ 29.04.21, 20:44

Давай теперь программу, которая фигачит инструкции в рандомном порядке.

Пффф. Даже язык такой есть.

Добавлено 30.04.21, 11:41
Нет, OpenGL. Они пытаются определить чёткие грани между двумя парадигмами, не понимая, что их нет.