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

https://www.perlmonks.org/?node=663393

Как назвать пакет, организующий совместимость со свежим time (1.9), если time-compat уже забито?

time-adapter

https://www.perlmonks.org/?node=663393

А с чего ты взял, что парсер обязан тоталится?

Точнее с чего это взял автор текста

Как назвать пакет, организующий совместимость со свежим time (1.9), если time-compat уже забито?

chronо̄convenientiæ

Не люблю латынь

А эта ещё с греческими заимствованиями

глубинность концепции фп раскрыта

А с чего ты взял, что парсер обязан тоталится?

А там не с тотальностью проблемы, там с детерминированностью проблемы

Норм (нет)

yatc

https://www.perlmonks.org/?node=663393

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

Как назвать пакет, организующий совместимость со свежим time (1.9), если time-compat уже забито?

just-about-time

Ну короче он берёт строчку, которая в зависимости от контекста либо представляет собой деление a / b, а дальше идёт комментарий, либо выполнение функции, а затем вызов die. И ожидает, что парсер однозначно разрулит ситуацию, исходя из контекста

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

как IO может не быть монадой? чушь какая-то. мы же говорим «числа являются группой по сложению»

мы так не говорим, я говорю "числа _образуют_ группу по сложению", а не "являются"

но ведь пирожок не образует еду

instance Iso Int String where type To Int = String type From String = Int

ладно, мне не удалось доказать ту фигню, которую хотел @A64m_qb0, ну и плевать

но ведь пирожок не образует еду

это подмена понятий

это подмена понятий

какого на какое?

Просто многие люди (особенно программисты) отношение общего и единичного путают с отношением предмета и предиката

@int_index в обоих случаях отношение "is-a", оно же принадлежность множеству, оно же обладание свойством

Пирожок образует тестовую оболочку над начинкой!

Пирожок образует тестовую оболочку над начинкой!

выпуклую?

Хватит уже, прямо как на экзамен по философии в пту попал

Просто многие люди (особенно программисты) отношение общего и единичного путают с отношением предмета и предиката

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

какого на какое?

Множество объектов классифицируемых как пирожки это подмножество объектов классифицируемых как еда. "Пирожок - еда" говорит о том, что одно множество входит в другое. "Числа образуют группу по сложению" это совсем другой случай, тут мы говорим, что элементами тьюпла (G, •) мы можем в качестве G взять числа и в качестве • сложение

А вот обосновать чем эти ситуации хоть немного похожи мне бы интересно послушать. Я не вижу аналогии.

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

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

Коллеги, прлсветите, пожалуйста Я уже лет 10 думаю, что хаскель автоматически параллелит вычисления, которые можно распараллелить. Чистые функции же, легко понять, что параллелится, а что нет И тут мне говорят, что нет ничего такого. Я готов поверить - я сам про хаскель знаю только самое общее. Но все же - так ли это? Действительно ли нет автоматического распараллеливания? А почему?

Коллеги, прлсветите, пожалуйста Я уже лет 10 думаю, что хаскель автоматически параллелит вычисления, которые можно распараллелить. Чистые функции же, легко понять, что параллелится, а что нет И тут мне говорят, что нет ничего такого. Я готов поверить - я сам про хаскель знаю только самое общее. Но все же - так ли это? Действительно ли нет автоматического распараллеливания? А почему?

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

А?!

Из-за невозможности автоматически определить, когда расходы на параллелизацию не превысят выгоды от неё

Смешно

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

hadoop map reduce?

Хадуп я знаю и умею

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

анекдот_про_холмса_и_математика.тхт

я про то что это совсем не про задачу останова

hadoop map reduce?

Так оно нетьюринг-полное

слишком абстрактные аргументы

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

хотел+

Аргументы - это если есть тезис. А у меня не тезис, а вопрос

Это он мне

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

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

Аргументы - это если есть тезис. А у меня не тезис, а вопрос

Daniel, ваши вопросы понятны, я не про них)

Из-за невозможности автоматически определить, когда расходы на параллелизацию не превысят выгоды от неё

@onokonem, чем Вам этот ответ на вопрос непонравился?

@onokonem, чем Вам этот ответ на вопрос непонравился?

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

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

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

выпуклую?

Нет, но обязательно связную, и часто односвязную

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

Расскажите, очень интересно

Вообще, конечно, очевидно, что оверхед от параллелизации это О(n), где n -- количество переключений контекстов. И единственный способ сделать n константой -- отказать от параллелизации

преконфигуренный тред-пул, лимит на количество тредов для одной задачи

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

Мне кажется, что это попахивает заявкой на Нобелевскую премию

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

преконфигуренный тред-пул, лимит на количество тредов для одной задачи

Ну количество переключений контекстов всё равно не станет от этого константным

Лимит на переключение контекстов -- вот этого заявка на победу! Но что делать, когда он будет исчерпан, непонятно

При полностью загруженом пуле? Сколько есть - столько и напереключает, не больше

При полностью загруженом пуле? Сколько есть - столько и напереключает, не больше

Вы точно о том самом переключении контекста?

Я о том, что выгрузка-загрузка регистров процессора

Мне бы не хотелось дискуссии, коллеги Правильно я понял, что ваш ответ "раз нельзя заранее понять, не станет ли хуже - не будем и пытаться"?

Мне бы не хотелось дискуссии, коллеги Правильно я понял, что ваш ответ "раз нельзя заранее понять, не станет ли хуже - не будем и пытаться"?

Ну а зачем пытаться вычислить невычислимую функцию?

А?!

Ну а ВДРУГ получится!

Ни одного прямого ответа :) Все, что я получил, это встречные вопросы. В любом случае - спасибо, пойду займусь своими делами

ERROR: S client not available

Мне бы не хотелось дискуссии, коллеги Правильно я понял, что ваш ответ "раз нельзя заранее понять, не станет ли хуже - не будем и пытаться"?

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

Ок, это ответ

Поэтому лучше параллизировать тонкие места

Мне бы не хотелось дискуссии, коллеги Правильно я понял, что ваш ответ "раз нельзя заранее понять, не станет ли хуже - не будем и пытаться"?

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

Мне не очень понятный - я-то вынужден горутины запускать прстоянно.

Но - ответ

Ну начните запускать горутины на каждое сложение и поймёте

Поэтому лучше параллизировать тонкие места

Спорно. По мне, так лучше запрещать параллелизацию толстых

Спорно. По мне, так лучше запрещать параллелизацию толстых

Этих мест очень много, в отличии от тонких.

Спорно. По мне, так лучше запрещать параллелизацию толстых

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

Ну начните запускать горутины на каждое сложение и поймёте

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

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

Ну вы пришли и спрашиваете почему в хаскель не паралелит всё автоматически.

Вам объяснили -- что нельзя вычислить что параллелить, а что нет

Параллелить всё не вариант. Вы не согласились. Я предложил вам самому попробовать

Старайтесь придерживаться одного мнения в ходе дискуссии, хорошо? У нас такое токсичное общение не принято

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

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

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

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

Кому понятно и почему?

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

Всё именно так. Просто написать ленивый сейчас никто не может уже

уже и строгий фя не могут

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

на всякий случай зиганул

тормозное убожество получается

уже и строгий фя не могут

Ну, вроде ML'и до сих пор пишут

на всякий случай зиганул

Вот этого тут не надо

самый новый мл с самописным рантаймом это элис, и ему уже больше 10 лет

ну и тормоза

он уже и помереть успел

А пурескрипт не мл что ли?

Вот этого тут не надо

Правым интеллектуалам трудно представить теоратический белый-супрематистский гипер-капитализм®

А пурескрипт не мл что ли?

> с самописным рантаймом

Правым интеллектуалам трудно представить теоратический белый-супрематистский гипер-капитализм®

Я ж вроде левый интеллигент