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

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

I>>>К сожалению, именно такой код часто и пишут функционалисты и называют это "красиво". Я даже видел библиотеки всерьёз написаные в подобном стиле на C# и даже на JS

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

I>Я пишу про те кейсы, где это неуместно. Типа это надо объяснять ?
Конечно. Ты только сейчас оговорился, что это бывает уместно, а ты лишь про те кейсы, где это неуместно.
I>Кроме того:
I> — на кой ляд изобретат велосипед в ЯП с другой парадигмой, где вообще всё построено на других принципах ?
Что бы было чем воспользоваться, если, вдруг, понадобились принципы, отличные от безальтернативно предлагаемых в данном ЯП.
I> — преждевременная пессимизация "всё и так будет работать" не менее вредна чем преждевременная оптимизация.
Убеди количественной оценкой вредности в среднем по больнице на сфероконических проектах.
I> — сложность сопровождения вырастает — нужно постоянно продираться через такие велосипеды, соответсвенно, такое решение обычно усложняет проект, а не наоборот.
Такое решение может давать гарантии, которых не может дать обычное решение. Как следствие, упрощает проект. Конечно, я здесь не про всевозможные велосипеды, а за те, которые обладают некими полезными свойствами как персистентность.

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

G>Помоему все претензии к Microsoft и .NET\C# уже должны кончиться.

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

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

I>>Я пишу про те кейсы, где это неуместно. Типа это надо объяснять ?
S>Конечно. Ты только сейчас оговорился, что это бывает уместно, а ты лишь про те кейсы, где это неуместно.

Вот такое, как ты показал, уместно в основном при портировании с другого функционального языка. А вот C# имеет кучу собственных вещей, которые позволяют эффективно работать со списками в функциональном стиле.
Это эффективно в силу особенностей портирования — вместо переписывания есть вариант "скопировать и подправить механически". При портировании важно сохранить вообще все кейсы, в т.ч. выроденные, про которые никто уже не знает.

I>>Кроме того:
I>> — на кой ляд изобретат велосипед в ЯП с другой парадигмой, где вообще всё построено на других принципах ?
S>Что бы было чем воспользоваться, если, вдруг, понадобились принципы, отличные от безальтернативно предлагаемых в данном ЯП.

Ага, "на всякий случай"

I>> — преждевременная пессимизация "всё и так будет работать" не менее вредна чем преждевременная оптимизация.
S>Убеди количественной оценкой вредности в среднем по больнице на сфероконических проектах.

Ага, "и так сойдёт"

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

Подробнее, какие именно гарантии, если компилер C# те самые гарантии не выдаёт. До кучи, отламывается пошаговая отладка — становится неюзабельной, а так же и другие инструменты. Например, автоматический рефакторинг сильно вряд ли сможет рефакторить твои наколеночные списки.

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

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

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

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

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

S>>Конечно. Ты только сейчас оговорился, что это бывает уместно, а ты лишь про те кейсы, где это неуместно.

I>Вот такое, как ты показал, уместно в основном при портировании с другого функционального языка. А вот C# имеет кучу собственных вещей, которые позволяют эффективно работать со списками в функциональном стиле.

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

I>>>Кроме того:
I>>> — на кой ляд изобретат велосипед в ЯП с другой парадигмой, где вообще всё построено на других принципах ?
S>>Что бы было чем воспользоваться, если, вдруг, понадобились принципы, отличные от безальтернативно предлагаемых в данном ЯП.

I>Ага, "на всякий случай"

I>Ага, "и так сойдёт"
Вполне ожидаемый уровень аргументации.

S>>Такое решение может давать гарантии, которых не может дать обычное решение.

I>Подробнее, какие именно гарантии, если компилер C# те самые гарантии не выдаёт.
Гарантии неизменяемости. С этим у компилера C# все не так плохо. Например, список, что я приводил, компилятор сломать не даст.
I>До кучи, отламывается пошаговая отладка — становится неюзабельной, а так же и другие инструменты.
Куда это пошаговая отладка отломалась? И почему она стала неюзабельной?
I> Например, автоматический рефакторинг сильно вряд ли сможет рефакторить твои наколеночные списков.
Какие проблемы с автоматическим рефакторингом?

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

I>Для персистентной модели в общем случае нужно гораздо больше, чем иммутабельные списки. Нужна вообще вся модель приложения персистентная, а следовательно, весь код который её использует, должен быть особенным.
Примерно таким же особенным, как код, использующий неизменяемые дотнетовские строки. Много ли твоих знакомых людей сломало голову о них?

I>Кроме того, если функционалист уходит, на его место надо внезапно искать нового функционалиста, да еще такого, что бы C# знал и умел на вышем уровне, что бы продраться через эти велосипеды. Тут уже звоночек и у ПМ, и у HR, и у заказчика.
Код, который я привел — навеян SICP-ом. Это вводный курс для программистов, рассчитанный на людей, которые к компу вообще не подходили ни разу. Замыкания там даются в первом семестре, если не ошибаюсь.
Звоночек у ПМ, HR и заказчиков должен взорваться от натуги, если они берут на C# программиста, не знакомого и не способного познакомиться с замыканием.

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

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

G>>Помоему все претензии к Microsoft и .NET\C# уже должны кончиться.

ARK>Ну, это только по-твоему. А, например, у меня претензий полно и сейчас — вместо относительно нормального ПО мелкософт стал выпускать дико раздутое, забагованное говнище, набитое троянами и телеметрией. В топку.
При чем тут .NET и C# ?

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

