Неправильное поведение лямбда-функций

облако selectel переписали с питона на хаскель

«Всё ли мы переписали на хаскел? Увы, нет, процесс идёт по мере возникновения потребностей и большая часть нашего кода всё ещё на питоне»

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

Это не системный софт.

Это не системный софт.

ОМГ, а как ты определяешь понятие «системный софт»?

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

Он по крайней мере не ленивый. Но сборка мусора всё портит, ИМХО. Непредсказуемый софт - это не системный софт.

У них биллинг и обвязки написаны, для меня это прикладной. Системный, например xapi или xenstore.

Понятно, что тут Си рулит и педалит.

не могу такое воспринимать всерьез.

При чём тут стиль статьи? Твои комментарии это эмоции. То что там не всё на хаскеле это потому что статья старая, была написана по горячим следам их миграции. Я этот период отлично помню, админку колбасило.

Даже если там часть на питоне то что в этом плохого? Я более того скажу, у них там и сишный код есть.

Ну хоть наполовину? А, еще слышал https://github.com/GaloisInc/HaLVM - но ориентировано на хаскель и статус его не знаю - пишут, что где-то используют.

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

Ну хоть наполовину?

Меньшую %)

Системный, например xapi или xenstore.

xapi на ocaml написан. Отсюда делаю недалёкий вывод что оно бы и на хаскеле взлетело.

Я не утверждал отбратного, а привел пример того, что для меня является системным софтом, а не биллинг и обвязка вокруг XCP у селектела.

Кстати, в xcp и xenstore на ocaml написан.

Непредсказуемый софт - это не системный софт.

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

Ну наверное нужно уточнить, что в плане производительности? Что писать на хаскель предсказуемо-производительные программы - сложно, нельзя не согласиться.

При чём тут стиль статьи?

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

Даже если там часть на питоне то что в этом плохого?

Это просто делает использование термина «переписали» сомнительным. Мягко говоря.

P.S. Python - это точно не язык для системного софта.

но разве весь системный софт - предсказуемый?

Думаю, что он весь должен быть таким. Примеры обратного - в студию.

Ой, в halvm 302 *.c против 197 *.hs

P.S. Python - это точно не язык для системного софта.

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

На нем вполне успешно написан xapi и большая часть утилит/систем в XCP.

у ксена xapi/xcp так много жрут что оптимизация становится насущной задачей?

Думаю, что он весь _должен быть таким_.

Кто-то против?

Примеры обратного - в студию.

linux?

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

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

Насколько большую, насколько менее предсказуем...

Вообще нема места в системной нише, даже если watchdog-ом обвязать?

У watchdog-ов совсем, совсем другое назначение.

Для меня пакетный менеджер, система мониторинга или внедрения, бэкапилка итп это системный софт.

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

Какое запутанное объяснение. Можно пару примеров системного софта?

Ядро ОС, библиотеки уровня glibc и zlib, рантайм языка, мультимедиа-декодер.

А хайрят до сих пор только питонистов :E

Странная у тебя классификация.. Я бы сказал zlib и всякие gstreamer это прикладные либы, ну да ладно.

А хайрят до сих пор только питонистов

Кто знает что с ними потом делают... Возможно, это обронили фразу «мы питонистов на хаскель за неделю пересаживаем».

Я бы сказал zlib и всякие gstreamer это прикладные

zlib? Нет, она уже давно системная (ЕМНИП, она используется в PPP и HTTP). А если мультимедийные декодеры кажутся тебе попсой, окей - подставь вместо них декодер любого нетривиального формата, хотя бы криптографического.

либы

Я специально подчеркнул использование через библиотечные интерфейсы (на всякий случай - это не о веб-службах и прочих сетевых API).

использование через библиотечные интерфейсы

почему именно такой критерий? По-моему, это классификация не по назначению, а по интерфейсу.

Насколько большую, насколько менее предсказуем...

Есть конкретный язык, может со временем появятся «наработанные данные» чтоб судить.. А был же пример, правда непрямой: прототипирование L4(?) вроде на лоре была новость.

У watchdog-ов совсем, совсем другое назначение.

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

прототипирование L4(?)

Засыпают.. не самого, а чего-то, основанного на нем.

использование через библиотечные интерфейсы

почему именно такой критерий?

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

P.S. вот хорошая статья на смежную тему (она об управлении памятью, но походя дает представление о требованиях к языку для системного софта): http://pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-th...

А был же пример, правда непрямой: прототипирование L4(?) вроде на лоре была новость.

Использование Haskell для верификации seL4? Там Haskell использовался как язык моделирования, а не системного софта.

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

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

Использование Haskell для верификации seL4? Там Haskell использовался как язык моделирования, а не системного софта.

Да вроде оно. Ну не спорю, честно написал, что «непрямой» пример, вроде подмены понятий: сопутствующий системному -> системный не делал.

