Re[55]: Как скрестить ужа и ежа или статическую и утиные тип - Философия программирования

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

L>>Ты ошибаешься.
VD>Или ты.

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

L>>В чистом языке (как в Haskell) может не быть понятия последовательности. Функция — это функция в математическом смысле. Запись f(a,b) не определяет в каком порядке будут вычисляться аргументы.
VD>Это никому не нужные абстракции.

Что значит никому не нужные абстракции? Это выводится из отсутствия сайд-эффектов.

VD>Ведь то что порядок не важен никак не запрещает считать, что вычисления идут слева на право и перед все аргументы вычисляются перед вызовом. Так?
VD>А раз так, то достаточно пометить участок кода каким-то образом и считать, что в нем эти соглашения обязаны соблюдаться. Все! Больше не нужно трахать мозги окружающих монадами и прочим высокохудожесвенным бредом.

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

VD>>>Я вижу что модады были созданы исключительно для траханья мозга окружающим.
L>>Нет, цели были другими.
VD>Они явно скрывали истенные цели. :))

:-)

L>>Ну, я же не сам эти усилия предпринимаю. За меня это делает компилятор. А я получаю следующие из этих свойств бонусы.

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

Тут дело вот в чем. Во-первых, давай признаем, что проблема в чистоте, а не лени. Иначе нам не от чего отталкиваться. В этом случае, конечно, есть вариант пометить код нечистым и получить то, что ты хочешь. В принципе, это сделано и сейчас — код помечается типом IO a и выглядит как императивный (явно задана последовательность), с этим нет проблем. Т.е. ваши два решения — твоё и комитета аналогичны, только они ещё и оставили чистоту языка нетронутой (1). Монады для этого учить специально не надо, разве что ты захочешь разобраться как это работает внутри. Но так ведь и во всех остальных языках!

(1) ещё одна разница — это то, что ты считаешь, что твой вариант более быстрый. Положим это так (хотя мне кажется, что это проблемы компилятора, а не программиста). Но тут стоит делать выбор, который и сделали создатели Хаскеля. Они люди неглупые и много думали над решением. Конечно, они могли ошибиться, но после них пришли те, кто язык используют — у них тоже нет проблем с монадическим вводом выводом.

И вот тут мы подходим к философии :-) что такое "верный выбор"? по моему, это решение, благодаря которому мы становимся ближе к цели, чем при "менее правильных" или уж совсем "неверном" выборе. Цель достаточно простая и о ней сказано в описании того, почему авторы выбрали монады. Эта цель — сохранить язык чистым (исходя из цели распространения ФП, обкатки идей и т.д., но это IMHO). И вот исходя из этой цели — твой выбор неверный. Если же исходить из твоих целей (озвучь их пожалуйста), тогда всё может быть как раз наоборот.

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

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.

Нам чужого не надо

Здравствуйте, 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.
Они пытаються выполнить как раз статический анализ кода. Правда сейчас им часто не хватает данных.

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

D>Всё. Прощай возможность автоматически распараллелить код,

А что ей кто-то говорил "зрасте"? Ее в Хаскеле нет и не появится в обозримом будущем. Ему бы пока что до С++ дотянуть по скорости. А то ведь и распараллеливание может не помочь.

Меж тем эксперементы по распараллеливанию ведутся и в императивных языках. И не без успеха. Так что это не аргумент.

D> бесконечные структуры данных и т.д.

Никуда они не денутся. Как были так и останутся. Только их нельзя будет объявлять в тех блоках программы что поечены как "строгие".

D>В Хаскелле для этих целей есть seq, который, однако, большинство рассматривает как что-то подобное goto в императивном мире.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

VladD2 wrote:
> А что ей кто-то говорил "зрасте"? Ее в Хаскеле нет и не появится в
> обозримом будущем. Ему бы пока что до С++ дотянуть по скорости. А то
> ведь и распараллеливание может не помочь.
Parallel Haskell? Хотя сознаюсь, я его не смотрел.

Posted via RSDN NNTP Server 2.0

Здравствуйте, 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>>

VladD2 wrote:
> L>Неа, ты, т.к. тезис о выводимости последовательного исполнения из
> неленивости языка не подтвердился, мало того, был опровергнут.
> Тебе показалось.
Был же формально предъявлен пример с SQL? Формально язык не ленивый.