S>>>Конечно. Ты только сейчас оговорился, что это бывает уместно, а ты лишь про те кейсы, где это неуместно.

I>>Вот такое, как ты показал, уместно в основном при портировании с другого функционального языка. А вот C# имеет кучу собственных вещей, которые позволяют эффективно работать со списками в функциональном стиле.

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

Цитирую себя "К сожалению, именно такой код часто и пишут функционалисты и называют это "красиво". Я даже видел библиотеки всерьёз написаные в подобном стиле на C# и даже на JS "

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

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

I>>Ага, "на всякий случай"
I>>Ага, "и так сойдёт"
S>Вполне ожидаемый уровень аргументации.

Добавь сюда "уместно лишь для блога" Это сумма твоих высказываний.

I>> Например, автоматический рефакторинг сильно вряд ли сможет рефакторить твои наколеночные списков.
S>Какие проблемы с автоматическим рефакторингом?

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

I>>Для персистентной модели в общем случае нужно гораздо больше, чем иммутабельные списки. Нужна вообще вся модель приложения персистентная, а следовательно, весь код который её использует, должен быть особенным.
S>Примерно таким же особенным, как код, использующий неизменяемые дотнетовские строки. Много ли твоих знакомых людей сломало голову о них?

Если ты про IImmutableList, то это используется местечково. Я как то не встречал больших приложений, что бы вся модель была персистентая, обычно толко кое какие части.
Сможешь сходу представить, как будет выглядеть персистетный аналог DOM ? html dom, xml dom, etc dom и как будет выглядеть код вида "удалить элементы в поддереве по признаку xxx"? И далее, как будет выглядеть вызывающий код.

I>>Кроме того, если функционалист уходит, на его место надо внезапно искать нового функционалиста, да еще такого, что бы C# знал и умел на вышем уровне, что бы продраться через эти велосипеды. Тут уже звоночек и у ПМ, и у HR, и у заказчика.
S>Код, который я привел — навеян SICP-ом. Это вводный курс для программистов, рассчитанный на людей, которые к компу вообще не подходили ни разу. Замыкания там даются в первом семестре, если не ошибаюсь.

ОМГ! Что бы понимать твой код надо гораздо больше, чем замыкания. Нужно уметь все алгоритмы, которые только встретятся в проекте, перепилить на вот эту модель. В универах этому почти не учат.

S>Звоночек у ПМ, HR и заказчиков должен взорваться от натуги, если они берут на C# программиста, не знакомого и не способного познакомиться с замыканием.

Cостояние нынешнего рынка труда не в твою пользу. 80% задач на любом проекте — рутина, простые задачи. Потому и берут тех, что дешевле. А вот оставшие 20% нужно написать так, что бы эти более дешовые смогли понимать и майнтейнить.

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

I>К сожалению, это не так. Асимптотика таких списков как правило ниже плинтуса.
Ну, как раз со списками вроде всё не так уж и плохо.

I>И даже товарищ Крис Окасаки в своей известной книге указал, что для многих вещей он так и не смог найти решение хотя бы с внятной амортизированой оценкой.
Вещей здесь значит "структур". Ну да, как бы не всякую произвольно взятую mutable структуру можно переписать на immutable без потерь.
I>Это значит, что среднему разрботчику надо долбить эти вещи день и ночь, иначе в проде будет хаос. Реально средний разработчик такие структуры нынче сливает ниже плинтуса. Такое вот состояние рынка труда.
Если честно, то средний разработчик и mutable-структуру затруднится родить так, чтобы она работала одновременно быстро и корректно.
Все просто берут код из коробки, и втыкают в свой проект.
Вот, когда я начинал программировать, в типичных библиотеках никаких там Dictionary, или RBTree не шло. Дали тебе TList да TStringList — и всё, на танки, ентерпрайзить прод.
Структура "двоичное дерево" была тем, что перенабивали из книги г.Шилдта.

Так и тут — дадут ФП программисту структуру "список" — и поехали

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

G>>>Помоему все претензии к Microsoft и .NET\C# уже должны кончиться.

ARK>>Ну, это только по-твоему. А, например, у меня претензий полно и сейчас — вместо относительно нормального ПО мелкософт стал выпускать дико раздутое, забагованное говнище, набитое троянами и телеметрией. В топку.
G>При чем тут .NET и C# ?

Во-первых, см. выделенное. Во-вторых, студия и net core теперь тоже набиты троянами, а студия (впридачу к) превратилась в дикого монстра на 50 гигов, которого еще и в виде исошки нет.

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

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

I>Цитирую себя "К сожалению, именно такой код часто и пишут функционалисты и называют это "красиво". Я даже видел библиотеки всерьёз написаные в подобном стиле на C# и даже на JS "

I>Далее, ты начал защищать тех самый функционалистов а потом "уместно лишь для блога"

I>Определись уже, для блоги или уместно в продакше.

Конкретный мой код — и "библиотеки всерьёз написаные в подобном стиле".. Мы явно о разных вещах говорим.

I>>>Ага, "на всякий случай"
I>>>Ага, "и так сойдёт"
S>>Вполне ожидаемый уровень аргументации.

I>Добавь сюда "уместно лишь для блога" Это сумма твоих высказываний.
Одно из. Остальные ты не заметил на фоне этого.

I>>> Например, автоматический рефакторинг сильно вряд ли сможет рефакторить твои наколеночные списков.
S>>Какие проблемы с автоматическим рефакторингом?

I>Например, я хочу заменять цепочку эквивалентным кодом.
Странное требование к коду, ну да ладно. В продакшне список дополняется на раз двумя методами в/из IEnumerable. Если работа рефакторингом с IEnumerable тебя устраивает, то проблем не вижу более.

I>>>Для персистентной модели в общем случае нужно гораздо больше, чем иммутабельные списки. Нужна вообще вся модель приложения персистентная, а следовательно, весь код который её использует, должен быть особенным.
S>>Примерно таким же особенным, как код, использующий неизменяемые дотнетовские строки. Много ли твоих знакомых людей сломало голову о них?

I>Если ты про IImmutableList, то это используется местечково. Я как то не встречал больших приложений, что бы вся модель была персистентая, обычно толко кое какие части.
Определись, нужно или не нужно? Может быть достаточно местячково, там, где это действительно нужно?

I>Сможешь сходу представить, как будет выглядеть персистетный аналог DOM ? html dom, xml dom, etc dom и как будет выглядеть код вида "удалить элементы в поддереве по признаку xxx"? И далее, как будет выглядеть вызывающий код.
Код вида "удалить элементы в поддереве по признаку xxx" будет выглядеть не сложнее, чем фильтрация IEnumerable в Linq.

S>>Код, который я привел — навеян SICP-ом. Это вводный курс для программистов, рассчитанный на людей, которые к компу вообще не подходили ни разу. Замыкания там даются в первом семестре, если не ошибаюсь.

I>ОМГ! Что бы понимать твой код надо гораздо больше, чем замыкания. Нужно уметь все алгоритмы, которые только встретятся в проекте, перепилить на вот эту модель. В универах этому почти не учат.
В сикпе этот код понимают студенты, которые кроме факториала и метода Ньютона ничего не видели. Какие там еще все алгоритмы проекта, который они еще не писали?

S>>Звоночек у ПМ, HR и заказчиков должен взорваться от натуги, если они берут на C# программиста, не знакомого и не способного познакомиться с замыканием.

I>Cостояние нынешнего рынка труда не в твою пользу. 80% задач на любом проекте — рутина, простые задачи. Потому и берут тех, что дешевле. А вот оставшие 20% нужно написать так, что бы эти более дешовые смогли понимать и майнтейнить.

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

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

I>>И даже товарищ Крис Окасаки в своей известной книге указал, что для многих вещей он так и не смог найти решение хотя бы с внятной амортизированой оценкой.
S>Вещей здесь значит "структур". Ну да, как бы не всякую произвольно взятую mutable структуру можно переписать на immutable без потерь.

"Ну, как раз со списками вроде всё не так уж и плохо." @ Sinclair



S>Так и тут — дадут ФП программисту структуру "список" — и поехали

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

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

I>>Далее, ты начал защищать тех самый функционалистов а потом "уместно лишь для блога"
I>>Определись уже, для блоги или уместно в продакше.

S>Конкретный мой код — и "библиотеки всерьёз написаные в подобном стиле".. Мы явно о разных вещах говорим.

Ну да — в одном месте ты пишешь, что все в порядке и тут же добавляешь, что это всё только для блога

I>>Например, я хочу заменять цепочку эквивалентным кодом.
S>Странное требование к коду, ну да ладно. В продакшне список дополняется на раз двумя методами в/из IEnumerable. Если работа рефакторингом с IEnumerable тебя устраивает, то проблем не вижу более.

А зачем мне эта кунсткамера если у меня и так есть IEnumerable и там уже есть иммутабельная модель вычислений? Каким образом оценить профит ?
Аргумет "я так пишу и у меня классно" не катит. Нужна проверка временем и массами. Массы подхватили — значит это экономически состоятельно. Если нет — значит в топку.

I>>Если ты про IImmutableList, то это используется местечково. Я как то не встречал больших приложений, что бы вся модель была персистентая, обычно толко кое какие части.
S>Определись, нужно или не нужно? Может быть достаточно местячково, там, где это действительно нужно?

Если местечково, то хочется обоснования, почему это лучше IImmutableList и IEnumerable.

I>>Сможешь сходу представить, как будет выглядеть персистетный аналог DOM ? html dom, xml dom, etc dom и как будет выглядеть код вида "удалить элементы в поддереве по признаку xxx"? И далее, как будет выглядеть вызывающий код.
S>Код вида "удалить элементы в поддереве по признаку xxx" будет выглядеть не сложнее, чем фильтрация IEnumerable в Linq.

Фильтрация в линке простая за счет yield. В DOM тебе нужно гарантировать, что пересоздадутся все узлы выше уровнем. Они ведь тоже иммутабельные. И рут пересоздаётся. А теперь как быть с теми, кто удерживает ссылки на старые элементы ? Теперь такое удержание или ой-ой, или специальное решение нужно.
То есть, речь уже про вполне конкретную архитектуру решения а не только списки.

I>>ОМГ! Что бы понимать твой код надо гораздо больше, чем замыкания. Нужно уметь все алгоритмы, которые только встретятся в проекте, перепилить на вот эту модель. В универах этому почти не учат.
S>В сикпе этот код понимают студенты, которые кроме факториала и метода Ньютона ничего не видели. Какие там еще все алгоритмы проекта, который они еще не писали?

1 Факт #1 В обычных универах нет СИКП, там дают совсем другие вещи.
2 Факт #2 Сикп дается в самых продвинутых, где а. жосткий отбор б. лушчие преподаватели
3 Факт #3 Большинству людей на рынке труда до СИКП как до луны.

I>>Cостояние нынешнего рынка труда не в твою пользу. 80% задач на любом проекте — рутина, простые задачи. Потому и берут тех, что дешевле. А вот оставшие 20% нужно написать так, что бы эти более дешовые смогли понимать и майнтейнить.

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

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

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

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

S>>Конкретный мой код — и "библиотеки всерьёз написаные в подобном стиле".. Мы явно о разных вещах говорим.

I>Ну да — в одном месте ты пишешь, что все в порядке и тут же добавляешь, что это всё только для блога
Мой пример и подобное ему — для блога, т.к. это не библиотека. И нормально работать (с большими данными) это может лишь за счет стека, который ограничен, т.к. в C# до сих пор не завезли хвостовую оптимизацию. Обработать 4 сообщения в день в наколенной поделке — подойдет более чем. В продакшн коммерческого продукта совать это не предлагаю. Так понятно?
Однако, против серьезных библиотек ничего не имею. Особенно, если в них есть трамполайны.

S>>Странное требование к коду, ну да ладно. В продакшне список дополняется на раз двумя методами в/из IEnumerable. Если работа рефакторингом с IEnumerable тебя устраивает, то проблем не вижу более.

I>А зачем мне эта кунсткамера если у меня и так есть IEnumerable и там уже есть иммутабельная модель вычислений? Каким образом оценить профит ?
Зачем тебе — это ты решай. Я тебе это не навязываю.
I>Аргумет "я так пишу и у меня классно" не катит. Нужна проверка временем и массами. Массы подхватили — значит это экономически состоятельно. Если нет — значит в топку.
Для меня массы не аргумент. Своя голова есть. И массы ничего и никогда не подхватят, если в массах будут лишь те, кто апеллирует к проверке массами.

I>>>Если ты про IImmutableList, то это используется местечково. Я как то не встречал больших приложений, что бы вся модель была персистентая, обычно толко кое какие части.
S>>Определись, нужно или не нужно? Может быть достаточно местячково, там, где это действительно нужно?

I>Если местечково, то хочется обоснования, почему это лучше IImmutableList и IEnumerable.
Пост назад ты рассуждал об использовании IImmutableList, но теперь спрашиваешь меня, чем ЭТО лучше, чем IImmutableList. Потерял контекст? Бывает.

I>>>Сможешь сходу представить, как будет выглядеть персистетный аналог DOM ? html dom, xml dom, etc dom и как будет выглядеть код вида "удалить элементы в поддереве по признаку xxx"? И далее, как будет выглядеть вызывающий код.
S>>Код вида "удалить элементы в поддереве по признаку xxx" будет выглядеть не сложнее, чем фильтрация IEnumerable в Linq.

I>Фильтрация в линке простая за счет yield. В DOM тебе нужно гарантировать, что пересоздадутся все узлы выше уровнем. Они ведь тоже иммутабельные. И рут пересоздаётся.
Пересоздадутся не все узлы выше уровнем, а только лишь те, которые имеют прямую связь с измененными данными. Или мы по разному понимаем уровень узла. Обычно под уровнем узла подразумевают число переходов до рута. И пересоздавать требуется лишь те узлы, которые стоят на пути от рута к изменению.
I> А теперь как быть с теми, кто удерживает ссылки на старые элементы ? Теперь такое удержание или ой-ой, или специальное решение нужно.
Полагаю, если ты удерживаешь ссылку на неизменяемый элемент, который может устареть и никто тебе об этом не скажет, то ты знаешь, что и зачем делаешь. При желании отслеживать изменения в элементе нужен способ найти этот элемент в новой версии документа.
I>То есть, речь уже про вполне конкретную архитектуру решения а не только списки.
Неужели с git-ом не знаком?

S>>В сикпе этот код понимают студенты, которые кроме факториала и метода Ньютона ничего не видели. Какие там еще все алгоритмы проекта, который они еще не писали?

I>1 Факт #1 В обычных универах нет СИКП, там дают совсем другие вещи.
Очень жаль, но это так.
I>2 Факт #2 Сикп дается в самых продвинутых, где а. жосткий отбор б. лушчие преподаватели
Сикп не преподается нигде. В программе MIT его уже нет много лет.
I>3 Факт #3 Большинству людей на рынке труда до СИКП как до луны.
Это не отменяет того, что материал Сикп преподавался далеким от IT людям с первого семестра. И большинство меня беспокоит лишь тем, что оказывает влияние на детей, которые на них ориентируются.

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

I>Ну вот ты слился на понты То есть, твои утверждения про студентов и замыкания можно игнорировать как несостоятельные, раз ты перешел к такой тактике.
Я лишь еще раз обозначил уровень моего восприятия твоей аргументации про большинство на рынке. И слегка включил тролля, что бы наверняка проняло.
Собственно, мои утверждения о студентах и замыканиях — это факты, которые очень легко проверить. Но да, тебе можно их игнорировать. Не могу же запретить. И продолжай апелляции к большинству. Очень интересно и поднимает мотивацию делать что-то не как большинство.

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

S>Мой пример и подобное ему — для блога, т.к. это не библиотека. И нормально работать (с большими данными) это может лишь за счет стека, который ограничен, т.к. в C# до сих пор не завезли хвостовую оптимизацию. Обработать 4 сообщения в день в наколенной поделке — подойдет более чем. В продакшн коммерческого продукта совать это не предлагаю. Так понятно?

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

I>>Аргумет "я так пишу и у меня классно" не катит. Нужна проверка временем и массами. Массы подхватили — значит это экономически состоятельно. Если нет — значит в топку.
S>Для меня массы не аргумент. Своя голова есть. И массы ничего и никогда не подхватят, если в массах будут лишь те, кто апеллирует к проверке массами.

Все ровно наоборот. Массы подхватывают вещи полезные для насущных задач безо всякой внешней помощи. С функциональщиной все сложнее — большей частью евангелисты рассказывают абстрактные вещи типа персистетность, списки, система типов и тд. От такого как правило сначала глаза на лоб лезут а потом в сон клонит. Типичное выступление — половина людей спит, другая половина втыкает в телефон. Очевидно, что при этом целая куча функциональных фремворков-языков сдохли и продолжают появляться и так же быстро дохнуть.
И вот странно — разработка на JavaScript гораздо сильнее напичкана функциональщиной, нежели C#, Java и подобные вещи. То есть, в общем случае массы подхватывают. И происходит это естественным образом.

I>>Если местечково, то хочется обоснования, почему это лучше IImmutableList и IEnumerable.
S>Пост назад ты рассуждал об использовании IImmutableList, но теперь спрашиваешь меня, чем ЭТО лучше, чем IImmutableList. Потерял контекст? Бывает.

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

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

I>>Фильтрация в линке простая за счет yield. В DOM тебе нужно гарантировать, что пересоздадутся все узлы выше уровнем. Они ведь тоже иммутабельные. И рут пересоздаётся.
S>Пересоздадутся не все узлы выше уровнем, а только лишь те, которые имеют прямую связь с измененными данными. Или мы по разному понимаем уровень узла. Обычно под уровнем узла подразумевают число переходов до рута. И пересоздавать требуется лишь те узлы, которые стоят на пути от рута к изменению.

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

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

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

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

I>>То есть, речь уже про вполне конкретную архитектуру решения а не только списки.
S>Неужели с git-ом не знаком?

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

I>>2 Факт #2 Сикп дается в самых продвинутых, где а. жосткий отбор б. лушчие преподаватели
S>Сикп не преподается нигде. В программе MIT его уже нет много лет.

МИТ это университет, где появился такой курс. Но с чего ты взял, что СИКП преподавался только там ?
Сикп до сих пор в строю, но не в МИТ. Но, конечно, сбавил популярности, после того как МИТ отказался от него.

Кстати говоря, в Стенфорде уход от СИКП был обоснован тем, что он "мистифицирует виртуальную машину". И это факт.

I>>3 Факт #3 Большинству людей на рынке труда до СИКП как до луны.
S>Это не отменяет того, что материал Сикп преподавался далеким от IT людям с первого семестра. И большинство меня беспокоит лишь тем, что оказывает влияние на детей, которые на них ориентируются.

Для справки — для далеких от ИТ людей даже в МИТ был предусмотрен вспомогательный курс, необязательный, который студенты могли брать перед этим самым СИКП. Там писали на питоне. Задания уровня первого курса сравнивая с вузами бывшего СССР.

Собственно, это демонстрирует уровень студентов в МИТ — там очень неслабые студенты. Мягко говоря.

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

I>>Ну вот ты слился на понты То есть, твои утверждения про студентов и замыкания можно игнорировать как несостоятельные, раз ты перешел к такой тактике.
S>Я лишь еще раз обозначил уровень моего восприятия твоей аргументации про большинство на рынке. И слегка включил тролля, что бы наверняка проняло.

А я вижу, что а) аргументы закончились и б) ты основываешься на ложных фактах.

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

В том то и дело, что твои факты проверку не проходят. Это я сужу а) по собеседованиям в странах бывшего СССР, включая Россию и б) мой собственный опыт преподавания/менторинга/супервайзинга а также в) общение с другими интервьюерами из разных стран.
Ситуация примерно одинаковая вне зависимости от стека технологий — .Net, Java, JS, Ruby и тд. Единственное исключение — всякие С++ и Erlang как то выделяются из общей массы. Сам факт вхождения в эти технологии говорит о наличии серьёзной квалификации. Т.е. не С++ и Erlang делают крутым, а крутым под силу даже C++ и Erlang. За Хаскель не могу сказать, за всё время только один кандидат, и тот неубедительно собеседовался на Питон с какого то бодуна

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

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

S>Сикп не преподается нигде. В программе MIT его уже нет много лет.

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

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

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

S>>Мой пример и подобное ему — для блога, т.к. это не библиотека. И нормально работать (с большими данными) это может лишь за счет стека, который ограничен, т.к. в C# до сих пор не завезли хвостовую оптимизацию. Обработать 4 сообщения в день в наколенной поделке — подойдет более чем. В продакшн коммерческого продукта совать это не предлагаю. Так понятно?

I>Какой смысл тащить такое в приложение, где ажно 4 сообщения в день? Почему нельзя сделать проще?
Что может быть проще односвязного списка? List<T> что ли?

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

I>С функциональщиной все сложнее — большей частью евангелисты рассказывают абстрактные вещи типа персистетность, списки, система типов и тд. От такого как правило сначала глаза на лоб лезут а потом в сон клонит. Типичное выступление — половина людей спит, другая половина втыкает в телефон. Очевидно, что при этом целая куча функциональных фремворков-языков сдохли и продолжают появляться и так же быстро дохнуть.
А сколько спят на ОО-семинарах и сколько сдохло ОО фреймворков не пробовал считать?
I>И вот странно — разработка на JavaScript гораздо сильнее напичкана функциональщиной, нежели C#, Java и подобные вещи. То есть, в общем случае массы подхватывают. И происходит это естественным образом.
Т.е. отрицать динамику процесса ты не собираешься? Если подхватывают — значит, подхватят. ОО тоже не за 10 лет подхватили.

I>>>Если местечково, то хочется обоснования, почему это лучше IImmutableList и IEnumerable.
S>>Пост назад ты рассуждал об использовании IImmutableList, но теперь спрашиваешь меня, чем ЭТО лучше, чем IImmutableList. Потерял контекст? Бывает.

I>Ну так твоей оценки эффективности не поступало Ты говоришь, что персистентность это полезно, но не говоришь, ради чего стараться то
Говорил, не раз. Расшифрую. Гарантии отсутствия изменений — бесплатная атомарность изменений и консистентность данных. Нет нужды откатывать наполовину переведенную в новое состояние модель. Все само. CAS-update уровня модели, если хочешь.

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

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

I>Это очевидно. Именно это и вносит сложность, т.к. в мутабельной модели нам не надо заниматься такими вещами. Чем больше модель, чем больше связей, — тем больше таких вот новых инстансов. Соответсвенно, всё это приводит к структуре навроде реляционной, где унутре нет никаких прямых ссылок на разделяемые объекты. Тогда нет необходимости пересоздавать большую часть объектов. Но реляционная структура вводит дополнительную сложность на обходы, выборки, фильтрации, удаление, оповещение и тд.
Я не понимаю, с чем связаны твои сложности. Если тебе нужно удалить что-то из дерева модели, то без ссылки на это нечто тебе придется его найти по некому признаку. И поиск в такой модели ничем не сложнее чем в мутабельной. Это касается обходов, выборок и фильтраций. Ничего отличного от мутабельной модели тут нет.
Если ты нашел то, что тебе нужно удалить — ты знаешь, где оно, у тебя есть зиппер. Это такой клубок нити в руке, по которому можно выйти из лабиринта, если ты умудрился привязать конец нити у входа в лабиринт. Вдоль этого зиппера модель и обновится. Ничего более не потребуется менять. Нотификация по идентификатору.
Тебе это сложно не потому, что это сложно, а потому, что ты так не делал и рубил всегда мутабельную модель с деструктивными изменениями. Стоит потребовать от твоей модели возможность неограниченного отката изменений и ты сам придешь к персистентной модели.

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

I>Вот этот способ и должен быть частью решения. Без этого будет чемодан без ручки — нести тяжело, а бросить неприемлемо. Здесь у тебя появляется кеширование-мемоизация, т.к. частоиспользуемые трудновычисляемые свойства надо где то хранить. Очевидно — модифицировать всю модель в своём уме на каждый чих никто в своем уме не будет. Или вызывающей код будет обкладываться костылями, или придется сделать это частью решения.
Кэширование-мемоизация появляется и в деструктивных структурах. Вопросы о том, где хранить трудновычисляемые свойства, не характерны для одних лишь персистентных моделей.

I>То есть, все присваивания остаются, только прячутся под капот. Часть — туда, где хранится рут, часть — в мемоизацию. И теперь любой разработчик обязан вкурить вообще все, если хочет модифицировать хоть что нибудь. С мутабельной моделью все проще — изучаешь только, что непосредственно перед тобой и этого хватает для большинства задач.
Все присваивания остаются? Что ты под этим подразумеваешь?

S>>Неужели с git-ом не знаком?

I>Это понты или недостаток внимания ? Я, слову, представляю решение задачи, т.к. сам же его реализовал. И это решение даже в упрощенном виде гораздо сложнее обычной мутабельной реализации, т.к. одно из условий такого DOM это быстродействие и потребление памяти.
Это твое решение. Полагаю, оно может отличаться от того, что характерно для ФП.

I>Мутабельный DOM навроде того, что в браузере, студент пишет от силы за рабочий день вместе с парсингом. Я обычно даю такое задание тем, кто приходит ко мне на стажировку. Задачка на которой с нуля изучают JS имея в запасе хорошо если первый курс университета. А вот приседания с иммутабельной моделью даются гораздо позже, когда сам студент реально может прочувствовать, сравнить и замерить профит, а не просто следовать мантрам авторитетов.
Это вопрос того, где как дают. В SICP-е приседания с мутабельной моделью даются гораздо позже иммутабельной. И они сложнее, эти приседания.

S>>Сикп не преподается нигде. В программе MIT его уже нет много лет.

I> МИТ это университет, где появился такой курс. Но с чего ты взял, что СИКП преподавался только там ?
Откуда взял? Не знаю, мне так казалось.
I>Сикп до сих пор в строю, но не в МИТ. Но, конечно, сбавил популярности, после того как МИТ отказался от него.
Просто скажи, где его еще преподают? Достаточно одного примера.

I>Кстати говоря, в Стенфорде уход от СИКП был обоснован тем, что он "мистифицирует виртуальную машину". И это факт.
И о чем нам говорит этот факт?

S>>Это не отменяет того, что материал Сикп преподавался далеким от IT людям с первого семестра. И большинство меня беспокоит лишь тем, что оказывает влияние на детей, которые на них ориентируются.

I>Для справки — для далеких от ИТ людей даже в МИТ был предусмотрен вспомогательный курс, необязательный, который студенты могли брать перед этим самым СИКП. Там писали на питоне. Задания уровня первого курса сравнивая с вузами бывшего СССР.
Да, был вспомогательный. Для сравнения в бывшем СССР я два года в ВУЗ-е изучал турбопаскаль тетрадный. От реального он отличался тем, что точки с запятой ставить не нужно было вовсе. За них мне снизили оценку и я два года не ходил на программирование. Если бы мне дали сикп за эти два года, я был бы счастлив. А после тетрадного паскаля было 2 года ООП, где нам рассказывали про китов и vtbl. Два года, Карл! Одновременно с ООП начался двухлетний курс дискретной оптимизации. 4 года на то, что бы начать писать поиск в графе. Я чувствовал себя дебилом.

I>Собственно, это демонстрирует уровень студентов в МИТ — там очень неслабые студенты. Мягко говоря.
Для чего неслабые? Для метода Ньютона? Для замыканий? На каком курсе это надо давать "нашим" студентам?

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

I>А я вижу, что а) аргументы закончились и б) ты основываешься на ложных фактах.
Возникает ощущение, что мы говорим о разных вещах. И в прошлом тоже.
Да, в MIT-е учатся сильные студенты. В МГУ сильно слабже? Уверен, что нет. У меня племянник после двух лет ВМК МГУ в программировании такое дерево, каких поискать (не структура данных). Его препод — тоже, судя по пересказам. Я пытался племяша научить писать new в C++ для выделения памяти. Но там все и так работало, т.к. присваивание выполнялось через указатель по адресу, заполненному мусором (Borland не проверял это в рантайме). Один зачет сдал, другой — принял. Так ладно бы ошибка — он настаивал что new писать не надо в ответ на мое офигевание!

I>В том то и дело, что твои факты проверку не проходят. Это я сужу а) по собеседованиям в странах бывшего СССР, включая Россию и б) мой собственный опыт преподавания/менторинга/супервайзинга а также в) общение с другими интервьюерами из разных стран.
I>Ситуация примерно одинаковая вне зависимости от стека технологий — .Net, Java, JS, Ruby и тд. Единственное исключение — всякие С++ и Erlang как то выделяются из общей массы. Сам факт вхождения в эти технологии говорит о наличии серьёзной квалификации. Т.е. не С++ и Erlang делают крутым, а крутым под силу даже C++ и Erlang. За Хаскель не могу сказать, за всё время только один кандидат, и тот неубедительно собеседовался на Питон с какого то бодуна
Мало что понял. Повторять не надо.

I>Итого — замыкания есть ничтожная вещь, мелкий винтик. Для алгоритмов требуется намного больше. Например — минимум семестр по структурам данных на специальности уровня "Прикладная математика". Реально — намного больше.
Вот здесь я с тобой соглашусь целиком и полностью. Замыкания — ничтожная вещь. Владение ими не дает автоматом владение алгоритмами и даже скромной их частью.
Односвязный список — лишь простейшая структура данных. Гораздо проще, чем два байта переставить местами и "x = x + 1", которое даже моя школьная математичка с двумя высшими образованиями по математике не смогла осилить.

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

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

S>Говорят на питон перешли, но я ничего вменяемого найти не смог, т.е. нормальный курс, а не обрывки.
Я тоже читал что сделали упор в робототехнику, а на питоне куча библиотек под это дело. Что бы не писать свое, заменили курс.

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

S>>Говорят на питон перешли, но я ничего вменяемого найти не смог, т.е. нормальный курс, а не обрывки.
S>Я тоже читал что сделали упор в робототехнику, а на питоне куча библиотек под это дело. Что бы не писать свое, заменили курс.

Так есть сикп на питоне или нет, что сейчас вместо?

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

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

S>Так есть сикп на питоне или нет, что сейчас вместо?
Что сейчас не знаю, но меняли сикп на курс питона с уклоном в робототехнику.

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

I>>Какой смысл тащить такое в приложение, где ажно 4 сообщения в день? Почему нельзя сделать проще?
S>Что может быть проще односвязного списка? List<T> что ли?

Односвязный список — сложная структура, нужно долго вдуплять все операции на ней. А вот массив — тривиальная, её можно объяснить в детском саду на шкафчиках или тумбочках. Т.е. разница в том, каким путём человек осваивает структуры данных.
Собственно, мне отец в детском саду про массив и объяснил

I>>Все ровно наоборот. Массы подхватывают вещи полезные для насущных задач безо всякой внешней помощи.
S>Лишь потому, что в массах есть люди, готовые подхватывать вещи, не оглядываясь на остальную массу. Об этом я и пытался тебе сказать.

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

I>>И вот странно — разработка на JavaScript гораздо сильнее напичкана функциональщиной, нежели C#, Java и подобные вещи. То есть, в общем случае массы подхватывают. И происходит это естественным образом.
S>Т.е. отрицать динамику процесса ты не собираешься? Если подхватывают — значит, подхватят. ОО тоже не за 10 лет подхватили.

Я вобщем показываю, что все не так, как ты это хочешь представить.

I>>Ну так твоей оценки эффективности не поступало Ты говоришь, что персистентность это полезно, но не говоришь, ради чего стараться то
S>Говорил, не раз. Расшифрую. Гарантии отсутствия изменений — бесплатная атомарность изменений и консистентность данных. Нет нужды откатывать наполовину переведенную в новое состояние модель. Все само. CAS-update уровня модели, если хочешь.

Сколько это в процентах к продуктивности, эффективности? Не в десятки раз, и даже не в разы

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

В этом и проблема, что ты весь профит приписываешь функциональщине. Судя по функциональщине, ты намного сильнее, чем ~99% контингента на рынке труда, это навскидку. Только из того, что ты функционалист. Не радикальный, но тем не менее функционалист. Таких примерно 1 на 100 человек.
Приближенная модель, но достаточно адекватная для нынешних реалий.

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

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

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

Обход такой же, удаление и любое изменение сложнее.

S>Если ты нашел то, что тебе нужно удалить — ты знаешь, где оно, у тебя есть зиппер. Это такой клубок нити в руке, по которому можно выйти из лабиринта, если ты умудрился привязать конец нити у входа в лабиринт. Вдоль этого зиппера модель и обновится. Ничего более не потребуется менять. Нотификация по идентификатору.

Спасибо, капитан! А зачем мне заниматься такими вещами в мутабельной модели, где изменение делается одним присваиванием?

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

Я знаю, как выглядят оба вариантами. Как то так

S>Кэширование-мемоизация появляется и в деструктивных структурах. Вопросы о том, где хранить трудновычисляемые свойства, не характерны для одних лишь персистентных моделей.

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

S>Все присваивания остаются? Что ты под этим подразумеваешь?

Мемоизация та же.

I>>Это понты или недостаток внимания ? Я, слову, представляю решение задачи, т.к. сам же его реализовал. И это решение даже в упрощенном виде гораздо сложнее обычной мутабельной реализации, т.к. одно из условий такого DOM это быстродействие и потребление памяти.
S>Это твое решение. Полагаю, оно может отличаться от того, что характерно для ФП.

Я его не придумывал, а взял готовый подход

S>Это вопрос того, где как дают. В SICP-е приседания с мутабельной моделью даются гораздо позже иммутабельной. И они сложнее, эти приседания.

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

I>> МИТ это университет, где появился такой курс. Но с чего ты взял, что СИКП преподавался только там ?
S>Откуда взял? Не знаю, мне так казалось.

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

I>>Сикп до сих пор в строю, но не в МИТ. Но, конечно, сбавил популярности, после того как МИТ отказался от него.
S>Просто скажи, где его еще преподают? Достаточно одного примера.

Список устаревший. Раньше у меня были более конкретные ссылки.
https://mitpress.mit.edu/sites/default/files/sicp/adopt-list.html

I>>Кстати говоря, в Стенфорде уход от СИКП был обоснован тем, что он "мистифицирует виртуальную машину". И это факт.
S>И о чем нам говорит этот факт?

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

I>>Для справки — для далеких от ИТ людей даже в МИТ был предусмотрен вспомогательный курс, необязательный, который студенты могли брать перед этим самым СИКП. Там писали на питоне. Задания уровня первого курса сравнивая с вузами бывшего СССР.
S>Да, был вспомогательный. Для сравнения в бывшем СССР я два года в ВУЗ-е изучал турбопаскаль тетрадный. От реального он отличался тем, что точки с запятой ставить не нужно было вовсе. За них мне снизили оценку и я два года не ходил на программирование. Если бы мне дали сикп

А толку смотреть на единичный пример?

I>>Собственно, это демонстрирует уровень студентов в МИТ — там очень неслабые студенты. Мягко говоря.
S>Для чего неслабые? Для метода Ньютона? Для замыканий? На каком курсе это надо давать "нашим" студентам?

В зависимости от вуза разница от первого курса до год-два после выпуска. Тех, где можно сразу давать такое, пару штук всего. И они погоды не делают. Даже в таких вузах часто бывает пол-группы просто ходят на занятия шоб оценку получить. В МИТ эта проблема решается кардинально — слабо-мотивированых отфильтровывают заранее.

S>Да, в MIT-е учатся сильные студенты. В МГУ сильно слабже? Уверен, что нет.

Отбор разный. Даже на самых свирепых специальностях можно нарваться на поток, где половина просто ходит, потому что папа с мамой заставляют.
Сильные студенты из МГУ вероятно сравнимы с МИТ. Но вот слабые примерно одинаково дохлые независимо от вуза. Такая вот нынче картина. В МИТ в силу разного отбора попадают скорее те, что сильнее мотивированы, но могут кое чего не знать.

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

S>Мало что понял. Повторять не надо.

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

S>Односвязный список — лишь простейшая структура данных. Гораздо проще, чем два байта переставить местами и "x = x + 1", которое даже моя школьная математичка с двумя высшими образованиями по математике не смогла осилить.

Да не простейшая Массив легко объяснить, т.к. пример шкафчика у всех перед глазами. А вот cons списки вещь нетривиальная, это ведь абстракция, раскрывается на операциях, а не просто так, картинкой.
Кстати, математичке надо было пример привести, скажем, "как поменять содержимое двух ведер" Присваивание сразу начинает получаться

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

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

S>>>Говорят на питон перешли, но я ничего вменяемого найти не смог, т.е. нормальный курс, а не обрывки.
S>>Я тоже читал что сделали упор в робототехнику, а на питоне куча библиотек под это дело. Что бы не писать свое, заменили курс.

S>Так есть сикп на питоне или нет, что сейчас вместо?

СИКП это одновременно и курс, и книга. Язык — Scheme. МИТ от него отказался в пользу курса на питоне для робототехники. кое какие вещи заимствованы.