Здравствуйте, VladD2, Вы писали:
L>>Ты ошибаешься. VD>Или ты.
Неа, ты, т.к. тезис о выводимости последовательного исполнения из неленивости языка не подтвердился, мало того, был опровергнут.
L>>В чистом языке (как в Haskell) может не быть понятия последовательности. Функция — это функция в математическом смысле. Запись f(a,b) не определяет в каком порядке будут вычисляться аргументы. VD>Это никому не нужные абстракции.
Что значит никому не нужные абстракции? Это выводится из отсутствия сайд-эффектов.
VD>Ведь то что порядок не важен никак не запрещает считать, что вычисления идут слева на право и перед все аргументы вычисляются перед вызовом. Так? VD>А раз так, то достаточно пометить участок кода каким-то образом и считать, что в нем эти соглашения обязаны соблюдаться. Все! Больше не нужно трахать мозги окружающих монадами и прочим высокохудожесвенным бредом.
Как и то, что вычисления идут справа налево. Считать можно что угодно, для чистого языка разницы быть не должно. Иначе язык нечистый. Точка.
Хоть обпомечайся код каким угодно образом, от того, в какой последовательности ты выполнишь два независимых участка, результат поменяться не должен.
VD>>>Я вижу что модады были созданы исключительно для траханья мозга окружающим. L>>Нет, цели были другими. VD>Они явно скрывали истенные цели. :))
:-)
L>>Ну, я же не сам эти усилия предпринимаю. За меня это делает компилятор. А я получаю следующие из этих свойств бонусы.
VD>Бунусы останутся на месте если просто помечать код. Но при этом на месте останется крыша тех кто пользуется языком и появится скорость полноценных компилируемых языков.
Тут дело вот в чем. Во-первых, давай признаем, что проблема в чистоте, а не лени. Иначе нам не от чего отталкиваться. В этом случае, конечно, есть вариант пометить код нечистым и получить то, что ты хочешь. В принципе, это сделано и сейчас — код помечается типом IO a и выглядит как императивный (явно задана последовательность), с этим нет проблем. Т.е. ваши два решения — твоё и комитета аналогичны, только они ещё и оставили чистоту языка нетронутой (1). Монады для этого учить специально не надо, разве что ты захочешь разобраться как это работает внутри. Но так ведь и во всех остальных языках!
(1) ещё одна разница — это то, что ты считаешь, что твой вариант более быстрый. Положим это так (хотя мне кажется, что это проблемы компилятора, а не программиста). Но тут стоит делать выбор, который и сделали создатели Хаскеля. Они люди неглупые и много думали над решением. Конечно, они могли ошибиться, но после них пришли те, кто язык используют — у них тоже нет проблем с монадическим вводом выводом.
И вот тут мы подходим к философии :-) что такое "верный выбор"? по моему, это решение, благодаря которому мы становимся ближе к цели, чем при "менее правильных" или уж совсем "неверном" выборе. Цель достаточно простая и о ней сказано в описании того, почему авторы выбрали монады. Эта цель — сохранить язык чистым (исходя из цели распространения ФП, обкатки идей и т.д., но это IMHO). И вот исходя из этой цели — твой выбор неверный. Если же исходить из твоих целей (озвучь их пожалуйста), тогда всё может быть как раз наоборот.
FR>Как я понял речь идет не вообще о списках, которые были в питоне с момента рождения, а о списковых расширениях (list comprehensions) которые и появились первыми именно в хаскеле.
Википедия, list comprehensions:
The earliest reference to the list comprehension notation is in Rod Burstall and John Darlington's description of their programming language, NPL from 1977, but SETL already had a similar construct.
Нам чужого не надо
Re[52]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, VladD2, Вы писали: T>>Я говорил про конкретный списковый синтаксис. T>>В Python-е он появился во 2ой версии и заимствован из Haskell. VD>Ты меня извини, но без ссылок такие заявления ничего не стоят. VD>Haskell является наследником ML и во многом заимствовал синтаксис у него. VD>Немерле тоже, но через O'Caml. А Питон уж точно вряд ли мог что-то там заимствовать у Хаскеля. VD>В общем, ссылки в студию... http://wiki.python.org/moin/PythonVsHaskell
T>>Если взять определение из Википедии, то скриптовый язык, это язык разработанный и использующийся для автоматизации рутинных действий. VD>Плохо читал.
Хотелось бы твою интерпретацию. VD>Нет в руском языке слова "скриптования". Не надо его применять.
Автоматизация рутинных действий подходит больше? VD>И Питон конечно же вряд ли создавался как язык общего назначения.
Именно как язык общего назначения. См. Википедию.
T>>В такой же позиции окажется и Немерл если использовать его для этой самой автоматизации. (а что мешает) VD>Ни что не мешает. Но в отличии от Питона на нем еще можно писать критичные к времени исполнения вещи.
Немерл предоставляет real-time гаранти по времени выполнения?
А если ты о NetJit-е, так у python есть psyco.
Ну и действительно критичные ко времени выполнения вещи таки пишуться на C++ и ещё долго будут на нём писаться.
VD>Да и выглядит код на Немерле, по-моему, по риличнее. ООП и ФП в нем поддерживаются явно чище. VD>В прочем я в принципе не люблю интерфпретируемые языки с прототипной разновидностью ООП.
Я не люблю .Net из за его воинственно-назойливой рекламы и закрытости.
Хотя идея в общем здравая.
T>>>>К Python тоже прикручивается что угодно. VD>>>Не совсем. Синтаксис в нем менять нельзя, в отличии "от". T>>Синтаксическое дерево ты получить можешь, а так же байт-код. T>>Есть несколько проектов, которые это используют. T>>Кроме того есть перегрузка операторов, декораторы и метаклассы — соответственно, даже штатными средствами можно получить очень большую вариабельность. VD>Все это детский лепет. Изучи макросы Немерла тогда поговрим. Пока что ты просто не понимаешь о чем говоришь. Это разный уровень. Все равно что эмуляция ООП на ассемблере.
Ок. Посмотрю.
T>>Собственно тред и начался с планов ввода статики. VD>Ага. Вот только на сегодня Неперле — это где она введена и на 100%. Причем введена грамотно, на высоком научном уровне. А Питон только собирается попробовать это сделать. VD>Собсвтенно с автором Питона я всецело согласен. Он человек весьма адекватный.
Статика на 100% в python-е не нужна — это получиться другой язык (см. например Boo)
Но если получится адекватно ввести возможность указывать ограничения на тиры, то некоторых классов ошибок можно будет избежать, да и скорость скомпилированного кода можно изрядно поднять.
T>>Причём, большое колмчество ошибок вполне можно найти до рантайме, используя утилиты проверки. VD>Все можно найти. Вопрос только в цене. Искать ошибки в рантайме сложнее чем читать лог компилятора. Так что не размуно оправдывать тем что ошибку можно найти потом то что ее вообще надо допускать.
До выполнения.
Используя утилиты типа lint — PyLint и PyChecker.
Они пытаються выполнить как раз статический анализ кода. Правда сейчас им часто не хватает данных.
Re[23]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, deniok, Вы писали:
D>Всё. Прощай возможность автоматически распараллелить код,
А что ей кто-то говорил "зрасте"? Ее в Хаскеле нет и не появится в обозримом будущем. Ему бы пока что до С++ дотянуть по скорости. А то ведь и распараллеливание может не помочь.
Меж тем эксперементы по распараллеливанию ведутся и в императивных языках. И не без успеха. Так что это не аргумент.
D> бесконечные структуры данных и т.д.
Никуда они не денутся. Как были так и останутся. Только их нельзя будет объявлять в тех блоках программы что поечены как "строгие".
D>В Хаскелле для этих целей есть seq, который, однако, большинство рассматривает как что-то подобное goto в императивном мире.
В Хаскеле вообще просматривается изрядная доля, как бы это сказать по мягче...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Как скрестить ужа и ежа или статическую и утиные тип
VladD2 wrote: > А что ей кто-то говорил "зрасте"? Ее в Хаскеле нет и не появится в > обозримом будущем. Ему бы пока что до С++ дотянуть по скорости. А то > ведь и распараллеливание может не помочь.
Parallel Haskell? Хотя сознаюсь, я его не смотрел.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[23]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, lomeo, Вы писали:
L>Неа, ты, т.к. тезис о выводимости последовательного исполнения из неленивости языка не подтвердился, мало того, был опровергнут.
Тебе показалось.
L>Что значит никому не нужные абстракции? Это выводится из отсутствия сайд-эффектов.
Вот выводимость и остальной булшит, тоже никому крмое самих любителей булшита тоже не нужны.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>А при чем тут немерле, мы когда впервые ругались ты о нем еще и не слышал
Прально! (с) Я тогда просто чувствовал, что можно все далеть не так через ухо. И тогда я был в поиске... R#... и т.п. А теперь я таки нашел!
FR>>>Кстати ван Россум тайный почитатель хаскеля и я тоже слышал что списки он оттуда содрал.
VD>>Расстрой его. Списки в Хаскеле синтаксически заимствованы из ML-подобных языков (коим и является Хаскель). А появились они в том самом легендарном дедушке Лиспе.
FR>Как я понял речь идет не вообще о списках,
Ты сказал "синтаксис списков". Так вот он был в МЛ почти 1 в 1.
FR> которые были в питоне с момента рождения, а о списковых расширениях (list comprehensions) которые и появились первыми именно в хаскеле.
По поводу list comprehensions тебе уже сказали. Я же добавлю, только что откровенно говоря list comprehensions в Хаскле и его калька в Немерле мне не очень наравится. Точнее совсем не нарвится. Причина тому — не интуитивность. Может те кто всю жизнь с мат.нотациями возятся и встретят его как родного, но большинство мэйнстрим-программистов от его вида будут сильно удивлены. Так что я бы предпочел композицию функций.
Вот сейчас подумалось... Может создать некий foreach comprehension? Ну, а ля list comprehensions, но с синтаксисом Немерлевого foreach-а. Чтобы выглядело как-то так:
def z = 0;
each(x is SomeType when x.y > z in someSequence)
или в общем виде:
each(<сопоставление с образцом> in <последовательнсоть>) => <другая последовательность>
Причем, чтобы это дело порождало фукнцию которую можно передать куда хочется (в отличии от foreach-а).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Как скрестить ужа и ежа или статическую и утиные тип
VladD2 wrote: > L>Неа, ты, т.к. тезис о выводимости последовательного исполнения из > неленивости языка не подтвердился, мало того, был опровергнут. > Тебе показалось.
Был же формально предъявлен пример с SQL? Формально язык не ленивый.
> L>Что значит никому не нужные абстракции? Это выводится из отсутствия > сайд-эффектов. > > Вот выводимость и остальной булшит, тоже никому крмое самих любителей > булшита тоже не нужны.
Это не bullshit, это исследование в computer science... Если оно придёт
к чему-то полезному, полезное выдерут из идеальной среды, отрежут, что
не влезет, и вставят в какой-нибудь язык, пригодный для прикладного
программирования в более широкой области, чем некоторые чистые
вычисления (во всех смыслах) со сложной логикой вычислений и без
требований к производительности.
Posted via RSDN NNTP Server 2.1 beta
Re[24]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, VladD2, Вы писали:
L>>Неа, ты, т.к. тезис о выводимости последовательного исполнения из неленивости языка не подтвердился, мало того, был опровергнут.
VD>Тебе показалось.
Что именно показалось? Так и будешь отделываться общими фразами?
Я тебе показал пример неленивого кода, при котором отсутствует последовательное исполнение.
Следовательно, не ленивость является причиной этого.
Покажи, где в моих рассуждениях ошибка?
L>>Что значит никому не нужные абстракции? Это выводится из отсутствия сайд-эффектов.
VD>Вот выводимость и остальной булшит, тоже никому крмое самих любителей булшита тоже не нужны.
Опять одни эмоции. "булшит", "никому кроме". Сказать то что хотел?
Здравствуйте, VladD2, Вы писали: VD>Вот сейчас подумалось... Может создать некий foreach comprehension? Ну, а ля list comprehensions, но с синтаксисом Немерлевого foreach-а. Чтобы выглядело как-то так: VD>
VD>def z = 0;
VD>each(x is SomeType when x.y > z in someSequence)
VD>
VD>или в общем виде: VD>
VD>each(<сопоставление с образцом> in <последовательнсоть>) => <другая последовательность>
VD>
VD>Причем, чтобы это дело порождало фукнцию которую можно передать куда хочется (в отличии от foreach-а).
Практически как в Python-е.
Вот из реального проекта (возврат генератора):
def getEnabledUser(self):
return (obj.oid for obj in self._allObjs if obj.enabled)
Причём, это генератор — т.е. реальные вычисления проводятся тогда, когда понадобиться соответствующий элементик.
Если поставить квадратные скобки — последовательность сразу вычислиться вся.
Re[46]: Как скрестить ужа и ежа или статическую и утиные тип
1. Это не аналогичный код. Мой код возращает список которы в дальнейшем можно продолжить обрабатывать. Например, вот так можно получить список квадратов:
numbers.Filter(_ < 5).Map(x => x * x)
а так еще и сумировать их:
numbers.Filter(_ < 5).Map(x => x * x).FoldLeft(0, _ + _)
2. Это выглядит довольно коряво.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Как скрестить ужа и ежа или статическую и утиные тип
VD>1. Это не аналогичный код. Мой код возращает список которы в дальнейшем можно продолжить обрабатывать. Например, вот так можно получить список квадратов:
Здравствуйте, VladD2, Вы писали:
VD>По поводу list comprehensions тебе уже сказали. Я же добавлю, только что откровенно говоря list comprehensions в Хаскле и его калька в Немерле мне не очень наравится. Точнее совсем не нарвится. Причина тому — не интуитивность.
Это субъективная вещь.
VD> Может те кто всю жизнь с мат.нотациями возятся и встретят его как родного, но большинство мэйнстрим-программистов от его вида будут сильно удивлены.
Немерле в любом случае для тех кто хочет чего-то большего чем C#. Для большинства мэйнстрим-программистов и pattern-matching и Iter/Map/Fold/лямбды тоже не слишком привычны.
VD> Так что я бы предпочел композицию функций.
VD>Вот сейчас подумалось... Может создать некий foreach comprehension? Ну, а ля list comprehensions, но с синтаксисом Немерлевого foreach-а. Чтобы выглядело как-то так: VD>
VD>def z = 0;
VD>each(x is SomeType when x.y > z in someSequence)
VD>
Дак те же list comprehensions практически 1-в-1 (только нет букв each — от этого что ли зависит интуитивная понятность ?):
def z = 0;
$[ x | x in someSequence, x is SomeType, x.y > z ]
, только многословнее и на мой взгляд менее понятно, ну и конечно менее гибко (нельзя произвольные функции от переменных из правой части пихать в левую).
VD>или в общем виде: VD>
VD>each(<сопоставление с образцом> in <последовательнсоть>) => <другая последовательность>
VD>
VD>Причем, чтобы это дело порождало фукнцию которую можно передать куда хочется (в отличии от foreach-а).
Типа так
Здравствуйте, VladD2, Вы писали:
VD>1. Это не аналогичный код. Мой код возращает список которы в дальнейшем можно продолжить обрабатывать. Например, вот так можно получить список квадратов:[c#] VD>numbers.Filter(_ < 5).Map(x => x * x)
Ок, вот аналогичный код:
li.FindAll(delegate(int i) { return i < 5; }).ConvertAll<int>(delegate(int i) { return i * i; });
VD>2. Это выглядит довольно коряво.
Это вопрос о том, как плохо в наше время живется без лямбды (хотя-бы такой как в BOOST).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[49]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, Denis2005, Вы писали:
VD>>numbers.Filter(_ < 5).Map(x => x * x)
D>Ок, вот аналогичный код: D>li.FindAll(delegate(int i) { return i < 5; }).ConvertAll<int>(delegate(int i) { return i * i; });
Сомнения в том что Немерле рулит еще остались?
Тогда попробуй написать аналогичный код для массива.
VD>>2. Это выглядит довольно коряво.
D>Это вопрос о том, как плохо в наше время живется без лямбды (хотя-бы такой как в BOOST).
Такой как Бусте лучше не надо. Это сильно кастрированный вариант.
Кроме того еще хотелось быиметь функциональный тип вместо делегатов (или в дополнении к ним) и вывод типов, чтобы не приходилось указывать параметры типов.
Ну, и само собой нужны метды расширения.
Кое что будет в C# 3.0, но к сожалению не все.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.