Watchdog-и используются для выхода из безвыходных ситуаций типа краха системы

Позволю себе считать, что цель была поделиться мудростью, а не ткнуть безымянного («не знал какой термин применить») %). Кстати, почему-то думал, что необязательно такие ситуации: если одно (пусть даже не критически-важное устройство) повисло, а другое отправляет ему низкоуровневый сброс.

цель была поделиться мудростью

Мудростью. О да.

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

Это и есть безвыходная ситуация для «одного».

Мудростью. О да.

Я бы тоже так ответил, чтобы основная масса лора не распознала как чужака. (Ну можно же мне немного потроллить в ответ хоть не на техническом, так на психологическом уровне? :)

Это и есть безвыходная ситуация для «одного».

По-моему не совсем объективный подход: в одном случае разделяется «подсистема» (как часть системы), а в другом нет. но ведь на уровне софта такое тоже может иметь место: крах на одном уровне - обрабатываемый случай на другом, вроде перезапуска следящим демоном.

Или просто сей термин неприменим вне контекста железа?

По-моему не совсем объективный подход

Не понял, в чем необъективность.

Ммм, что-то я вижу противоречие вот с этим:

http://ru.wikipedia.org/wiki/Системное_программное_обеспечение

По твоей логике libxpm или libmpg321 какой-нить это системное программирование...

но походя дает представление о требованиях к языку для системного софта

так мы сейчас не об этом спорим, а о том что считать системным софтом.

что-то я вижу противоречие вот с этим: http://ru.wikipedia.org/wiki/Системное_программное_обеспечение

Не люблю русскую Вики, но даже в ней отражена суть:

«В отличие от прикладного программного обеспечения, системное не решает конкретные практические задачи, а лишь обеспечивает работу других программ, предоставляя им сервисные функции»

походя дает представление о требованиях к языку для системного софта

так мы сейчас не об этом спорим

Я вообще не спорю. А статью почитай.

И чем бэкапилка не сервисная функция?

чем бэкапилка не сервисная функция?

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

за такое:

l, i = 0, [] 
for i in range(2):
  l.append(lambda: i)

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

int i=0;
while(....) {
  ....
  ++i;
}
while(....) { // этот цикл надо начать именно с того i, где закончился первый
  ....
  ++i;
}

Бардак - он, как обычно, в головах.

а я что, против? в голове гвидо, например, когда он делал области видимости

В примере ТС нет никакого «нелокального скоупа».

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

кусок кода

 
for i in range(2):
  l.append(lambda: i)

да, на с++ можно написать for(; i<n; ++i) {....} с похожим нелокальным поведением, но это превращается в локальную версию *простым* дописыванием «int i», т.е. for(int i; i<n; ++i) {....}, а как в питоне?

Бардак - он, как обычно, в головах.

а я что, против? в голове гвидо

*пожимая плечами* окей, как скажешь.

была написана по горячим следам их миграции. Я этот период отлично помню, админку колбасило.

спасибо

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

ах вот ты какой, северный олень хаскель

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

тогда этот язык, вероятно, не хаскель

были тесты на устойчивость исходников программ на разных языках от случайного изменения — так хаскель примерно в 2 раза чаще, чем с++, собирался без ошибок, и при этом глючил в рантайме http://habrahabr.ru/post/161967/

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

Если таки сходить по ссылке то увидим что разница между питоном и сями всего 50% (wrong output). Выводы делай сам.

честно говоря я не понял, какие выводы я должен сделать из этой разницы в 50% — хотя бы потому, что чистый си совсем не интересен

вот что я вижу:

1. если брать надежность в чистом виде (без коррекции на избыточную говорливость), то с++ ведущий

2. хаскель *очень* неплох, поскольку *несмотря* на свою лаконичность, собирается с ошибками еще реже, чем с++

3. ява — полное говно, т.к. несмотря на свою жуткую говорливость (например Window window = new Window(), гы-гы), умудряется глючить в рантайме больше, чем с++

но за исключением п.1 это я и так знал

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

Всё что этот тест показывает это то что если натравить неизвестный перловый скрипт на исходники то программа может даже заработает.

Я намекнул что в этой волшебной статье получилось так что кол-во ошибок в питоне и хаскеле получилось одинаковым. Это крайне противоречит практике. Вместо того чтобы притягивать за уши аналитику лучше бы задумался почему результаты теста нерепрезентативны.

так же можно сравнить питон с хаскелем — питон полностью проигрывает при примерно равной лаконичности (хотя, честно говоря, код на питоне более плавный, а на хаскеле какой-то дерганный)

не очень понятен результат си-шарп — вполен возможно, такой результат будет у с++11, если активно пользоваться auto

Я намекнул что в этой волшебной статье получилось так что кол-во ошибок в питоне и хаскеле получилось одинаковым. Это крайне противоречит практике.

это говорит о том, что ты не прочувствовал систему типов хаскеля

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