В Raku ведётся работа над иммутабельностью

Из многобукв не совсем уловил: так хотят все данные сделать иммутабельными или оставить мутабельные с обязательным идентификатором (var, mut)?

А чё в перле констант нету?

Там написано persistent, для тебя это иммутабельные? Тупой лор

What even is immutability? The biggest selling point of persistent data structures is, of course, that they are immutable while also being fairly cheap to copy. But to deliver on that promise, it’s important to have a very clear idea of what we mean by «immutability».

Видимо, это имеется ввиду.

У всех людей persistent data structure — это структура, сохраняющая свои предыдущие состояния перед модификацией. Например, списки по отношению к cons.

А. Ну тогда я ещё меньше понял.

ТС, где выжимка для деби… тех, кому лень читать!?

Теперь будут копировать строки на каждый чих и конкатенацию плюсиком через точку через ж... тильду объявят «антипаттерном», чтоб конкатенировать максимально через жеппу, которая вызвана... эээ... иммутабельностью? Где-то мы это видели :)))

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

Пока там нет твёрдого понимания чего и как будет работать. Просто работы ведутся.

Странно звучит. Ладно, подожду новости, когда это в релиз войдёт.

Популярно об иммутабельности.

Но если туп, как дерево, — родишься баобабом
И будешь баобабом тыщу лет, пока помрёшь.

А зависимые типы туда завезут?

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

Теперь оно будет жрать не гиги памяти а терабайты?

Проблема такого подхода заключается в том, что получаемые многозадачные программы будут абсолютно не похожи на обычный перловый код. По этой причине для питона я делал транзакционную память на двухверсионных изменяемых структурах, но вот в чем беда — они точно так же никому не нужны, как персистентные структуры данных. Ну то есть пару челиков откликнулось, но это сильно меньше, чем миллионы макак, полубессознательно пишущих код на питоне за деньги на регулярной основе. Более того, на никому не нужном языке реализовать эту фичу проще, чем на активно используемом, поскольку в перле костылей нужно намного меньше, чем в питоне, который сверху-донизу увешан всякими NumPy, PyTorch, TensorFlow, Pandas, и прочими сишно-крестовыми костылями, которые каждый по сути создают свой собственный язык программирования, поскольку базовый питон несостоятелен.

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

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

Это не проблема. Хочешь - пиши как раньше, а хочешь - используй новые структуры. Замечательно сочетается с TIMTOWTDI. А вот как в Python можно тащить сопоставление с образцом или такие вот штуки - я хз. Этож противоречие идеологии языка. Мне со стороны кажется так: раньше был питон и его губительный дзен. Но дзен был и за ПОЗИЦИЮ питон можно было уважать. Сейчас у этого языка не остаётся костяка. Он расплывается в угоду сиюминутным порывам очередного стада макак.

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

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

Настрочил МНОГО БУКВ, но не стал публиковать.

Кратко «как у меня» /у меня объекты и поля могут иметь свойства/.

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

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

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

В 1С например, предусмотрена возможность ведения «истории» значений полей /раньше у них было понятие «периодический реквизит»/ …

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

Может быть и так …

Для меня проблема N1 не язык программирования, а его экосистема.
В каждом из них она своя, да еще с своими нюансами …

Был бы какой-то унифицированный API /да и синтаксис/, то был бы

ДРУГОЙ КОМПОТ

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

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

Хочешь - пиши как раньше, а хочешь - используй новые структуры. Замечательно сочетается с TIMTOWTDI

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

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

Не понимаю, о чем ты.

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

Лично у меня, как у человека, знакомого с функциональщиной и немного с макросами кложи, возникает оценка «челы просто притащили в язык все парадигмы. которые нашли в книжках». И это очень плохо, потому что качество ЯП определяется его простотой при равных возможностях, а не тупым числом фич.

Для меня проблема N1 не язык программирования, а его экосистема.

В каждом из них она своя, да еще с своими нюансами

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

Кстати, дельный подход. Чел описал, что сделает, и сколько денег просит. Вот все бы так. А то иные разведут туман, что типа донатьте, если хотите, а вообще мы бабло на благотворительность пустим, и никто вам ничего не обещал.

Может быть и так …

Ностальжи

В 1812 году использовал Foxpro 2.6, а он с строками не умел эффективно работать /Foxpro работал в DOSEMU и очень шустро/.

Что сделал?

«Подружил» Foxpro с Perl.
Для Perl реализовал 100% API Foxpro 2.6 для работы с строками.
Поэтому модуль в Perl на вид был как программа на Foxpro.
И все отчеты стали формироваться супер быстро /правда отчеты разрабатывались не в ручную, а с помощью своего визуального reporting/.
Отчет на 2000 расчетных листков формировался Раз, а на Два уже все Ok!

Как то так

Ныне разработку API веду лишь на Си и C++, прикидывающимся, что он Си.
Потому, что функциональность на порядки лучше, да и работает все шустро …

ЭТО НЕ НАЕЗД НА Perl, а НАСТОЛЬЖИ

Perl-у РЕСПЕКТ!

Кстати, дельный подход. Чел описал, что сделает, и сколько денег просит. Вот все бы так. А то иные разведут туман, что типа донатьте, если хотите, а вообще мы бабло на благотворительность пустим, и никто вам ничего не обещал

Скажем так: чел попросил денег на вполне конкретное «ненужно» с предсказуемыми свойствами и сроками выполнения. Что сообщество до сих пор не поняло, что же на самом деле этот чел предлагает (и при этом уже дало гранты) — это меня уже не особо колышет. Меня колышет то, что если я попрошу денег на PSO, то первый вопрос встанет — а что именно делать. Причем, я попрошу примерно в полтора-два раза меньше, чем он. Просить деньги на абстрактное стартапное «нечто» намного удобнее, чем пытаться сделать что-то полезное и верифицируемое (то есть, очевидно бесполезное, а не «может быть когда-то пригодится») для интенсивно используемого решения, как то питон. PEP 554 уже пятый год ковыряют, а релизнуть не могут, несмотря на внимание сообщества и кучу волонтеров. Вот это и есть разница между прикладным проектом и теоретически-исследовательским. И я уже жалею, что попытался сделать что-то практически применимое, а не выпрашивать гранты на очередные STM-монады под хаскель.

Причем, я попрошу примерно в полтора-два раза меньше, чем он.

Шутка

Хорошими дееелами, прослаааавиться нельзя ...

Просто не умеешь себя пиарить, а он умеет.

Шикарно.

Просто не умеешь себя пиарить, а он умеет

Ну блин, я привлек какое-то внимание. Но когда ты выдаешь верифицируемое решение, то его малополезность более очевидна, чем непонятно что плана «мы сделаем самый великий язык на планете». Первое, что спрашивают люди, чье внимание мне удалось заполучить — «а оно с NumPy умеет работать?». А я прекрасно понимаю, что поддержка NumPy по сути значит переработка всего NumPy, поскольку NumPy изначально сделано как совершенно иной язык, плохо совместимый с любым другим питоньим решением, кроме тех, которые уже спроектированы специально под NumPy.

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

Так про нумпи вопрос разумный. Людям нужОн нумпи, а теоретические эксперименты вокруг питона не нужны.

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

Так, погоди-ка… Дядьке дали 7 килобачей на доработку, а тебе нет и при этом «ненужно» относится к его работе? Интересная логика.

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

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

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

Дядьке дали 7 килобачей на доработку, а тебе нет и при этом «ненужно» относится к его работе? Интересная логика

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

Если ты еще не понял — сами по себе персистентные структуры никому не нужны, они, как правило, являются вспомогательным инструментом для механизмов асинхронности и многопоточности. Наивная прямолинейная реализация многозадачности опускает твой уровень абстракций на уровень C++, то есть, периодически код будет виснуть, портить данные, и изредка даже падать. Потому что тебе нужны изменяемые данные, не важно на персистентных или неперсистентных структурах, их нужно как-то координировать, вроде STM, блокировок, акторов, каналов. Да, в Raku есть каналы — то есть, это по сути подражание Go. Особенно если учесть, что также присутствует Proc::Async, оно же «go routine». Каналы, мягко говоря, не являются панацеей и не спасают от дедлоков. Всё, STM нет, блокировки примитивнейшие, есть промисы, которые слишком примитивны, чтобы сами по себе служили надежным базисом для чего-то большего, и широковещательные Supplies (карго-культ на ReactiveX), которые хоть и не низкоуровневы, но я не вижу особого преимущества над обычными промисами для средней проги в вакууме, особенно учитывая то, насколько тяжело отлаживать асинхронный код на промисах/ReactiveX.

Я уже достаточно наигрался с персистентными структурами в Elixir’е и знаю что это такое. Недавно в Raku переписали механизм диспетчеризации, не думаю что запил иммутабельности более сложная задача. Просто так тэнге дядьке никто бы не давал. Там не дураки сидят.

Перл 5.30 напомнить у кого собрался , а паразитики ?

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

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

Я уже достаточно наигрался с персистентными структурами в Elixir’е и знаю что это такое. Недавно в Raku переписали механизм диспетчеризации, не думаю что запил иммутабельности более сложная задача

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

Ты только километровые простыни на лоре можешь соченять.

Ты только километровые простыни на лоре можешь соченять

Ну почему на лоре... на хабре еще.

byko3y 8 ноября в 07:38

https://habr.com/ru/post/587750/ Многозадачность и многопоточность — распространенные заблуждения и недопонимания

Нормас статья. Для веб макак пойдет. Им и не такое пойдет.

На самом деле основная проблема — это отсутствие переиспользуемых алгоритмов. Проблема в том, что все они — говно и делались под машину Тьюринга.

Для дискуссии.

https://ru.wikipedia.org/wiki/POSIX помогает унифицировать API для работы с разными ОС в части

Разделы стандарта
Планировка приоритетов[5]
Сигналы реального времени[10]
Часы и таймеры[5]
Семафоры[5]
Передача сообщений[5]
Управление памятью[a][5]
Синхронизация файлов и асинхронный ввод-вывод[5]
Интерфейс блокировки виртуальной памяти[10]

Что касаемого остального API, то «кто во что горазд».
Поэтому трудоемко использовать разные языки программирования.
Зачастую в проектах используются xml, json, …
Для каждого языка программирования создают тьму binding такого рода API …

Шутка

Если кто-то бы осмелился разгрести эти «Авгеевы конюшни» и разработал единое ГУМНО, то как в песне

Жить стало бы легче, стало веселей ...

Sorry «Авгиевы конюшни» /давненько в них не заглядывал/

чего только люди не сделают, лишь бы Clojure не использовать