> L>Что значит никому не нужные абстракции? Это выводится из отсутствия
> сайд-эффектов.
>
> Вот выводимость и остальной булшит, тоже никому крмое самих любителей
> булшита тоже не нужны.
Это не bullshit, это исследование в computer science... Если оно придёт
к чему-то полезному, полезное выдерут из идеальной среды, отрежут, что
не влезет, и вставят в какой-нибудь язык, пригодный для прикладного
программирования в более широкой области, чем некоторые чистые
вычисления (во всех смыслах) со сложной логикой вычислений и без
требований к производительности.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, 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)

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

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

VD>Nemerle рулит

VD>

VD>def numbers = array[5, 4, 1, 3, 9, 8, 6, 7, 2, 0];
VD>WriteLine(numbers.Filter(_ < 5));
VD>

VD>или так
VD>

VD>def numbers = array[5, 4, 1, 3, 9, 8, 6, 7, 2, 0];
VD>WriteLine($[x | x in numbers, x < 5]);
VD>

Хочу заметить, что на C# 2.0 выглядит не менее локанично:

List<int> li = new List<int>(new int[] { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 });
li.ForEach(delegate(int i) { if(i < 5) Console.WriteLine(i); } );

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

T>Практически как в Python-е.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

L>Опять одни эмоции.

Ну, так не нервничай.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>>

VD>>def numbers = array[5, 4, 1, 3, 9, 8, 6, 7, 2, 0];
VD>>WriteLine(numbers.Filter(_ < 5));
VD>>

D>Хочу заметить, что на C# 2.0 выглядит не менее локанично:

D>

D>List<int> li = new List<int>(new int[] { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 });
D>li.ForEach(delegate(int i) { if(i < 5) Console.WriteLine(i); } );
D>

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>>

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

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

L>>Опять одни эмоции.

VD>Ну, так не нервничай. ;)

Ну, сливать ты мастер. Факт известный.

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

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

VD>>>

VD>>>def numbers = array[5, 4, 1, 3, 9, 8, 6, 7, 2, 0];
VD>>>WriteLine(numbers.Filter(_ < 5));
VD>>>

D>>Хочу заметить, что на C# 2.0 выглядит не менее локанично:

D>>

D>>List<int> li = new List<int>(new int[] { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 });
D>>li.ForEach(delegate(int i) { if(i < 5) Console.WriteLine(i); } );
D>>

VD>1. Это не аналогичный код. Мой код возращает список которы в дальнейшем можно продолжить обрабатывать. Например, вот так можно получить список квадратов:

VD>numbers.Filter(_ < 5).Map(x => x * x)
VD>

Можно даже проще (и эффективней):

$[ x*x | x in numbers, x < 5 ]

VD>а так еще и сумировать их:
VD>

VD>numbers.Filter(_ < 5).Map(x => x * x).FoldLeft(0, _ + _)
VD>

$[ x*x | x in numbers, x < 5 ].FoldLeft(0, _ + _)

соответственно.

VD>2. Это выглядит довольно коряво.
+1. Да еще и неэффективно, т.к. сначала создается массив а потом он же копируется в List<int>

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 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-а).
Типа так

macro forpattern(pattern,collection,body)
syntax("forpattern","(",pattern,"in",collection,")",body)
{
    <[ 
         foreach(_ in $collection)
         {
                | $pattern => $body
                | _ => ()
         }
    ]>
}

только чтобы можно было сохранять pattern?

Для этого нужен некий механизм, который позволял бы из паттерна делать T->bool.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 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>>

АХ>+1. Да еще и неэффективно, т.к. сначала создается массив а потом он же копируется в List<int>

Конечно можно обойтись и без лишних "танцев":

int[] a0 = Array.FindAll(new int[] { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 }, delegate(int i) { return i < 5; });

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 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>>

От:	lomeo	http://lomeo.livejournal.com/
Дата:	26.01.07 14:03
Оценка:	12 (1) +1

	От:	deniok
	Дата:	26.01.07 14:27
	Оценка:

От:	Tonal-	www.promsoft.ru
Дата:	26.01.07 15:49
Оценка:

От:	VladD2	www.nemerle.org
Дата:	26.01.07 18:02
Оценка:

	От:	Cyberax
	Дата:	26.01.07 21:16
	Оценка:

	От:	Андрей Хропов
	Дата:	27.01.07 14:59
	Оценка:

	От:	Denis2005
	Дата:	28.01.07 08:43
	Оценка:

	От:	Denis2005
	Дата:	28.01.07 08:43
	Оценка: