Re: Стабильная система?

[Artem Chuprina]

Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Wed, 28 Oct 2015 
13:17:00 +0200:

 >> Понятно что неизменяемость влечет за собой генерацию кучи обьектов и большей
 >> нагрузки на GC и тут еще нужно смотреть что лучше.

 OG> Вот пример когда имутабельность приводит к меньшей производительности:

 OG>   
http://concurrencyfreaks.blogspot.com/2013/10/immutable-data-structures-are-not-as.html

 OG> Когда у нас большущее дерево (но влазит в L2, который сейчас несколько
 OG> мегабайт на десктопе и десятки-сотни на серверах) в случае мутабельности
 OG> перебалансировка выкинет/добавит 1 ноду, в имутабельном случае LOG(N), это 
за
 OG> собою влечет засовывание в кеш LOG(N) новых значений. Заметьте не 
изменения, а
 OG> добавления! Т.к. новые ноды будут иметь новые адреса вирт. памяти.

С одной стороны, кто бы спорил - серебряной пули нет.

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

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

Конечно, если у нас и апдейты конкурентные, то блокировки между ними
нужны и в иммутабельном случае.  Software Transactional Memory (которая,
собственно, и потянет упомянутые в статье два барьера вместо одного), по
словам измерявших людей, работает заметно медленнее, чем обычные
блокировки.  Зато надежнее.  Таким образом, если у нас основная нагрузка
- конкурентные апдейты, то наш выбор - мутабельные структуры, не вопрос.

Собственно, измерявший товарищ так и делал, насколько я его понял.

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

Re: Стабильная система?

[Oleksandr Gavenko]

On 2015-10-28, Oleksandr Gavenko wrote:

> Понятно что неизменяемость влечет за собой генерацию кучи обьектов и большей
> нагрузки на GC и тут еще нужно смотреть что лучше.

Вот пример когда имутабельность приводит к меньшей производительности:

  
http://concurrencyfreaks.blogspot.com/2013/10/immutable-data-structures-are-not-as.html

Когда у нас большущее дерево (но влазит в L2, который сейчас несколько
мегабайт на десктопе и десятки-сотни на серверах) в случае мутабельности
перебалансировка выкинет/добавит 1 ноду, в имутабельном случае LOG(N), это за
собою влечет засовывание в кеш LOG(N) новых значений. Заметьте не изменения, а
добавления! Т.к. новые ноды будут иметь новые адреса вирт. памяти.

-- 
Best regards!

Re: Стабильная система?

[Oleksandr Gavenko]

On 2015-10-26, Dmitrii Kashin wrote:

>> Сравните:
>>
>>   
>> http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=threadring
>
> Олександр, я дико извиняюсь, но для меня всегда было большой проблемой
> понимание методики тестирования. Ситуация всегда одна и та же: Передо
> мной какой-то тест. Надо понять, в чём его суть, как производилось
> сравнение, что демонстрируют его результаты. Начинаю искать по названию
> теста в поисковике -- и пусто. Ничего толком не понятно.
>
> Вот в данном случае, я поискал по слову thread ring test -- и ничего не
> уяснил для себя. Где мне посмотреть, что это такое-то?
>
> К тому же, мне интересно, что там можно в OCaml сравнивать по части
> тредов. У него ж их нет.

Приведенный сайт - это бывший

  http://shootout.alioth.debian.org/

Навигация на старом была понятней, на новом ощущение что все сломано.

Тут исходные тексты и скрипты тестирования
http://benchmarksgame.alioth.debian.org/play.html

Я не в курсе социальных процесов по проекту, вижу что есть плачь, наример:
http://habrahabr.ru/post/119579/

Историю проекта можно начинать выискивать тут:
http://benchmarksgame.alioth.debian.org/sometimes-people-just-make-up-stuff.html

Как видно проект переходил из рук в руки, принадлежал всегда индивидуалам и
за ним не было сообщества.

Я читал статью на русском сайте Intel Research как они перегнали один из
тестов используя Intel C Compiler используя спец. директивы для того что бы
контекст исполнения не переключался между ядрами, там было еще пару трюков.
Статью не отыщу, за давностью времени они выпала из баз поисковиков, тут
пусто:

  site:intel.ru  shootout.alioth
  site:intel.com  shootout.alioth

В общем про преимущества неизменяемых обьектов для GC посмотрите здесь:

  http://c2.com/cgi/wiki?ImmutableObjectsAndGarbageCollection

Сразу получаем возможность проводить паралельну сборку к основному выполнению,
т.е. нет необходимости вводить блокировки на запись в момент GC. Такие
блокировки будут отодвинуты до момента дефрагментации.

Хотя там как то мало написано, буча вокруг функционального программирования
необосновано раздута, раз так мало написано про преимущества рантайма таких
сред.

Настоящий реализованый пример:
https://wiki.haskell.org/GHC/Memory_Management#Garbage_collection

Понятно что неизменяемость влечет за собой генерацию кучи обьектов и большей
нагрузки на GC и тут еще нужно смотреть что лучше.

-- 
Best regards!

Re: Стабильная система?

[Dmitrii Kashin]

Oleksandr Gavenko  writes:

> On 2015-10-15, Dmitrii Kashin wrote:
>
>> Бывает, что императивное программирование разумнее. Большинство
>> алгоритмов можно писать в функциональном стиле, но бывает и так, что это
>> порождает большой оверхед в производительности.
>
> Или наоборот имея в вычислительной модели гарантии о ссылочности меджу данными
> можно уменьшить время в блокировках или эфективней собирать мусор.
>
> Сравните:
>
>   http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=threadring

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

Вот в данном случае, я поискал по слову thread ring test -- и ничего не
уяснил для себя. Где мне посмотреть, что это такое-то?

К тому же, мне интересно, что там можно в OCaml сравнивать по части
тредов. У него ж их нет.


signature.asc
Description: PGP signature

Re: Стабильная система?

[Dmitrii Kashin]

"Артём Н."  writes:

> On 17.10.2015 22:21, Dmitrii Kashin wrote:
>> "Артём Н."  writes:
>>
>>> On 16.10.2015 16:46, Artem Chuprina wrote:
 Артём Н. -> debian-russian@lists.debian.org  @ Fri, 16 Oct 2015 16:04:15 
 +0300:

АН> Хосспади, OCaml... o.O
АН> Может, когда требуется "большой кусок в императивном стиле",
АН> следует отказаться от использования функционального языка в сторону 
 императивного?
АН> Или религия не позволяет? ;-)

 А смысл, если есть язык, который это позволяет прямо тут?  Ocaml,
 насколько я понимаю, ничем не плох.
>>>
>>> "Большой кусок в императивном стиле" может иметь разный размер.
>>> Смысл в том, чтобы молотком забивать гвозди, а под микроскопом 
>>> рассматривать нечто под увеличением.
>>> Конечно, возможно на молоток линзу приделать, но зачем?
>>
>> Артём, всё в толк не возьму: Вы что сказать-то хотели?
>>
> Для чего использовать инструмент, не ориентированный на данную задачу?
> Возможно конечно пытаться "задать порядок выполнения" в функциональном языке,
> а возможно использовать императивный для "императивного" куска и не городить 
> огород
> (к тому же, если код уже фактически написан).
> Почему просто не выделить в отдельный проект?

Артём, Вы всё попутали. Это Haskell -- чисто функциональный язык. Это в
нём надо "задавать порядок выполнения". В Ocaml как раз прямо
противоположная ситуация: если нужно написать кусок в императивном
стиле, средства языка это вполне позволяют.

Поэтому, может быть:

АН> Хосспади, Haskell... o.O



signature.asc
Description: PGP signature

Re: Стабильная система?

[Oleksandr Gavenko]

On 2015-10-15, Dmitrii Kashin wrote:

> Бывает, что императивное программирование разумнее. Большинство
> алгоритмов можно писать в функциональном стиле, но бывает и так, что это
> порождает большой оверхед в производительности.

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

Сравните:

  http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=threadring

-- 
Best regards!

Re: Стабильная система?

[Артём Н.]

On 17.10.2015 22:21, Dmitrii Kashin wrote:

"Артём Н."  writes:


On 16.10.2015 16:46, Artem Chuprina wrote:

Артём Н. -> debian-russian@lists.debian.org  @ Fri, 16 Oct 2015 16:04:15 +0300:

   АН> Хосспади, OCaml... o.O
   АН> Может, когда требуется "большой кусок в императивном стиле",
   АН> следует отказаться от использования функционального языка в сторону 
императивного?
   АН> Или религия не позволяет? ;-)

А смысл, если есть язык, который это позволяет прямо тут?  Ocaml,
насколько я понимаю, ничем не плох.


"Большой кусок в императивном стиле" может иметь разный размер.
Смысл в том, чтобы молотком забивать гвозди, а под микроскопом рассматривать 
нечто под увеличением.
Конечно, возможно на молоток линзу приделать, но зачем?


Артём, всё в толк не возьму: Вы что сказать-то хотели?


Для чего использовать инструмент, не ориентированный на данную задачу?
Возможно конечно пытаться "задать порядок выполнения" в функциональном языке,
а возможно использовать императивный для "императивного" куска и не городить 
огород
(к тому же, если код уже фактически написан).
Почему просто не выделить в отдельный проект?

Re: Стабильная система?

[Dmitrii Kashin]

"Артём Н."  writes:

> On 16.10.2015 16:46, Artem Chuprina wrote:
>> Артём Н. -> debian-russian@lists.debian.org  @ Fri, 16 Oct 2015 16:04:15 
>> +0300:
>>
>>   АН> Хосспади, OCaml... o.O
>>   АН> Может, когда требуется "большой кусок в императивном стиле",
>>   АН> следует отказаться от использования функционального языка в сторону 
>> императивного?
>>   АН> Или религия не позволяет? ;-)
>>
>> А смысл, если есть язык, который это позволяет прямо тут?  Ocaml,
>> насколько я понимаю, ничем не плох.
>
> "Большой кусок в императивном стиле" может иметь разный размер.
> Смысл в том, чтобы молотком забивать гвозди, а под микроскопом рассматривать 
> нечто под увеличением.
> Конечно, возможно на молоток линзу приделать, но зачем?

Артём, всё в толк не возьму: Вы что сказать-то хотели?


signature.asc
Description: PGP signature

Re: Стабильная система?

[Artem Chuprina]

Dmitrii Kashin -> debian-russian@lists.debian.org  @ Sat, 17 Oct 2015 00:17:13 
+0300:

 >>  >>  DK> За время работы с ним меня приятно удивило после Haskell:
 >>  >>
 >>  >>  DK> 1) Позволяет более просто комбинировать функциональное и 
 >> императивное
 >>  >>  DK> программирование: не надо изворачиваться монадами, чтобы добиться
 >>  >>  DK> последовательного выполнения команд.
 >>  >>
 >>  >> ...
 >>  >>
 >>  >> а зачем, собственно, добиваться последовательного выполнения никак не
 >>  >> связанных между собой команд?
 >>
 >>  DK> Я думаю, тут есть недоразумение. Требование последовательного 
 >> выполнения
 >>  DK> определённых команд как раз и определяет связь между ними. Если конечно
 >>  DK> не считать, что связь -- это "результат А нужен для вычисления B". Тут
 >>  DK> важно понять, что императивное программирование -- это именно
 >>  DK> программирование с изменением состояния системы.
 >>
 >> Тогда это, натурально, связанные между собой команды.  Для вычисления B
 >> требуется состояние системы, полученное после вычисления A.
 >>
 >> Хаскельный компилятор просто более аккуратно подходит к вопросу
 >> зависимости (он машина, ему внимания не жалко), и может обнаружить
 >> независимость там, где программист ее не обнаружил, и по умолчанию
 >> полагает, что зависимость есть.

 DK> Теоретически это наверное плюс. Но мне бы реальных ситуаций. У меня
 DK> такое чувство, что вполне себе может случится обратное: зависимость
 DK> есть, а компилятор её не обнаружил, и решил что-нибудь
 DK> соптимизировать. В этом случае мне кажется, чем тупее система -- тем
 DK> лучше.

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

Он же работает по схеме "для вычисления вот этого мне нужно вот это, вот
это и вот это.  Где я их возьму?"  А если ему в процессе этого выяснения
что-то _не_ понадобилось, то от него зависимости нет по построению.

 >>  DK> Зачем это нужно? Ну, бывают разные случаи.
 >>
 >>  DK> Бывает, что это повышает производительность. В случае большого словаря
 >>  DK> создание его дубликата при изменении значения одного ключа создаёт 
 >> очень
 >>  DK> большие накладные расходы.
 >>
 >> Это, как я уже писал, вопрос не императивности, а мутабельности.  Нам,
 >> вообще говоря, совершенно незачем выполнять строго последовательно
 >> изменения значений у двух разных ключей.

 DK> Извините, у меня в мозгу императивность и мутабельность неразрывно
 DK> связаны. Объясните, почему Вы разделяете их? Мутабельность -- это
 DK> возможность объекта менять состояние. Императивность -- стиль
 DK> программирования, при котором программа проходит через
 DK> последовательность состояний.

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

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

Каждое изменение производится локально, но имеет неопределенные
последствия при взгляде из точки изменения.

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

Мы хотим, чтобы вот тут было вот так.  Для этого надо взять вот это и
вот это и вот так их скомбинировать.  Вот это можно получить вот так...

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

А так мутировать-то мы его мутируем...

 >> Хаскель, кстати, будет делать дубликат не всего словаря, а только той
 >> ветки, в которой поменяли значение.  Для, допустим, Map это O(log n).

 DK> Ну и таки да, Хаскель не будет делать дубликат словаря, ибо эти "разницы
 DK> между исходной версией и данной" для него суть thunk-и, и это одно из
 DK> полезных следствий ленивости.

Нет, не поэтому.  Когда он вычислит эти thunk'и, у него появится shared
structure.  Потому что остальной словарь не затронут, и его можно
использовать as is, копия не требуется.

 DK> Но тут мы вроде бы занимались выяснением вопроса "почему иногда
 DK> императив всё-таки нужен".

А выяснили пока что, зачем _в некоторых очень отдельных местах_ нужна
мутабельность.  Причем если рассмотреть задачу в целом, внезапно
выяснится, что целиком мутабельный словарь выгоднее только в сферическом
случае в вакууме, когда к нему обращаются (и на изменение, и на чтение)
строго последовательно.  Иначе всю выгоду от более быстрого изменения
может сожрать обеспечение консистентности.

 >>  DK> Бывает, что это упрощает описание алгоритма. Например, если Вы
 >>  DK> реализуете программу, алгоритм которой описан в императивном стиле в
 >>  DK> некоторой 

Re: Стабильная система?

[Артём Н.]

On 16.10.2015 16:46, Artem Chuprina wrote:

Артём Н. -> debian-russian@lists.debian.org  @ Fri, 16 Oct 2015 16:04:15 +0300:

  АН> Хосспади, OCaml... o.O
  АН> Может, когда требуется "большой кусок в императивном стиле",
  АН> следует отказаться от использования функционального языка в сторону 
императивного?
  АН> Или религия не позволяет? ;-)

А смысл, если есть язык, который это позволяет прямо тут?  Ocaml,
насколько я понимаю, ничем не плох.

"Большой кусок в императивном стиле" может иметь разный размер.
Смысл в том, чтобы молотком забивать гвозди, а под микроскопом рассматривать 
нечто под увеличением.
Конечно, возможно на молоток линзу приделать, но зачем?

Re: Стабильная система?

[Artem Chuprina]

Vladimir Zhbanov -> debian-russian@lists.debian.org  @ Fri, 16 Oct 2015 
18:51:37 +0300:

 >> Я иногда тоже хочу параметров по умолчанию, но сильно подозреваю, что
 >> это пережиток языков с duck typing.  На практике, учитывая, что язык
 >> компилируемый, всегда можно либо добавить пару параметров и поменять все
 >> (найденные компилятором) вхождения вызовов, добавив туда дефолтные
 >> значения, либо, что чаще, одновременно со вводом дополнительных
 >> параметров переименовать функцию, а старое имя определить как
 >> каррирование нового.
 VZ> А что если параметров десяток-два?

Тогда кто-то что-то делает не так.

 VZ> И, прошу прощения за невежество, что в языках с duck typing хуже по
 VZ> сравнению с языками со статической типизацией, если не считать размер
 VZ> объектного кода из-за проверок типа? Не знаю за другие языки (и даже за
 VZ> другие лиспы), дюже не пробовал, но в guile scheme (который я пытаюсь
 VZ> начать осваивать в последние пару лет) вопрос размера объектного кода
 VZ> сейчас во многом решается на этапе прекомпиляции (если я правильно понял
 VZ> одного из авторов), причём работа в этом направлении идёт масштабная.

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

 >>  DK> Сейчас я работаю в основном на Racket Scheme, Emacs/Common Lisps и
 >>  DK> Ocaml. Последний выглядит для меня примерно как Haskell, только без
 >>  DK> ленивости. Синтаксис выразительный, но логика вычислений проще 
 >> поддаётся
 >>  DK> осмыслению, и дебаг также не вызывает трудностей.
 >> 
 >> Мозги разные?  Для меня логика вычислений на хаскеле на порядок (по
 >> основанию явно больше 2, но не 10) проще для осмысления.  Именно в силу
 >> функциональности.  Ведь императивный алгоритм - это инструкции для
 VZ> Ээээмм, ещё раз прошу прощения... А разве названные языки не- (недо-?)
 VZ> функциональные?

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

Re: Стабильная система?

[Dmitrii Kashin]

Vladimir Zhbanov  writes:

> On Fri, Oct 16, 2015 at 01:33:51AM +0300, Artem Chuprina wrote:
>
> И, прошу прощения за невежество, что в языках с duck typing хуже по
> сравнению с языками со статической типизацией, если не считать размер
> объектного кода из-за проверок типа?

Ну, тут есть много мнений, но самое существенное -- возможность выявить
проблему во время компиляции, а не в рантайме. Это, кстати, палка о двух
концах. Для прототипирования удобнее использовать языки не строго
типизированные, потому что Вы потратите меньше времени на то, чтобы
"договориться" с компилятором о том, какие типы уместны при вызове
данной функции. Но тогда надо иметь в виду, что всякие граничные случаи
могут давать ошибки. И тогда на сцену выходит статическая типизация,
которая просто не даст проекту скомпилироваться, если Вы в каком-то
месте пытаетесь подсунуть в функцию значение несоответствующего типа.

> Не знаю за другие языки (и даже за другие лиспы), дюже не пробовал, но
> в guile scheme (который я пытаюсь начать осваивать в последние пару
> лет) вопрос размера объектного кода сейчас во многом решается на этапе
> прекомпиляции (если я правильно понял одного из авторов), причём
> работа в этом направлении идёт масштабная.

Какая бы там работа не шла, проблема не в размере кода, и даже не в
производительности. Вопрос лишь в том, когда выявляются ошибки. И это
важно, если Вы намерены отдавать программу в продакшн.

> ...
>>  DK> Сейчас я работаю в основном на Racket Scheme, Emacs/Common Lisps и
>>  DK> Ocaml. Последний выглядит для меня примерно как Haskell, только без
>>  DK> ленивости. Синтаксис выразительный, но логика вычислений проще поддаётся
>>  DK> осмыслению, и дебаг также не вызывает трудностей.
>> 
>> Мозги разные?  Для меня логика вычислений на хаскеле на порядок (по
>> основанию явно больше 2, но не 10) проще для осмысления.  Именно в силу
>> функциональности.  Ведь императивный алгоритм - это инструкции для
>
> Ээээмм, ещё раз прошу прощения... А разве названные языки не- (недо-?)
> функциональные?

Они мультипарадигменные. Позволяют писать в обоих
стилях. Функциональный, само собой, поощряется.


signature.asc
Description: PGP signature

Re: Стабильная система?

[Vladimir Zhbanov]

On Fri, Oct 16, 2015 at 09:43:25PM +0300, Artem Chuprina wrote:
> Vladimir Zhbanov -> debian-russian@lists.debian.org  @ Fri, 16 Oct 2015 
> 18:51:37 +0300:
> 
>  >> Я иногда тоже хочу параметров по умолчанию, но сильно подозреваю, что
>  >> это пережиток языков с duck typing.  На практике, учитывая, что язык
>  >> компилируемый, всегда можно либо добавить пару параметров и поменять все
>  >> (найденные компилятором) вхождения вызовов, добавив туда дефолтные
>  >> значения, либо, что чаще, одновременно со вводом дополнительных
>  >> параметров переименовать функцию, а старое имя определить как
>  >> каррирование нового.
>  VZ> А что если параметров десяток-два?
> 
> Тогда кто-то что-то делает не так.
Ожидаемый общий ответ. Типичный пример про кучу параметров, например, в
документации guile, он про графическое иксовое окошко, написанное хз на
чём, ну, скажем, на gtk, которое имеет кучу параметров только иксовых.
Или, например, взять тот же xrandr. Что если кто-то захочет сделать его
функцией для использования в модуле для какой-то графической хрени. Я не
буду приводить свои более спицфицкие примеры, но вот это -- такое
использование -- неправильно? Ты считаешь, правильно делать кучу функций
для каждой отдельной ерунды? Или таки вызвать 'такое окошко шириной
столько-то и высотой столько-то, со всеми остальными параметрами по
умолчанию' допустимо на твой взгляд? (Не, сразу оговорюсь, я здесь ни
разу не хочу спорить о том, кто должен решать размер окна, юзер или wm,
это о другом, есличо.)

> 
>  VZ> И, прошу прощения за невежество, что в языках с duck typing хуже по
>  VZ> сравнению с языками со статической типизацией, если не считать размер
>  VZ> объектного кода из-за проверок типа? Не знаю за другие языки (и даже за
>  VZ> другие лиспы), дюже не пробовал, но в guile scheme (который я пытаюсь
>  VZ> начать осваивать в последние пару лет) вопрос размера объектного кода
>  VZ> сейчас во многом решается на этапе прекомпиляции (если я правильно понял
>  VZ> одного из авторов), причём работа в этом направлении идёт масштабная.
> 
> Основная проблема заключается в том, что почти любая проблема выявляется
> только в рантайме.  Как раз размер объектного кода чем дальше, тем
> меньше важен.  А вот время на разработку...
Ага, понял, спасибо.  Таки ты считаешь си++ лучше лиспов в отношении
времени на разработку (из-за статической типизации; не говорю про
обычный си, искал, но не нашёл его в списках языков ни с динамической,
ни со статической типизацией; каюсь, ленивый, смотрел только в
"авторитетной" википедии)? Или сие касается только Haskel vs 'все
остальные'?

Re: Стабильная система?

[Vladimir Zhbanov]

On Fri, Oct 16, 2015 at 10:14:10PM +0300, Dmitrii Kashin wrote:
...
> > Не знаю за другие языки (и даже за другие лиспы), дюже не пробовал, но
> > в guile scheme (который я пытаюсь начать осваивать в последние пару
> > лет) вопрос размера объектного кода сейчас во многом решается на этапе
> > прекомпиляции (если я правильно понял одного из авторов), причём
> > работа в этом направлении идёт масштабная.
> 
> Какая бы там работа не шла, проблема не в размере кода, и даже не в
> производительности. Вопрос лишь в том, когда выявляются ошибки. И это
> важно, если Вы намерены отдавать программу в продакшн.
Ну, как говорит одна русская пословица, продакшн продакшну рознь. Я, к
примеру, работаю (не смог подобрать здесь слова лучше) над одним
FOSS-проектом. И в нашем комьюнити (не смог подобрать здесь слова
лучше) постоянно висят крики типа "ну вас с вашим дурацким ским/лиспом,
си форевер, или накрайняк хотим питону". Повторюсь, я недавно начал
знакомиться с Scheme. И вот, когда смотришь "этот статический C-код"...
Не, плакать не хочется... Хочется плюнуть, и бросить всё это безнадёжное
дело. Но совесть не позволяет :) И да, ошибки стараемся ловить тестами,
несмотря на (кашу в головах и коде). И как всё это превратить в систему,
где ошибки выявляются на этапе компиляции..., я просто представить не
могу.

> 
> > ...
> >>  DK> Сейчас я работаю в основном на Racket Scheme, Emacs/Common Lisps и
> >>  DK> Ocaml. Последний выглядит для меня примерно как Haskell, только без
> >>  DK> ленивости. Синтаксис выразительный, но логика вычислений проще 
> >> поддаётся
> >>  DK> осмыслению, и дебаг также не вызывает трудностей.
> >> 
> >> Мозги разные?  Для меня логика вычислений на хаскеле на порядок (по
> >> основанию явно больше 2, но не 10) проще для осмысления.  Именно в силу
> >> функциональности.  Ведь императивный алгоритм - это инструкции для
> >
> > Ээээмм, ещё раз прошу прощения... А разве названные языки не- (недо-?)
> > функциональные?
> 
> Они мультипарадигменные. Позволяют писать в обоих
Хорошее слово, запишу в свою книжечку...

> стилях. Функциональный, само собой, поощряется.

Re: Стабильная система?

[Dmitrii Kashin]

Artem Chuprina  writes:

> Dmitrii Kashin -> debian-russian@lists.debian.org  @ Thu, 15 Oct 2015 
> 21:49:30 +0300:
>
>  >>  DK> За время работы с ним меня приятно удивило после Haskell:
>  >>
>  >>  DK> 1) Позволяет более просто комбинировать функциональное и императивное
>  >>  DK> программирование: не надо изворачиваться монадами, чтобы добиться
>  >>  DK> последовательного выполнения команд.
>  >>
>  >> ...
>  >>
>  >> а зачем, собственно, добиваться последовательного выполнения никак не
>  >> связанных между собой команд?
>
>  DK> Я думаю, тут есть недоразумение. Требование последовательного выполнения
>  DK> определённых команд как раз и определяет связь между ними. Если конечно
>  DK> не считать, что связь -- это "результат А нужен для вычисления B". Тут
>  DK> важно понять, что императивное программирование -- это именно
>  DK> программирование с изменением состояния системы.
>
> Тогда это, натурально, связанные между собой команды.  Для вычисления B
> требуется состояние системы, полученное после вычисления A.
>
> Хаскельный компилятор просто более аккуратно подходит к вопросу
> зависимости (он машина, ему внимания не жалко), и может обнаружить
> независимость там, где программист ее не обнаружил, и по умолчанию
> полагает, что зависимость есть.

Теоретически это наверное плюс. Но мне бы реальных ситуаций. У меня
такое чувство, что вполне себе может случится обратное: зависимость
есть, а компилятор её не обнаружил, и решил что-нибудь
соптимизировать. В этом случае мне кажется, чем тупее система -- тем
лучше.

>  DK> Зачем это нужно? Ну, бывают разные случаи.
>
>  DK> Бывает, что это повышает производительность. В случае большого словаря
>  DK> создание его дубликата при изменении значения одного ключа создаёт очень
>  DK> большие накладные расходы.
>
> Это, как я уже писал, вопрос не императивности, а мутабельности.  Нам,
> вообще говоря, совершенно незачем выполнять строго последовательно
> изменения значений у двух разных ключей.

Извините, у меня в мозгу императивность и мутабельность неразрывно
связаны. Объясните, почему Вы разделяете их? Мутабельность -- это
возможность объекта менять состояние. Императивность -- стиль
программирования, при котором программа проходит через
последовательность состояний.

> Хаскель, кстати, будет делать дубликат не всего словаря, а только той
> ветки, в которой поменяли значение.  Для, допустим, Map это O(log n).

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

>  DK> Бывает, что это упрощает описание алгоритма. Например, если Вы
>  DK> реализуете программу, алгоритм которой описан в императивном стиле в
>  DK> некоторой статье, то логично пользоваться тем же представлением, что и
>  DK> автор.
>
> Ну, тут да.  Тут, действительно, может выясниться, что один в один
> перевести сложнонавороченный цикл на монадную схему... не то чтобы
> сложно, но получается менее удобочитаемо.  С другой стороны, ну, пишем
> наскоро EDSL под псевдокод из статьи, и вперед.  Зефиров рассказывал,
> что для какой-то довольно серьезной задачи он делал императивный даже не
> EDSL, а просто DSL, и транслировал его в хаскель.

Ну, в принципе, создание EDSL -- это метод. Но это, как я понимаю, в
основном прерогатива Lisp-ов. Там они органичны более-менее. (Хотя это
смотря где ещё. Вот гигиенические макросы из Scheme на меня тоску
наводят). А как в Haskell с расширением синтаксиса?

>  DK> Бывает, что без этого обойтись невозможно. Такое случается, когда Ваша
>  DK> программа должна некоторым образом взаимодействовать со внешней
>  DK> средой. Вот пишете Вы, допустим, сборочную систему, и Вам принципиально
>  DK> важно, чтобы были выполнены последовательно сначала git clone, а потом
>  DK> git checkout.
>
> Это система с изменением состояния - "не склонировано", "склонировано",
> "извлечено".  git checkout можно делать из состояния "склонировано", а
> откуда и когда оно взялось, в этом месте неважно.  А берется оно из
> завершения git clone (это состояние RealWorld)...
>
> Система зависимостей тут как раз может гарантировать консистентность
> вытащенного, потому что, если копать дальше, для выполнения git clone
> надо, чтобы место было чистое - и вызывается команда приведения места в
> чистое состояние...

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

Что ж, возможно, тут есть свои подходы. Вот об этом-то и надо бы писать
в книжках.

>  DK> Но вот сейчас я вспомнил, чего я действительно не видел в Haskell, и что
>  DK> очень облегчает мне жизнь сейчас. Это опциональные аргументы при
>  DK> сопутствующих полноценных возможностях каррирования.
>
>  DK> ...
>
> Я иногда тоже хочу 

Re: Стабильная система?

[Artem Chuprina]

Артём Н. -> debian-russian@lists.debian.org  @ Fri, 16 Oct 2015 16:04:15 +0300:

 АН> Хосспади, OCaml... o.O
 АН> Может, когда требуется "большой кусок в императивном стиле",
 АН> следует отказаться от использования функционального языка в сторону 
императивного?
 АН> Или религия не позволяет? ;-)

А смысл, если есть язык, который это позволяет прямо тут?  Ocaml,
насколько я понимаю, ничем не плох.

  1) Позволяет более просто комбинировать функциональное и императивное
  программирование: не надо изворачиваться монадами, чтобы добиться
  последовательного выполнения команд.
 
 >>> Но зачем?
 >>
 >> "This is no matter of religion or esthetics; a priori neither style is
 >> prettier or holier than the other. On the contrary, one style may be
 >> more adequate than the other depending on the problem to be solved.
 >>
 >> The first rule to apply is the rule of simplicity. Whether the algorithm
 >> to use implemented is written in a book, or whether its seed is in the
 >> mind of the programmer, the algorithm is itself described in a certain
 >> style. It is natural to use the same style when implementing it.
 >>
 >> The second criterion of choice is the efficiency of the program. One may
 >> say that an imperative program (if well written) is more efficient that
 >> its functional analogue, but in very many cases the difference is not
 >> enough to justify complicating the code to adopt an imperative style
 >> where the functional style would be natural". [1]
 >>
 >> Бывает, что императивное программирование разумнее. Большинство
 >> алгоритмов можно писать в функциональном стиле, но бывает и так, что это
 >> порождает большой оверхед в производительности. При столкновении с
 >> подобным "узким горлом" приходится реализовывать часть функционала в
 >> императивном стиле. Например, управление большими словарями много
 >> выгоднее, если они мутабельны.
 >>
 >> [1] http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora038.html
 >>

Re: Стабильная система?

[Артём Н.]

Хосспади, OCaml... o.O
Может, когда требуется "большой кусок в императивном стиле",
следует отказаться от использования функционального языка в сторону 
императивного?
Или религия не позволяет? ;-)

On 15.10.2015 21:02, Dmitrii Kashin wrote:



1) Позволяет более просто комбинировать функциональное и императивное
программирование: не надо изворачиваться монадами, чтобы добиться
последовательного выполнения команд.


Но зачем?


"This is no matter of religion or esthetics; a priori neither style is
prettier or holier than the other. On the contrary, one style may be
more adequate than the other depending on the problem to be solved.

The first rule to apply is the rule of simplicity. Whether the algorithm
to use implemented is written in a book, or whether its seed is in the
mind of the programmer, the algorithm is itself described in a certain
style. It is natural to use the same style when implementing it.

The second criterion of choice is the efficiency of the program. One may
say that an imperative program (if well written) is more efficient that
its functional analogue, but in very many cases the difference is not
enough to justify complicating the code to adopt an imperative style
where the functional style would be natural". [1]

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

[1] http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora038.html

Re: Стабильная система?

[Vladimir Zhbanov]

On Fri, Oct 16, 2015 at 01:33:51AM +0300, Artem Chuprina wrote:
...
> Я иногда тоже хочу параметров по умолчанию, но сильно подозреваю, что
> это пережиток языков с duck typing.  На практике, учитывая, что язык
> компилируемый, всегда можно либо добавить пару параметров и поменять все
> (найденные компилятором) вхождения вызовов, добавив туда дефолтные
> значения, либо, что чаще, одновременно со вводом дополнительных
> параметров переименовать функцию, а старое имя определить как
> каррирование нового.
А что если параметров десяток-два?

И, прошу прощения за невежество, что в языках с duck typing хуже по
сравнению с языками со статической типизацией, если не считать размер
объектного кода из-за проверок типа? Не знаю за другие языки (и даже за
другие лиспы), дюже не пробовал, но в guile scheme (который я пытаюсь
начать осваивать в последние пару лет) вопрос размера объектного кода
сейчас во многом решается на этапе прекомпиляции (если я правильно понял
одного из авторов), причём работа в этом направлении идёт масштабная.

...
>  DK> Сейчас я работаю в основном на Racket Scheme, Emacs/Common Lisps и
>  DK> Ocaml. Последний выглядит для меня примерно как Haskell, только без
>  DK> ленивости. Синтаксис выразительный, но логика вычислений проще поддаётся
>  DK> осмыслению, и дебаг также не вызывает трудностей.
> 
> Мозги разные?  Для меня логика вычислений на хаскеле на порядок (по
> основанию явно больше 2, но не 10) проще для осмысления.  Именно в силу
> функциональности.  Ведь императивный алгоритм - это инструкции для
Ээээмм, ещё раз прошу прощения... А разве названные языки не- (недо-?)
функциональные?

Re: Стабильная система?

[Dmitrii Kashin]

Vladimir Zhbanov  writes:

> И в нашем комьюнити (не смог подобрать здесь слова лучше) постоянно
> висят крики типа "ну вас с вашим дурацким ским/лиспом, си форевер, или
> накрайняк хотим питону".

Есть два типа языков программирования. На которые все ругаются -- раз,
которыми никто не пользуется -- два. :)

Это у Вас ещё слабое противостояние. Си против лиспов не тянет
совершенно: если постараетесь, заткнёте оппонентов за пояс. Дело плохо,
когда какие-нибудь фанатики начинают дебаты типа "Racket vs Clojure" или
"Ocaml vs Scala". В таких случаях лучше отойти в сторонку, ибо разговор
неизбежно сведётся к плюсам и минусам JVM. :)

> Повторюсь, я недавно начал знакомиться с Scheme. И вот, когда смотришь
> "этот статический C-код"...  Не, плакать не хочется... Хочется
> плюнуть, и бросить всё это безнадёжное дело.

Да, первое впечатление от Лиспов, оно такое. Но Вы не обольщайтесь. У
нас есть куча своих проблем. Как говорил Ф. Брукс: "серебряной пули
нет".



signature.asc
Description: PGP signature

Re: Стабильная система?

[Artem Chuprina]

Vladimir Zhbanov -> debian-russian@lists.debian.org  @ Fri, 16 Oct 2015 
23:29:10 +0300:

 >>  >> Я иногда тоже хочу параметров по умолчанию, но сильно подозреваю, что
 >>  >> это пережиток языков с duck typing.  На практике, учитывая, что язык
 >>  >> компилируемый, всегда можно либо добавить пару параметров и поменять все
 >>  >> (найденные компилятором) вхождения вызовов, добавив туда дефолтные
 >>  >> значения, либо, что чаще, одновременно со вводом дополнительных
 >>  >> параметров переименовать функцию, а старое имя определить как
 >>  >> каррирование нового.
 >>  VZ> А что если параметров десяток-два?
 >> 
 >> Тогда кто-то что-то делает не так.
 VZ> Ожидаемый общий ответ. Типичный пример про кучу параметров, например, в
 VZ> документации guile, он про графическое иксовое окошко, написанное хз на
 VZ> чём, ну, скажем, на gtk, которое имеет кучу параметров только иксовых.
 VZ> Или, например, взять тот же xrandr. Что если кто-то захочет сделать его
 VZ> функцией для использования в модуле для какой-то графической хрени. Я не
 VZ> буду приводить свои более спицфицкие примеры, но вот это -- такое
 VZ> использование -- неправильно? Ты считаешь, правильно делать кучу функций
 VZ> для каждой отдельной ерунды? Или таки вызвать 'такое окошко шириной
 VZ> столько-то и высотой столько-то, со всеми остальными параметрами по
 VZ> умолчанию' допустимо на твой взгляд? (Не, сразу оговорюсь, я здесь ни
 VZ> разу не хочу спорить о том, кто должен решать размер окна, юзер или wm,
 VZ> это о другом, есличо.)

Ну, такое я на хаскеле делаю регулярно.  Это один _комплект_ параметров,
под него заводится тип записи, у нее есть дефолтное значение, и ему при
необходимости модифицируются поля.

 >>  VZ> И, прошу прощения за невежество, что в языках с duck typing хуже по
 >>  VZ> сравнению с языками со статической типизацией, если не считать размер
 >>  VZ> объектного кода из-за проверок типа? Не знаю за другие языки (и даже за
 >>  VZ> другие лиспы), дюже не пробовал, но в guile scheme (который я пытаюсь
 >>  VZ> начать осваивать в последние пару лет) вопрос размера объектного кода
 >>  VZ> сейчас во многом решается на этапе прекомпиляции (если я правильно 
 >> понял
 >>  VZ> одного из авторов), причём работа в этом направлении идёт масштабная.
 >> 
 >> Основная проблема заключается в том, что почти любая проблема выявляется
 >> только в рантайме.  Как раз размер объектного кода чем дальше, тем
 >> меньше важен.  А вот время на разработку...
 VZ> Ага, понял, спасибо.  Таки ты считаешь си++ лучше лиспов в отношении
 VZ> времени на разработку (из-за статической типизации; не говорю про
 VZ> обычный си, искал, но не нашёл его в списках языков ни с динамической,
 VZ> ни со статической типизацией; каюсь, ленивый, смотрел только в
 VZ> "авторитетной" википедии)? Или сие касается только Haskel vs 'все
 VZ> остальные'?

Говоря "почти любая", я имею в виду все-таки высокоуровневый язык с
богатой системой типов.  C++ слишком низкоуровневый, чтобы сравнивать
его с лиспом.  То есть в смысле статической проверки типов он да, лучше,
но его оверхед на выражение мысли возвращает его обратно к ассемблерам
:)

Re: Стабильная система?

[Artem Chuprina]

Dmitrii Kashin -> debian-russian@lists.debian.org  @ Thu, 15 Oct 2015 21:49:30 
+0300:

 >>  DK> За время работы с ним меня приятно удивило после Haskell:
 >>
 >>  DK> 1) Позволяет более просто комбинировать функциональное и императивное
 >>  DK> программирование: не надо изворачиваться монадами, чтобы добиться
 >>  DK> последовательного выполнения команд.
 >>
 >> ...
 >>
 >> а зачем, собственно, добиваться последовательного выполнения никак не
 >> связанных между собой команд?

 DK> Я думаю, тут есть недоразумение. Требование последовательного выполнения
 DK> определённых команд как раз и определяет связь между ними. Если конечно
 DK> не считать, что связь -- это "результат А нужен для вычисления B". Тут
 DK> важно понять, что императивное программирование -- это именно
 DK> программирование с изменением состояния системы.

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

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

 DK> Зачем это нужно? Ну, бывают разные случаи.

 DK> Бывает, что это повышает производительность. В случае большого словаря
 DK> создание его дубликата при изменении значения одного ключа создаёт очень
 DK> большие накладные расходы.

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

Хаскель, кстати, будет делать дубликат не всего словаря, а только той
ветки, в которой поменяли значение.  Для, допустим, Map это O(log n).

 DK> Бывает, что это упрощает описание алгоритма. Например, если Вы
 DK> реализуете программу, алгоритм которой описан в императивном стиле в
 DK> некоторой статье, то логично пользоваться тем же представлением, что и
 DK> автор.

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

 DK> Бывает, что без этого обойтись невозможно. Такое случается, когда Ваша
 DK> программа должна некоторым образом взаимодействовать со внешней
 DK> средой. Вот пишете Вы, допустим, сборочную систему, и Вам принципиально
 DK> важно, чтобы были выполнены последовательно сначала git clone, а потом
 DK> git checkout.

Это система с изменением состояния - "не склонировано", "склонировано",
"извлечено".  git checkout можно делать из состояния "склонировано", а
откуда и когда оно взялось, в этом месте неважно.  А берется оно из
завершения git clone (это состояние RealWorld)...

Система зависимостей тут как раз может гарантировать консистентность
вытащенного, потому что, если копать дальше, для выполнения git clone
надо, чтобы место было чистое - и вызывается команда приведения места в
чистое состояние...

 >>  DK> 2) Позволяет таки определять полиморфные функции. Да, это нарушение
 >>  DK> системы типов, но если этим не злоупотреблять, то это даже удобно.
 >>
 >> Какого именно вида полиморфных функций?  В хаскеле их минимум два (а с
 >> generics, пожалуй, и все три).

 DK> Прошу прощения, ошибся. Я уже начал подзабывать Haskell. Да, в Haskell
 DK> есть полиморфные функции.

 DK> Но вот сейчас я вспомнил, чего я действительно не видел в Haskell, и что
 DK> очень облегчает мне жизнь сейчас. Это опциональные аргументы при
 DK> сопутствующих полноценных возможностях каррирования.

 DK> Мне вот достался в наследство проект, который в виду крайне сумбурного
 DK> развития имеет ужасную архитектуру, и работает с горем
 DK> пополам. Благодаря возможности описания опциональных аргументов у
 DK> функций, я могу дополнять их функционалом, не меняя при этом их
 DK> поведения в старом коде.

 DK> По поводу каррирования, то вот к примеру можно определить функцию со
 DK> двумя опциональными аргументами:

 DK> let funA ?a ?(b=1) c = match a with
 DK>   | None -> b*c;
 DK>   | Some a -> a+b*c

 DK> И после этого каррировать её вот так:\

 DK> let funB = funA ~a:None ~b:2

 DK> При этом "funB 1" будет эквивалентна "funA ~b:2 1"

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

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

Re: Стабильная система?

[Dmitrii Kashin]

>> 1) Позволяет более просто комбинировать функциональное и императивное
>> программирование: не надо изворачиваться монадами, чтобы добиться
>> последовательного выполнения команд.
>>
> Но зачем?

"This is no matter of religion or esthetics; a priori neither style is
prettier or holier than the other. On the contrary, one style may be
more adequate than the other depending on the problem to be solved.

The first rule to apply is the rule of simplicity. Whether the algorithm
to use implemented is written in a book, or whether its seed is in the
mind of the programmer, the algorithm is itself described in a certain
style. It is natural to use the same style when implementing it.

The second criterion of choice is the efficiency of the program. One may
say that an imperative program (if well written) is more efficient that
its functional analogue, but in very many cases the difference is not
enough to justify complicating the code to adopt an imperative style
where the functional style would be natural". [1]

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

[1] http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora038.html


signature.asc
Description: PGP signature

Re: Стабильная система?

[Artem Chuprina]

Dmitrii Kashin -> debian-russian@lists.debian.org  @ Thu, 15 Oct 2015 21:02:49 
+0300:

 >>> 1) Позволяет более просто комбинировать функциональное и императивное
 >>> программирование: не надо изворачиваться монадами, чтобы добиться
 >>> последовательного выполнения команд.
 >>>
 >> Но зачем?

 DK> "This is no matter of religion or esthetics; a priori neither style is
 DK> prettier or holier than the other. On the contrary, one style may be
 DK> more adequate than the other depending on the problem to be solved.

 DK> The first rule to apply is the rule of simplicity. Whether the algorithm
 DK> to use implemented is written in a book, or whether its seed is in the
 DK> mind of the programmer, the algorithm is itself described in a certain
 DK> style. It is natural to use the same style when implementing it.

 DK> The second criterion of choice is the efficiency of the program. One may
 DK> say that an imperative program (if well written) is more efficient that
 DK> its functional analogue, but in very many cases the difference is not
 DK> enough to justify complicating the code to adopt an imperative style
 DK> where the functional style would be natural". [1]

 DK> Бывает, что императивное программирование разумнее. Большинство
 DK> алгоритмов можно писать в функциональном стиле, но бывает и так, что это
 DK> порождает большой оверхед в производительности. При столкновении с
 DK> подобным "узким горлом" приходится реализовывать часть функционала в
 DK> императивном стиле. Например, управление большими словарями много
 DK> выгоднее, если они мутабельны.

Было бы клево еще не путать императивность с мутабельностью...

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

Но в любом случае последовательное выполнение команд, даже в
императивном случае - не цель, а в лучшем случае средство.  Зачем его
отдельно добиваться?

Re: Стабильная система?

[Dmitrii Kashin]

Artem Chuprina  writes:

> Dmitrii Kashin -> debian-russian@lists.debian.org  @ Wed, 07 Oct 2015 
> 02:07:07 +0300:
>
>  DK> За время работы с ним меня приятно удивило после Haskell:
>
>  DK> 1) Позволяет более просто комбинировать функциональное и императивное
>  DK> программирование: не надо изворачиваться монадами, чтобы добиться
>  DK> последовательного выполнения команд.
>
> ...
>
> а зачем, собственно, добиваться последовательного выполнения никак не
> связанных между собой команд?

Я думаю, тут есть недоразумение. Требование последовательного выполнения
определённых команд как раз и определяет связь между ними. Если конечно
не считать, что связь -- это "результат А нужен для вычисления B". Тут
важно понять, что императивное программирование -- это именно
программирование с изменением состояния системы.

Зачем это нужно? Ну, бывают разные случаи.

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

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

Бывает, что без этого обойтись невозможно. Такое случается, когда Ваша
программа должна некоторым образом взаимодействовать со внешней
средой. Вот пишете Вы, допустим, сборочную систему, и Вам принципиально
важно, чтобы были выполнены последовательно сначала git clone, а потом
git checkout.

>  DK> 2) Позволяет таки определять полиморфные функции. Да, это нарушение
>  DK> системы типов, но если этим не злоупотреблять, то это даже удобно.
>
> Какого именно вида полиморфных функций?  В хаскеле их минимум два (а с
> generics, пожалуй, и все три).

Прошу прощения, ошибся. Я уже начал подзабывать Haskell. Да, в Haskell
есть полиморфные функции.

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

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

По поводу каррирования, то вот к примеру можно определить функцию со
двумя опциональными аргументами:

let funA ?a ?(b=1) c = match a with
  | None -> b*c;
  | Some a -> a+b*c

И после этого каррировать её вот так:\

let funB = funA ~a:None ~b:2

При этом "funB 1" будет эквивалентна "funA ~b:2 1"

Вот тут ещё можно посмотреть очень интересное мнение:
http://blog.ezyang.com/2010/10/ocaml-for-haskellers/

>  DK> Я в своё время с Вашей подачи пытался взять Haskell наскоком. Увы, он
>  DK> меня расстроил по целому ряду причин. Если хотите, могу рассказать.
>
> Было бы интересно.  Я его и сам осваивал небыстро, и кое-что открываю в
> нем до сих пор, пятый год уже.  (Кое-что из этого, впрочем, и
> появилось-то в этом году.)

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



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

В то время язык оказался неподходящим. Я, конечно, разработал чисто
функциональные алгоритмы, которые сильно упростили мне проектирование
будущих версий программы, но я столкнулся вот с чем:

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

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

Промучившись с этим делом полгода, я отошёл от этой задачи в сторону
Common Lisp'а, который хотя и динамически типизирован, сэкономил мне
кучу времени макросами и приличным FFI-ем (как подружить с которым
Haskell я понятья не имею, ибо опять же, ленивость).

Сейчас я работаю в основном на Racket Scheme, Emacs/Common Lisps и
Ocaml. Последний выглядит для меня примерно как Haskell, только без
ленивости. Синтаксис выразительный, но логика вычислений проще поддаётся
осмыслению, и дебаг также не вызывает трудностей.

> Я Вам открою, наверное, страшную тайну: в хаскеле вообще невозможно
> добиться последовательного выполнения команд, кроме как через
> зависимость "результат A нужен для вычисления B".  В монадах на сей
> предмет нет ничего волшебного.  Даже в монаде IO.  Я когда-то, посмотрев
> на ее реализацию и осознав, что она такое, ухитрился даже нарисовать
> тест, который это демонстрировал.

Ну, вот видите. Принудительная ленивость по умолчанию порождает 

Re: Стабильная система?

[Артём Н.]

Ok, если оффтоп, так полный.

On 07.10.2015 02:07, Dmitrii Kashin wrote:

Artem Chuprina  writes:


Артём Н. -> debian-russian@lists.debian.org  @ Mon, 28 Sep 2015 10:37:48 +0300:

  АН> Offtopic:
  АН> А что кто-то реально использует Haskell?

Да.  И на данный момент я его считаю лучшим вариантом по соотношению
затрат на разработку и уверенности в результате, с БОЛЬШИМ отрывом от
конкурентов.


Я хотел бы высказать сомнение в большом отрыве Haskell от
Ocaml. Последний видится мне весьма живым проектом.

За время работы с ним меня приятно удивило после Haskell:

1) Позволяет более просто комбинировать функциональное и императивное
программирование: не надо изворачиваться монадами, чтобы добиться
последовательного выполнения команд.


Но зачем?


2) Позволяет таки определять полиморфные функции. Да, это нарушение
системы типов, но если этим не злоупотреблять, то это даже удобно.


Я в своё время с Вашей подачи пытался взять Haskell наскоком. Увы, он
меня расстроил по целому ряду причин. Если хотите, могу рассказать.


Короче, тут сплошные функциональщики, я себя ощущаю неполноценным C-шником. :-)

Знаю, что :[|||]:, но:
'— Ты функциональщик! - прокричал Сергей на весь оупен-спейс-рум номер 14.
Комната притихла в ожидании развязки.
— Я видел, как ты вчера вечером каррировал и декаррировал прямо за рабочим 
компьютером!
Неодобрительный ропот и возгласы удивления прокатились по комнате.
Кто-то громким шепотом сказал "какой ужас, а я с ним за руку здоровался".
— Знаешь что, Сергей, — сказал Денис, вставая из-за рабочего стола, — любой 
нормальный мужчина,
если у него всё в порядке, может позволить себе позаниматься функциональным 
программированием.
Это естественно. Каждый хотя бы раз, да пробовал. Зачем только об этом кричать 
на всю комнату?
Я же не кричу, что ты объектно-ориентированный!
Девушки захихикали, кто-то снова громко пробормотал "ну надо же, а по нему и не 
скажешь".
Присутствовавший при этом Игорь Матвеевич сильнее вжался в кресло. Только бы 
никто не
узнал про его процедурные наклонности!'

%-)

Re: Стабильная система?

[Artem Chuprina]

Dmitrii Kashin -> debian-russian@lists.debian.org  @ Wed, 07 Oct 2015 02:07:07 
+0300:

 >>  АН> Offtopic:
 >>  АН> А что кто-то реально использует Haskell?
 >>
 >> Да.  И на данный момент я его считаю лучшим вариантом по соотношению
 >> затрат на разработку и уверенности в результате, с БОЛЬШИМ отрывом от
 >> конкурентов.

 DK> Я хотел бы высказать сомнение в большом отрыве Haskell от
 DK> Ocaml. Последний видится мне весьма живым проектом.

Ну, Ocaml я просто не знаю.  В смысле, видеть видел, но не работал.
Может, и да.

 DK> За время работы с ним меня приятно удивило после Haskell:

 DK> 1) Позволяет более просто комбинировать функциональное и императивное
 DK> программирование: не надо изворачиваться монадами, чтобы добиться
 DK> последовательного выполнения команд.

Я Вам открою, наверное, страшную тайну: в хаскеле вообще невозможно
добиться последовательного выполнения команд, кроме как через
зависимость "результат A нужен для вычисления B".  В монадах на сей
предмет нет ничего волшебного.  Даже в монаде IO.  Я когда-то, посмотрев
на ее реализацию и осознав, что она такое, ухитрился даже нарисовать
тест, который это демонстрировал.

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

 DK> 2) Позволяет таки определять полиморфные функции. Да, это нарушение
 DK> системы типов, но если этим не злоупотреблять, то это даже удобно.

Какого именно вида полиморфных функций?  В хаскеле их минимум два (а с
generics, пожалуй, и все три).

 DK> Я в своё время с Вашей подачи пытался взять Haskell наскоком. Увы, он
 DK> меня расстроил по целому ряду причин. Если хотите, могу рассказать.

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

Re: Стабильная система?

[Dmitrii Kashin]

Artem Chuprina  writes:

> Артём Н. -> debian-russian@lists.debian.org  @ Mon, 28 Sep 2015 10:37:48 
> +0300:
>
>  АН> Offtopic:
>  АН> А что кто-то реально использует Haskell?
>
> Да.  И на данный момент я его считаю лучшим вариантом по соотношению
> затрат на разработку и уверенности в результате, с БОЛЬШИМ отрывом от
> конкурентов.

Я хотел бы высказать сомнение в большом отрыве Haskell от
Ocaml. Последний видится мне весьма живым проектом.

За время работы с ним меня приятно удивило после Haskell:

1) Позволяет более просто комбинировать функциональное и императивное
программирование: не надо изворачиваться монадами, чтобы добиться
последовательного выполнения команд.

2) Позволяет таки определять полиморфные функции. Да, это нарушение
системы типов, но если этим не злоупотреблять, то это даже удобно.


Я в своё время с Вашей подачи пытался взять Haskell наскоком. Увы, он
меня расстроил по целому ряду причин. Если хотите, могу рассказать.


signature.asc
Description: PGP signature

Re: Стабильная система?

[Artem Chuprina]

Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Mon, 05 Oct 2015 
00:46:42 +0300:

 OG> Разработка на Haskel bottom-up? В старых книжках по Форту хвастают что при
 OG> таком подходе ты выверяешь каждый кирпичик в момент его конструирования, а 
из
 OG> надежных кирпичей строишь надежное здание.

В обе стороны бывает.  Благодаря богатой системе типов ты можешь
сформулировать что-то вида

dumpDescFrag :: Dictionary
-> [(DefParamType,DictTypeDef)]
-> [DictParamInfo]
-> Dictionary
dumpDescFrag = undefined

и компилировать (но не запускать) код, который использует dumpDescFrag.
Если ты понимаешь, что потребуется передать в эту функцию, то вот тебе
top-down.

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

 OG> Тесты помагают с регресиями, 10 мин. bisect может избавить от
 OG> многодневной отладки.

Да.  За это приходится заплатить многонедельным написанием тестов :)

 OG> Помагают при реструктуризации кода, например изменил сигнатуру и идя по
 OG> ошибкам от компилятора правишь кусочки.

Если язык со статической типизацией, то гораздо лучше помогает компилятор.

Re: Стабильная система?

[Oleksandr Gavenko]

On 2015-10-02, Artem Chuprina wrote:

>  >> Позже, уже в Транзасе, мне коллеги рассказывали, что они изначально тоже
>  >> писали тесты, и автоматически прогоняли их каждое утро, когда приходили
>  >> на работу и запускали smalltalk.  Профессиональных параноиков среди низ
>  >> не было, с количеством тестов они не перенапрягались, но все равно через
>  >> несколько месяцев прогон тестов стал занимать столько времени, что был
>  >> отключен.
>  АН> Может проблема в Smalltalk?
>  АН> Я представил себя на месте пилота (если это не тренажёр).
>  АН> Наверное, если бы летал я, для себя я бы не стал отключать тесты...
>
> У Лема, кажется, есть рассказ на эту тему.  Как искусственный интеллект
> космического корабля, обученный несколько параноидальным пилотом,
> настолько погряз в проверках, все ли хорошо, что разбил корабль при
> посадке.

https://en.wikipedia.org/wiki/Test_plan
https://en.wikipedia.org/wiki/Test_suite

Выбрать стратегию исходя из бюджета проекта.

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

Разработка на Haskel bottom-up? В старых книжках по Форту хвастают что при
таком подходе ты выверяешь каждый кирпичик в момент его конструирования, а из
надежных кирпичей строишь надежное здание.

Всякие Java/.Net проекты подразумевают "бизнес" подходы, т.е. top-down модель.
Незавершенный продукт содержит костыли вместо твердых кирпичей, код полагается
на спецификацию, вместо отлаженой реализации. Тесты нужны.

Тесты помагают с регресиями, 10 мин. bisect может избавить от многодневной
отладки.

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

Если есть ошибка и сразу не ясно в чем проблема в 99% случаев мне помагает
printf, отладчики не умею готовить. Т.е. нужны какие-то кусочки, хоть как то
дергающие функционал.

В GCC каждый патч-фикс должден ити с выявляющем его тестом:
https://gcc.gnu.org/contribute.html

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

-- 
Best regards!

Re: Стабильная система?

[Artem Chuprina]

Артём Н. -> debian-russian@lists.debian.org  @ Thu, 01 Oct 2015 23:12:30 +0300:

 >>> Как измеряется надёжность?
 >> Количеством, гм, ВНЕЗАПНЫХ глюков в единицу времени.
 АН> Если серьёзно говорить об измерении, это не является показателем.

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

На этой задаче.  Если бы это была реальная авионика, 

 >>> не исключена просто логическая ошибка в алгоритме, которую без тестов вы не
 >>> сможете отловить (да знаю, это очевидно).
 >>
 >> Ну да, естественно.  Вот это как раз обычно лечится ручным прогоном.
 АН> Либо вы несколько противоречите сами себе, либо кода не так много.
 АН> В таком случае, чтобы проверить все пути выполнения, вам надо выполнить 
столько же
 АН> операций, сколько выполнят тесты. Только вручную.

Я ел этих устриц.

Тут есть три момента.

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

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

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

 >> Кстати, в оригинальном приборе (который стоит в реальных вертолетах)
 >> таки благополучно перепутали в одном месте плюс с минусом, и отловлено
 >> это было (мной) на стенде при ручном прогоне.
 АН> Фактически, в данном случае стенд являлся тестом для реальной системы,
 АН> а реальная система тестом для стенда.

Учитывая, что реальная система - это вертолет в воздухе, то тестирование
таким образом стенда, особенно на критических и закритических режимах,
дело такое...

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

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

Да, там это, возмоно, имело бы смысл, потому что реальный прибор писан,
вероятно, на C++, в лучшем случае на C, с mutable state, и гонять потом
этот тест следовало бы регулярно.  Угадайте с трех раз, стали ли это
делать разработчики прибора?

 >> Вообще мне приходилось работать в режиме TDD, когда я не знал про
 >> хаскель.  Там, собственно, я и узнал на практике, что прекрасная в
 >> теории идея TDD на практике выражается в квадратичном количестве тестов
 >> и многочасовом их прогоне.
 АН> Да, я тоже это знаю.

 АН> Ну, по факту, странный "спор". По-моему, вы сами прекрасно знаете, что
 АН> без тестов никогда нельзя гарантированно сказать, что система не работает
 АН> на некотором подмножестве случаев после её изменения.
 АН> И тесты нужны. Хотя писать их лень и оверхед.

Видите ли, информация о том, что система НЕ работает - это не та
информация, которая нужна.  Нужна достаточная степень уверенности, что
система РАБОТАЕТ.  Эту уверенность можно получить разными способами.

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

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

Re: Стабильная система?

[Артём Н.]

Однако же успешно выпилил systemd и очень доволен. Злу не должно быть
места в нашей жизни.

Ну возможно конечно развести политико-философскую дискуссию...
Но по факту: system.d - мэинстрим.
Он станет основным, так что я смирился с тем, что придётся изучать "комбайн".


Да и то, что где-то что-то у кого-то еще хуже - это весьма слабое
оправдание. Всегда можно найти кого-нибудь, у кого хуже дела идут.

Но проблема в том, что не найдёте лучше.

Я писал несколько ранее про плюсики и минусики на бумажке. По
совокупности параметров (по-крайней мере для моих скромных потребностей)
лучшего просто нет. Это действительно так.

По факту, более стабильное есть. Но это не Linux.
Из того, что вам не доступно и не нужно - это z/OS. Очень стабильно. :-)
Из того, что возможно поставить при большом желании (и пользоваться, кстати) - 
QNX 6.3.x.


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

Админы говорят, что им давно такого не хватало.

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

Ну не знаю, может им интересно: чинишь, следовательно занят.
Говорили, что там некая дикая автоматизация, которой не позволял достичь 
sysvinit.
Я от этого далёк: с sysvinit мне было проще, я мог что-то быстро поправить, 
если меня не устраивало.


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

Вы про RH?


В Редмонде рады, конечно.

Вряд ли: они свой дистрибутив Linux пилят.

Не верю. Это не в их стиле просто. Зачем пилить свое, если можно взять
чужое. Генту, например.

Маркетинг.
Не имеет значения, что они возьмут за основу, т.к. это всё-равно будет Linux от 
MS:
http://habrahabr.ru/post/267209/


Яблочные так давно уже сделали. Только они фрю
за основу взяли.

Инженерный подход.


А тяга этих ребят к повторению яблочных ходов тоже
давно всем известна. И история с СР/М тоже как-бы намекает. Такая вот
простая логика. Дистрибутив, будет, конечно. Вот только чей?

По лицензии - сообщества.

Re: Стабильная система?

[Артём Н.]

On 01.10.2015 19:39, Artem Chuprina wrote:

Артём Н. -> debian-russian@lists.debian.org  @ Thu, 01 Oct 2015 18:36:54 +0300:

  >>   >>   АН> Offtopic:
  >>   >>   АН> А что кто-то реально использует Haskell?
  >>   >>
  >>   >> Да.  И на данный момент я его считаю лучшим вариантом по соотношению
  >>   >> затрат на разработку и уверенности в результате, с БОЛЬШИМ отрывом от
  >>   >> конкурентов.
  >>   >>
  >>   АН> А, если не секрет, для разработки чего и, что важно, кем, а также 
для кого?
  >>
  >> В одном месте это часть разработки авиационных тренажеров.
  АН> "Сухой" или МАНС?

Транзас-Авиация.

А, не слышал. Посмотрел. Интересная компания.


  >> Приходится много рефакторить, когда выясняется, что вот тут он ведет
  >> себя совсем не так, как мы раньше думали.  Хаскель спасает от дилеммы
  >> "много молиться или писать тестов в разы больше, чем работающего кода".
  >>
  АН> Каким образом спасает?
  АН> Разве для ФП не требуются тесты?
  АН> В чём отличия.

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


Из-за отсутствия зависимостей и состояния функций?


А для достижения приемлемого уровня уверенности можно вообще без тестов
жить.  У меня в том проекте за три года работы и минимум трех крупных
рефакторингах раза три-четыре вылезали ошибки типа "перепутал ветки then
и else" или "перепутал плюс с минусом".  Остальное ловилось системой
типов на стадии компиляции и изредка - первым же ручным прогоном того
места, где менялась функциональность.  Тестов у хреновины нет вообще.
Хреновина при этом оказывается одним из самых надежных мест в тренажере.


Как измеряется надёжность?


Тестов там вообще почти нет, надо сказать.  Потому что работать они
начинают тогда, когда их квадрат от размера кода, а кода в проекте
много.

По-моему, TDD не зависит от языка и парадигмы (не использую, но есть, кто 
использует).
Если нет тестов, сложно проверить корректность изменений.
Т.е., надёжность здесь просто словесная характеристика, а не показатель:
"раза три-четыре вылезали ошибки типа "перепутал ветки then и else" или "перепутал плюс с 
минусом"", -
не исключена просто логическая ошибка в алгоритме, которую без тестов вы не 
сможете отловить (да знаю, это очевидно).



  АН> и скорость выполнения всё-таки ниже C++ (но это не всегда минус).

У меня есть знакомый программист, который мерил.  Зачастую сборка ghc
превосходит по скорости C, а C++ (если на нем пишут как на плюсах, а не
чисто как на C с чуть более удобным синтаксисом) так и как правило
(вероятно, потому что если писать как на плюсах, то будет довольно много
выделений памяти, которые по умолчанию защищены мутексами, а также из-за
неоптимизируемых разыменований виртуальных функций).  В Глазго
оптимизировать тоже умеют, а иммутабельность и статическая типизация
открывают куда более широкие возможности для оптимизации.

Это он писал обработку мощного потока информации, на плюсах на имевшейся
технике уже требовавшую ручного тюнинга параллелизации.

Для определённых задач, согласен. Только это не Хаскелл, а парадигма.
Однако я не совсем понимаю: там всё-равно там есть данные...
Пусть, надо что-то записать, как обойтись без блокировок вообще?



  >> Непосредственный заказчик - работодатель, а потребитель тренажера и
  >> критик, если что-то работает не так, как в настоящей машине - летчик.
  >> Это ответ на вопрос "для кого".
  >>
  АН> Вопрос был к тому, что вакансий на Haskell я не видел.

Так на Haskell не индусы пишут.

Кстати, индусы тоже пишут: они разные бывают. :-)


В смысле, человека берут решать сложную
задачу, а на чем он ее решает - это уже его личное дело.
Задача сложная, "программист на XXX" ее не решит.

Как правило, всё-таки декларируют определённый язык.
Решите вы задачу и уйдёте.
А кто будет поддерживать ваш код затем?


И я, когда ищу себе работу, тоже не ищу вакансии "программиста на YYY".
Потому что это вакансии для негров, у меня тупая монотонная работа плохо
получается.

У меня тоже, я заметил.


Я ищу вакансии разработчика ПО, где надо думать головой.

Это не обязательно работа на Haskell.


  >> В другом месте веб-сервер, встраивающийся в существующий и без того
  >> нетривиальный бизнес-процесс, и добавляющий еще своей нетривиальности.
  >> Попытка сделать его на рельсах мне не понравилась - трогать страшно,
  >> сейчас переписываю на yesod.
  >>
  АН> Любопытно уже хотя бы то, что он не умер и не остался эзотерическим 
языком,
  АН> а вполне стабильно обрастает инфраструктурой...
  АН> Плотно ФП руки не доходили заняться (на началах Lisp, это всё и 
закончилось).

В мире довольно много людей с развитым абстрактным мышлением.



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

Хм... ООП тогда тоже неплохо.


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

Ещё тут 

Re: Стабильная система?

[Артём Н.]

On 01.10.2015 18:52, Алексей Витальевич Коротков wrote:

On Thu, 01 Oct 2015 18:36:54 +0300
Артём Н. wrote:


Вопрос был к тому, что вакансий на Haskell я не видел.


Так много кто много чего не видел. Тем не менее, как ни странно, но:

http://www.haskellers.com/jobs
http://www.indeed.com/q-Haskell-Functional-jobs.html


Да я посмотрел уже.
Даже на hh есть.
Только, где ФП (не обязательно Haskell) в требованиях всего лишь
одна вакансия (и несколько, где Haskell в пожеланиях).

Re: Стабильная система?

[Artem Chuprina]

Артём Н. -> debian-russian@lists.debian.org  @ Thu, 01 Oct 2015 18:36:54 +0300:

 >>   >>   АН> Offtopic:
 >>   >>   АН> А что кто-то реально использует Haskell?
 >>   >>
 >>   >> Да.  И на данный момент я его считаю лучшим вариантом по соотношению
 >>   >> затрат на разработку и уверенности в результате, с БОЛЬШИМ отрывом от
 >>   >> конкурентов.
 >>   >>
 >>   АН> А, если не секрет, для разработки чего и, что важно, кем, а также для 
 >> кого?
 >>
 >> В одном месте это часть разработки авиационных тренажеров.
 АН> "Сухой" или МАНС?

Транзас-Авиация.

 >> На хаскеле написан имитатор изрядно интеллектуального прибора, не имеющего 
 >> не
 >> только четкой модели, но и достаточной для имитации документации.
 АН> Хм... Экспертная система? Нейронная сеть?

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

 >> Приходится много рефакторить, когда выясняется, что вот тут он ведет
 >> себя совсем не так, как мы раньше думали.  Хаскель спасает от дилеммы
 >> "много молиться или писать тестов в разы больше, чем работающего кода".
 >>
 АН> Каким образом спасает?
 АН> Разве для ФП не требуются тесты?
 АН> В чём отличия.

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

А для достижения приемлемого уровня уверенности можно вообще без тестов
жить.  У меня в том проекте за три года работы и минимум трех крупных
рефакторингах раза три-четыре вылезали ошибки типа "перепутал ветки then
и else" или "перепутал плюс с минусом".  Остальное ловилось системой
типов на стадии компиляции и изредка - первым же ручным прогоном того
места, где менялась функциональность.  Тестов у хреновины нет вообще.
Хреновина при этом оказывается одним из самых надежных мест в тренажере.

Тестов там вообще почти нет, надо сказать.  Потому что работать они
начинают тогда, когда их квадрат от размера кода, а кода в проекте
много.

 АН> По факту минуса два: мало людей на нём пишет и поймёт написанное

Мне хватает.

 АН> и скорость выполнения всё-таки ниже C++ (но это не всегда минус).

У меня есть знакомый программист, который мерил.  Зачастую сборка ghc
превосходит по скорости C, а C++ (если на нем пишут как на плюсах, а не
чисто как на C с чуть более удобным синтаксисом) так и как правило
(вероятно, потому что если писать как на плюсах, то будет довольно много
выделений памяти, которые по умолчанию защищены мутексами, а также из-за
неоптимизируемых разыменований виртуальных функций).  В Глазго
оптимизировать тоже умеют, а иммутабельность и статическая типизация
открывают куда более широкие возможности для оптимизации.

Это он писал обработку мощного потока информации, на плюсах на имевшейся
технике уже требовавшую ручного тюнинга параллелизации.

 >> Непосредственный заказчик - работодатель, а потребитель тренажера и
 >> критик, если что-то работает не так, как в настоящей машине - летчик.
 >> Это ответ на вопрос "для кого".
 >>
 АН> Вопрос был к тому, что вакансий на Haskell я не видел.

Так на Haskell не индусы пишут.  В смысле, человека берут решать сложную
задачу, а на чем он ее решает - это уже его личное дело.  Задача
сложная, "программист на XXX" ее не решит.

И я, когда ищу себе работу, тоже не ищу вакансии "программиста на YYY".
Потому что это вакансии для негров, у меня тупая монотонная работа плохо
получается.  Я ищу вакансии разработчика ПО, где надо думать головой.

 >> В другом месте веб-сервер, встраивающийся в существующий и без того
 >> нетривиальный бизнес-процесс, и добавляющий еще своей нетривиальности.
 >> Попытка сделать его на рельсах мне не понравилась - трогать страшно,
 >> сейчас переписываю на yesod.
 >>
 АН> Любопытно уже хотя бы то, что он не умер и не остался эзотерическим языком,
 АН> а вполне стабильно обрастает инфраструктурой...
 АН> Плотно ФП руки не доходили заняться (на началах Lisp, это всё и 
закончилось).

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

Re: Стабильная система?

[Артём Н.]

On 30.09.2015 22:34, Artem Chuprina wrote:

Артём Н. -> debian-russian@lists.debian.org  @ Tue, 29 Sep 2015 19:20:08 +0300:

  >>   АН> Offtopic:
  >>   АН> А что кто-то реально использует Haskell?
  >>
  >> Да.  И на данный момент я его считаю лучшим вариантом по соотношению
  >> затрат на разработку и уверенности в результате, с БОЛЬШИМ отрывом от
  >> конкурентов.
  >>
  АН> А, если не секрет, для разработки чего и, что важно, кем, а также для 
кого?

В одном месте это часть разработки авиационных тренажеров.

"Сухой" или МАНС?


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

Хм... Экспертная система? Нейронная сеть?


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


Каким образом спасает?
Разве для ФП не требуются тесты?
В чём отличия.

По факту минуса два: мало людей на нём пишет и поймёт написанное и скорость 
выполнения
всё-таки ниже C++ (но это не всегда минус).


Непосредственный заказчик - работодатель, а потребитель тренажера и
критик, если что-то работает не так, как в настоящей машине - летчик.
Это ответ на вопрос "для кого".


Вопрос был к тому, что вакансий на Haskell я не видел.


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


Любопытно уже хотя бы то, что он не умер и не остался эзотерическим языком,
а вполне стабильно обрастает инфраструктурой...
Плотно ФП руки не доходили заняться (на началах Lisp, это всё и закончилось).

Re: Стабильная система?

[Artem Chuprina]

Артём Н. -> debian-russian@lists.debian.org  @ Thu, 01 Oct 2015 20:05:46 +0300:

 >>   >> Приходится много рефакторить, когда выясняется, что вот тут он ведет
 >>   >> себя совсем не так, как мы раньше думали.  Хаскель спасает от дилеммы
 >>   >> "много молиться или писать тестов в разы больше, чем работающего кода".
 >>   >>
 >>   АН> Каким образом спасает?
 >>   АН> Разве для ФП не требуются тесты?
 >>   АН> В чём отличия.
 >>
 >> В том, что для достижения того же (высокого) уровня уверенности в
 >> работоспособности кода тестов требуется на порядок меньше.  Не квадрат
 >> от размера кода, а линейно.
 >>
 АН> Из-за отсутствия зависимостей и состояния функций?

Угу.

 >> А для достижения приемлемого уровня уверенности можно вообще без тестов
 >> жить.  У меня в том проекте за три года работы и минимум трех крупных
 >> рефакторингах раза три-четыре вылезали ошибки типа "перепутал ветки then
 >> и else" или "перепутал плюс с минусом".  Остальное ловилось системой
 >> типов на стадии компиляции и изредка - первым же ручным прогоном того
 >> места, где менялась функциональность.  Тестов у хреновины нет вообще.
 >> Хреновина при этом оказывается одним из самых надежных мест в тренажере.
 >>
 АН> Как измеряется надёжность?

Количеством, гм, ВНЕЗАПНЫХ глюков в единицу времени.

 >> Тестов там вообще почти нет, надо сказать.  Потому что работать они
 >> начинают тогда, когда их квадрат от размера кода, а кода в проекте
 >> много.
 АН> По-моему, TDD не зависит от языка и парадигмы (не использую, но есть, кто 
использует).
 АН> Если нет тестов, сложно проверить корректность изменений.
 АН> Т.е., надёжность здесь просто словесная характеристика, а не показатель:
 АН> "раза три-четыре вылезали ошибки типа "перепутал ветки then и else" или 
"перепутал плюс с минусом"", -
 АН> не исключена просто логическая ошибка в алгоритме, которую без тестов вы не
 АН> сможете отловить (да знаю, это очевидно).

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

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

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

 >>   АН> и скорость выполнения всё-таки ниже C++ (но это не всегда минус).
 >>
 >> У меня есть знакомый программист, который мерил.  Зачастую сборка ghc
 >> превосходит по скорости C, а C++ (если на нем пишут как на плюсах, а не
 >> чисто как на C с чуть более удобным синтаксисом) так и как правило
 >> (вероятно, потому что если писать как на плюсах, то будет довольно много
 >> выделений памяти, которые по умолчанию защищены мутексами, а также из-за
 >> неоптимизируемых разыменований виртуальных функций).  В Глазго
 >> оптимизировать тоже умеют, а иммутабельность и статическая типизация
 >> открывают куда более широкие возможности для оптимизации.
 >>
 >> Это он писал обработку мощного потока информации, на плюсах на имевшейся
 >> технике уже требовавшую ручного тюнинга параллелизации.
 АН> Для определённых задач, согласен. Только это не Хаскелл, а парадигма.
 АН> Однако я не совсем понимаю: там всё-равно там есть данные...
 АН> Пусть, надо что-то записать, как обойтись без блокировок вообще?

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

 >>   >> Непосредственный заказчик - работодатель, а потребитель тренажера и
 >>   >> критик, если что-то работает не так, как в настоящей машине - летчик.
 >>   >> Это ответ на вопрос "для кого".
 >>   >>
 >>   АН> Вопрос был к тому, что вакансий на Haskell я не видел.
 >>
 >> Так на Haskell не индусы пишут.
 АН> Кстати, индусы тоже пишут: они разные бывают. :-)

Естественно, я в среднем.

 >> В смысле, человека берут решать сложную
 >> задачу, а на чем он ее решает - это уже его личное дело.
 >> Задача сложная, "программист на XXX" ее не решит.
 АН> Как правило, всё-таки декларируют определённый язык.
 АН> Решите вы задачу и уйдёте.
 АН> А кто будет поддерживать ваш код затем?

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

Человеку со сравнимым интеллектом будет дешевле выучить хаскель и
разобраться в хаскельном коде, чем 

Re: Стабильная система?

[Melleus]

"Артём Н." <artio...@yandex.ru> writes:

>> Однако же успешно выпилил systemd и очень доволен. Злу не должно быть
>> места в нашей жизни.
> Ну возможно конечно развести политико-философскую дискуссию...
> Но по факту: system.d - мэинстрим.
> Он станет основным, так что я смирился с тем, что придётся изучать "комбайн".
Будущее есть сущность во многом неопределенная. Так что я бы не был столь
категоричен. Тем более, что многих влиятельных умов таки несколько беспокоит
имеющая место проблема непереносимости systemd.
>>>> Да и то, что где-то что-то у кого-то еще хуже - это весьма слабое
>>>> оправдание. Всегда можно найти кого-нибудь, у кого хуже дела идут.
>>> Но проблема в том, что не найдёте лучше.
>> Я писал несколько ранее про плюсики и минусики на бумажке. По
>> совокупности параметров (по-крайней мере для моих скромных потребностей)
>> лучшего просто нет. Это действительно так.
> По факту, более стабильное есть. Но это не Linux.
> Из того, что вам не доступно и не нужно - это z/OS. Очень стабильно. :-)
> Из того, что возможно поставить при большом желании (и пользоваться, кстати) 
> - QNX 6.3.x.
Еще проще было бы поставить FreeBSD. У меня уход из мира мелкого мягкого софта
был связан именно с ней. Самая стабильная система из всего, чем приходилось
пользоваться. Но со сменой компа как-то вылезли проблемы совместимости с
железом, переполз, да так и остался на Дебиан. Иногда бросаю косяки на
Генту, даже в виртуалку себе поставил. Но затраты времени на поддержку
системы актуальной просто ужасают. А отдельного админа себе позволить не
могу да и не считаю правильным, вообще-то. Так что дальше экспериментов
дело не пошло. И это все без сборки офиса. Без которого, увы, обойтись не
могу. И стабильность не та. После обновления бывает склонность к сбоям.
>>>> И сообщество вместо того, чтобы заниматься действительно актуальными
>>>> вещами вынуждено тратить свое драгоценное время и ресурсы на то, чтобы
>>>> хоть как-то сгладить косяки лезущие из всех щелей его псевдо
>>>> инноваций. Все проходит. И это пройдет тоже. Но потеряны годы.
>>> Админы говорят, что им давно такого не хватало.
>> Молодому поколению админов, с пеленок окучиваемых компанией с весьма
>> дискуссионными подходами к созданию и функционалу ПО (вспомним, какие
>> редакторы и электронные таблицы они начинают учить со школы, под какую
>> операционную систему писано большинство игрушек) конечно, всегда будет
>> нехватать этого короткого одеяла из неким странным образом подобранных
>> разноцветных лоскутов, не оченнь-то аккуратно сшитых между собой.
> Ну не знаю, может им интересно: чинишь, следовательно занят.
> Говорили, что там некая дикая автоматизация, которой не позволял достичь 
> sysvinit.
> Я от этого далёк: с sysvinit мне было проще, я мог что-то быстро поправить, 
> если меня не устраивало.
Ну а мне-то для подготовки научных и академических текстов да для
бложека и подавно, чем проще - тем лучше.
>> Насчет ПО, может они и не очень, а вот что касается маркетинга - то очень,
>> очень талантливые люди там сидят. Они даже пингвинам смогут снег зимой
>> продать, а те еще потом за добавкой придут и будут за собой остаток
>> жизни непонятно зачем тягать разноцветные ошметки.
> Вы про RH?
Не только, проблема более глобальна, ИМХ0.
>>>> В Редмонде рады, конечно.
>>> Вряд ли: они свой дистрибутив Linux пилят.
>> Не верю. Это не в их стиле просто. Зачем пилить свое, если можно взять
>> чужое. Генту, например.
> Маркетинг.
> Не имеет значения, что они возьмут за основу, т.к. это всё-равно будет Linux 
> от MS:
> http://habrahabr.ru/post/267209/
>
>> Яблочные так давно уже сделали. Только они фрю
>> за основу взяли.
> Инженерный подход.
>
>> А тяга этих ребят к повторению яблочных ходов тоже
>> давно всем известна. И история с СР/М тоже как-бы намекает. Такая вот
>> простая логика. Дистрибутив, будет, конечно. Вот только чей?
> По лицензии - сообщества.

Re: Стабильная система?

[Артём Н.]

Как измеряется надёжность?

Количеством, гм, ВНЕЗАПНЫХ глюков в единицу времени.

Если серьёзно говорить об измерении, это не является показателем.


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


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

Либо вы несколько противоречите сами себе, либо кода не так много.
В таком случае, чтобы проверить все пути выполнения, вам надо выполнить столько 
же
операций, сколько выполнят тесты. Только вручную.


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

Фактически, в данном случае стенд являлся тестом для реальной системы,
а реальная система тестом для стенда.


Тесты, кстати, могли и не поймать - написать тест, который это ловит, весьма 
нетривиально.

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


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

Да, я тоже это знаю.

Ну, по факту, странный "спор". По-моему, вы сами прекрасно знаете, что
без тестов никогда нельзя гарантированно сказать, что система не работает
на некотором подмножестве случаев после её изменения.
И тесты нужны. Хотя писать их лень и оверхед.


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

Может проблема в Smalltalk?
Я представил себя на месте пилота (если это не тренажёр).
Наверное, если бы летал я, для себя я бы не стал отключать тесты...
Да, и может проблема не в тестах?
Если изменяется кусок, который сильно изолирован, так ли часто надо прогонять 
_все_ тесты?


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

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


  >> В смысле, человека берут решать сложную
  >> задачу, а на чем он ее решает - это уже его личное дело.
  >> Задача сложная, "программист на XXX" ее не решит.
  АН> Как правило, всё-таки декларируют определённый язык.
  АН> Решите вы задачу и уйдёте.
  АН> А кто будет поддерживать ваш код затем?

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

Но есть ещё "умение разбираться в чужом коде".
Хотя, в данном случае, наверное Хаскелю будет плюс, в целом.
Сложно найти людей, которые с ним работают, чтобы поручить
им поддерживать кусочки задачи (не думаю, что интеллект измеряется знанием или 
незнанием
Haskell, я вот его не знаю, так что, я автоматически попадаю у вас в категорию 
"тупой"?).


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


Вероятно. Это зависит от того, кем, как и с какой целью так написан C++ код.
Есть C++ код, в некоторой степени написанный для того, чтобы показать "какая крутая 
у меня квалификация".


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

Странная поддержка...


Если задача простая, то ситуация, разумеется, иная.

На C++ любую задачу возможно решить сложно.


Я пробовал, довольно много. ООП как парадигма - это duck typing

Да не обязательно. Это выражение больше напоминает Python.
И всё вытекающее: нестрогую типизации прежде всего, прототипное "наследование" 
и т.п..


следствие, вышеупомянутое квадратичное количество тестов.  Собственно,
это оно у хорошо примененной ООП квадратичное, у спагетти-кода оно
экспоненциальное.

И на хаскеле возможно так написать. :-\


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

Разве не проще оперировать объектами в терминах какого-нибудь DSL?


Ещё тут рядом на Erlang пытались что-то делать, не пошло.
Некому это поддерживать.
Просто людей не найти, кто станет на этом писать.


У меня коллега уехал в Швецию как раз на позицию, где был нужен Erlang.

Re: Стабильная система?

[Artem Chuprina]

Артём Н. -> debian-russian@lists.debian.org  @ Tue, 29 Sep 2015 19:20:08 +0300:

 >>   АН> Offtopic:
 >>   АН> А что кто-то реально использует Haskell?
 >>
 >> Да.  И на данный момент я его считаю лучшим вариантом по соотношению
 >> затрат на разработку и уверенности в результате, с БОЛЬШИМ отрывом от
 >> конкурентов.
 >>
 АН> А, если не секрет, для разработки чего и, что важно, кем, а также для кого?

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

Непосредственный заказчик - работодатель, а потребитель тренажера и
критик, если что-то работает не так, как в настоящей машине - летчик.
Это ответ на вопрос "для кого".

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

Кем - мной и аналогичными по умственному развитию коллегами (во втором
месте только мной, там таких коллег нет).

Re: Стабильная система?

[Melleus]

"Артём Н."  writes:

>> А насчет стабильности стейбла - так вот сегодня с удивлением заметил,
>> что еще и Clementine больше не проигрывает ape-файлы. Когда отвалилось -
>> не отследил, но на предыдущем стейбле все прекрасно воспроизводилось.
>>
> Ну, а у меня Plymouth давно отъехал. В Wheezy всё работало.
> А сейчас, дескать, не хотим, чтобы ты NVIDIA драйвера проприетарные из
> репозитория использовал, если хочешь смотреть картинку при загрузке.
> Ну, может танцами с бубном и возможно завести и на проприетарных драйверах.
> Но с введением systemd стабильность упала, я принимаю это, как неизбежное зло.
Однако же успешно выпилил systemd и очень доволен. Злу не должно быть
места в нашей жизни.
>> Да и то, что где-то что-то у кого-то еще хуже - это весьма слабое
>> оправдание. Всегда можно найти кого-нибудь, у кого хуже дела идут.
> Но проблема в том, что не найдёте лучше.
Я писал несколько ранее про плюсики и минусики на бумажке. По
совокупности параметров (по-крайней мере для моих скромных потребностей)
лучшего просто нет. Это действительно так.
>> Лично мне болезнь понятна - она связана с экстравагантными инновациями одного
>> из разработчиков, чересчур известному чтобы называть его имя.
> Угу.
>
>>И сообщество вместо того, чтобы заниматься действительно актуальными
>> вещами вынуждено тратить свое драгоценное время и ресурсы на то, чтобы
>> хоть как-то сгладить косяки лезущие из всех щелей его псевдо
>> инноваций. Все проходит. И это пройдет тоже. Но потеряны годы.
> Админы говорят, что им давно такого не хватало.
Молодому поколению админов, с пеленок окучиваемых компанией с весьма
дискуссионными подходами к созданию и функционалу ПО (вспомним, какие
редакторы и электронные таблицы они начинают учить со школы, под какую
операционную систему писано большинство игрушек) конечно, всегда будет
нехватать этого короткого одеяла из неким странным образом подобранных
разноцветных лоскутов, не оченнь-то аккуратно сшитых между собой. Насчет
ПО, может они и не очень, а вот что касается маркетинга - то очень,
очень талантливые люди там сидят. Они даже пингвинам смогут снег зимой
продать, а те еще потом за добавкой придут и будут за собой остаток
жизни непонятно зачем тягать разноцветные ошметки.
>> В Редмонде рады, конечно.
> Вряд ли: они свой дистрибутив Linux пилят.
Не верю. Это не в их стиле просто. Зачем пилить свое, если можно взять
чужое. Генту, например. Яблочные так давно уже сделали. Только они фрю
за основу взяли. А тяга этих ребят к повторению яблочных ходов тоже
давно всем известна. И история с СР/М тоже как-бы намекает. Такая вот
простая логика. Дистрибутив, будет, конечно. Вот только чей?

Re: Стабильная система?

[Artem Chuprina]

Алексей Витальевич Коротков -> debian-russian@lists.debian.org  @ Tue, 29 Sep 
2015 09:54:14 +0400:

 AC>> Впрочем, неудивительно - какая-то она очень куцая.  Ищет только в
 AC>> именах пакетов.

 АВК> Хм. Ну так в stack и вот этого нет:

Ну, нету, да.  Видимо, авторы stack пользуются hayoo и/или
централизованным hoogle.  Типа, все равно, чтобы поставить пакет,
интернет потребуется, так не проще ли воспользоваться им же для поиска,
там поисковик лучше.

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

Можно спросить их, но если спросить меня, то я скажу, что в stack не
хватает (или я не нашел) только возможности спросить напрямую, какая
именно версия конкретного пакета есть в текущем резолвере.  Впрочем,
тривиальный grep это популярно рассказывает, если прочесть архитектуру и
понимать, где лежит build plan.

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

Re: Стабильная система?

[Алексей Витальевич Коротков]

On Tue, 29 Sep 2015 09:19:44 +0300
Artem Chuprina wrote:

AC> А вот поиск по именам пакетов из индекса с выводом описаний - это
AC> лишнее в этом инструменте, на мой взгляд.

Я бы предпочёл иметь хоть такой, чем ничего.

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

Согласен.

Re: Стабильная система?

[Artem Chuprina]

Алексей Витальевич Коротков -> debian-russian@lists.debian.org  @ Tue, 29 Sep 
2015 11:16:10 +0400:

 AC>> А вот поиск по именам пакетов из индекса с выводом описаний - это
 AC>> лишнее в этом инструменте, на мой взгляд.

 АВК> Я бы предпочёл иметь хоть такой, чем ничего.

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

 АВК> Согласен.

И я вот задумался...  Локальный hoogle, часом, не справится ли, имея
только индекс?  Хотя, наверное, вряд ли, он искалка по API, а API в
индексе нет.

Re: Стабильная система?

[Артём Н.]

А насчет стабильности стейбла - так вот сегодня с удивлением заметил,
что еще и Clementine больше не проигрывает ape-файлы. Когда отвалилось -
не отследил, но на предыдущем стейбле все прекрасно воспроизводилось.


Ну, а у меня Plymouth давно отъехал. В Wheezy всё работало.
А сейчас, дескать, не хотим, чтобы ты NVIDIA драйвера проприетарные из
репозитория использовал, если хочешь смотреть картинку при загрузке.
Ну, может танцами с бубном и возможно завести и на проприетарных драйверах.
Но с введением systemd стабильность упала, я принимаю это, как неизбежное зло.


Да и то, что где-то что-то у кого-то еще хуже - это весьма слабое
оправдание. Всегда можно найти кого-нибудь, у кого хуже дела идут.

Но проблема в том, что не найдёте лучше.


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

Угу.


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

Админы говорят, что им давно такого не хватало.


В Редмонде рады, конечно.

Вряд ли: они свой дистрибутив Linux пилят.

Re: Стабильная система?

[Артём Н.]

On 28.09.2015 23:34, Artem Chuprina wrote:

Артём Н. -> debian-russian@lists.debian.org  @ Mon, 28 Sep 2015 10:37:48 +0300:

  АН> Offtopic:
  АН> А что кто-то реально использует Haskell?

Да.  И на данный момент я его считаю лучшим вариантом по соотношению
затрат на разработку и уверенности в результате, с БОЛЬШИМ отрывом от
конкурентов.


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

Re: Стабильная система?

[Artem Chuprina]

Алексей Витальевич Коротков -> debian-russian@lists.debian.org  @ Tue, 29 Sep 
2015 01:03:09 +0400:

 АВК> Что не понравилось в stack (и это очень странно, как вообще обходятся
 АВК> без этой функции): нет поиска (в cabal это cabal list).

Видимо, авторы, как и я, не пользуются этой функцией...

Впрочем, неудивительно - какая-то она очень куцая.  Ищет только в именах
пакетов.

Re: Стабильная система?

[Melleus]

"Артём Н."  writes:

> Offtopic:
> А что кто-то реально использует Haskell?
>
> Насчёт "стабильного" дистрибутива. Стоит попробовать Windows.
> Обновил 7-ю на виртуалке, студию поставил, затратил время, обновления всякие
> от MS.
> Перезагрузил...
>
> Оно мне выдало насмешливый синий экран с текстом:
> "STOP: c145 {Application Error}
> The application was unable to start correctly (0xc00d)
>
> Click ok to close application."
>
> Внезапно оказалось, что это нормально:
> http://kakpedia.org/%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B0-c145-%D0%BF%D0%BE%D1%81%D0%BB%D0%B5-%D1%83%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B8-%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9-windows/
>
> И до сих пор винда валяется (по инструкции не сделать, т.к. ошибки в
> утилите восстановления (именно в самой утилите: она пытается искать
> какой-то бред)).

Судя по факту существования и достаточно широкой популярности в узких
кругах таких софтин, как Pandoc и Xmonad таки да.

А насчет стабильности стейбла - так вот сегодня с удивлением заметил,
что еще и Clementine больше не проигрывает ape-файлы. Когда отвалилось -
не отследил, но на предыдущем стейбле все прекрасно воспроизводилось.

Да и то, что где-то что-то у кого-то еще хуже - это весьма слабое
оправдание. Всегда можно найти кого-нибудь, у кого хуже дела идут. Лично
мне болезнь понятна - она связана с экстравагантными инновациями одного
из разработчиков, чересчур известному чтобы называть его имя. И
сообщество вместо того, чтобы заниматься действительно актуальными
вещами вынуждено тратить свое драгоценное время и ресурсы на то, чтобы
хоть как-то сгладить косяки лезущие из всех щелей его псевдо
инноваций. Все проходит. И это пройдет тоже. Но потеряны годы. В
Редмонде рады, конечно. Конечно, тучи разойдутся и время расставит все
на свои места, как уже бывало неоднократно. И если вдруг окажется, что
он получал оттуда денежные переводы или какие нибудь "гранты", я уж
нисколько не удивлюсь. Какой еще конкуренции приходится ждать от
компании, построившей свой бизнес на ребрендинге украденной ОС и
продажах ее "внагрузку" к чужому успешному продукту. Конечно же, эти
ребята знают толк в пиратстве и плетении интриг. Я бы сказал, имеют к
этому недюжинный талант, которому можно даже позавидовать. Опять же
покупка и последующий убой Нокии. Вот только это уже совсем другая тема.

Re: Стабильная система?

[Artem Chuprina]

Артём Н. -> debian-russian@lists.debian.org  @ Mon, 28 Sep 2015 10:37:48 +0300:

 АН> Offtopic:
 АН> А что кто-то реально использует Haskell?

Да.  И на данный момент я его считаю лучшим вариантом по соотношению
затрат на разработку и уверенности в результате, с БОЛЬШИМ отрывом от
конкурентов.

Re: Стабильная система?

[Алексей Витальевич Коротков]

On Sat, 26 Sep 2015 21:14:45 +0300
Artem Chuprina wrote:

AC> Тогда уж осваивай stack. Для человека, который не намерен
AC> самостоятельно бороться с тонкостями настройки системы сборки
AC> хаскельных программ, лучше stack. Его недавно придумали, и про него
AC> мало кто знает, но обычно он проблему зависимостей решает
AC> эффективнее, потому что радикальнее.

Спасибо за наводку.

Покрутил. Работает. Для чистоты эксперимента поставил в виртуалке на
Debian вообще без системных haskell-пакетов. Взлетело. Поставил через
него pandoc и pandoc-citeproc. Работают.

Опять же там с нуля поставил и cabal (в домашник другого пользователя).
Так же через cabal поставил pandoc и pandoc-citeproc. Работают. Когда
зимой ставил на Wheezy через cabal, то были проблемы с зависимостями
(подробностей уже не вспомню; что-то смог преодолеть, что-то - нет).
Сейчас всё прошло как по маслу.

В общем, работает и то и то.

Что не понравилось в stack (и это очень странно, как вообще обходятся
без этой функции): нет поиска (в cabal это cabal list).

Re: Стабильная система?

[Артём Н.]

Offtopic:
А что кто-то реально использует Haskell?

Насчёт "стабильного" дистрибутива. Стоит попробовать Windows.
Обновил 7-ю на виртуалке, студию поставил, затратил время, обновления всякие
от MS.
Перезагрузил...

Оно мне выдало насмешливый синий экран с текстом:
"STOP: c145 {Application Error}
The application was unable to start correctly (0xc00d)

Click ok to close application."

Внезапно оказалось, что это нормально:
http://kakpedia.org/%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B0-c145-%D0%BF%D0%BE%D1%81%D0%BB%D0%B5-%D1%83%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B8-%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9-windows/

И до сих пор винда валяется (по инструкции не сделать, т.к. ошибки в утилите 
восстановления (именно в самой утилите: она пытается искать какой-то бред)).

Re: Стабильная система?

[Artem Chuprina]

Melleus -> debian-russian@lists.debian.org  @ Sat, 26 Sep 2015 23:25:52 +0300:

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

 M> Спасибо за наводку на инструмент. Но только неправильно это. Все должно
 M> в оф. репозитории быть, из него устанавливаться и работать нормально (в
 M> моем понимании). А все эти костыли. Как-то надо без них обходиться. Ибо
 M> зачем тогда Дебиан?

В моей практике дебиан для того, что работает в дебиане.  Почему именно
дебиан?  Потому что в нем работает больше.  Но я всегда был готов к
тому, что что-то конкретное не работает или мне нужно более новое, чем
есть в дистрибутиве.  Или, наоборот, более старое.  Обычно это один-два
предмета.  Вот сейчас, например, это хаскель (я в основном на нем
программирую), он в дебиане несколько устаревший, и ruby on rails (этот,
наоборот, более свежий, чем там, где мне его надо поддерживать).  Раньше
был vim, который мы с Витусом себе собирали в разные позы так, чтобы
несколько пакетов уживались в одной системе.

 M> Есть же ведь для искателей сложных путей LFS. Я в свое время
 M> вычеркнул xmonad из списка претендентов, чтобы этот огород с
 M> хакселем не окучивать.

Вот как раз xmonad и xmobar (дистрибутивные) нормально живут с
дистрибутивным комплектом хаскеля.  Глюков в них нет (или почти нет), и
жить можно, а пакет libghc-xmonad-dev честно тянет за собой все
зависимости, которые ему нужны для перекомпиляции.

 M> А он, как у Достоевского любовь - с монадом его в дверь выгнал, так
 M> он теперь с пандоком через окно лезет. Там, глядишь и Гента
 M> подкрадется сзади. Прошу извинить мое бурчание. А за поддержку - еще
 M> раз спасибо. И за наводку тоже.

 M> PS Собралось все вроде и установилось. И даже запускается. Теперь бы еще
 M> не забыть грохнуть все это хозяйство, когда до оф. репозиториев
 M> обновления доползут.

 M> Еще раз огромное спасибо всем, принявшим участие.

Re: Стабильная система?

[Artem Chuprina]

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

Сорри за боттом-квотинг, с планшета пишу.

On 24 September 2015 10:54:52 pm GMT+03:00, Melleus  
wrote:
>Алексей Витальевич Коротков  writes:
>
>> Я себе ставлю его через cabal. Нельзя сказать, что штука
>беспроблемная,
>> но pandoc как раз таким образом ставится.
>
>Спасибо за подсказку. Пытался забекпортить, но опять наткнулся на
>взаимоисключающие зависимости. Хоть и идеологически неправильно это, но
>наверное, придется таки осваивать cabal. Хотя, наверное, это и не самый
>правильный, но зато - самый простой способ заполучить работающий пакет
>в
>стабильную ветку. В такие моменты все чаще посещает мысль ближе с
>Гентой
>познакомиться. Но вот если бы еще ее не дало было компилять при каждом
>обновлении и стабильность, и комьюнити чтобы. Но, наверное, не бывает в
>этом мире чтоб прямо все сразу было хорошо. Всегда чего-то не
>хватает. Начинаешь плюсики-минусики на бумажке рисовать - больше всех
>плюсиков таки у Дебиана получается.
>
>Еще раз спасибо.

Re: Стабильная система?

[Melleus]

Artem Chuprina  writes:

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

Спасибо за наводку на инструмент. Но только неправильно это. Все должно
в оф. репозитории быть, из него устанавливаться и работать нормально (в
моем понимании). А все эти костыли. Как-то надо без них обходиться. Ибо
зачем тогда Дебиан? Есть же ведь для искателей сложных путей LFS. Я в
свое время вычеркнул xmonad из списка претендентов, чтобы этот огород с
хакселем не окучивать. А он, как у Достоевского любовь - с монадом его в
дверь выгнал, так он теперь с пандоком через окно лезет. Там, глядишь и
Гента подкрадется сзади. Прошу извинить мое бурчание. А за поддержку
- еще раз спасибо. И за наводку тоже.

PS Собралось все вроде и установилось. И даже запускается. Теперь бы еще
не забыть грохнуть все это хозяйство, когда до оф. репозиториев
обновления доползут.

Еще раз огромное спасибо всем, принявшим участие.

Re: Стабильная система?

[Алексей Витальевич Коротков]

On Fri, 25 Sep 2015 17:48:33 +0300
Melleus wrote:

M> Дебиановские одноименные пакеты
M> (pandoc и citeproc) я так понимаю, лучше удалить.

Можно и удалить, хотя они не будут мешать, если правильно в ~/.bashrc
(или каким шеллом пользуетесь) пути прописаны. Главное, чтобы
$HOME/.cabal/bin в переменной $PATH шёл раньше системных каталогов.

С другой стороны, смысла держать их установленными в системе
deb-пакетами тоже нет.

M> Если он так все свое компактненько в кучке держит, то, пожалуй,
M> риски минимальны, буду пробовать.

По такому же принципу и другие пакетные менеджеры работают (rvm, nvm,
etc).

M> Спасибо огромное и за наводку, и за разъяснения.

Пожалуйста. Когда начал сам пользоваться Markdown (ещё на Wheezy), то,
естественно, наткнулся на pandoc и тут же возникли вопросы, связанные с
версиями и дополнительными пакетами. Поиск навёл на cabal, попробовал им
воспользоваться - меня устроило, хотя, как уже писал ранее, сказать,
что он работает беспроблемно, не могу. Но конкретно с pandoc проблем не
возникало.

Re: Стабильная система?

[Melleus]

Алексей Витальевич Коротков  writes:

> On Fri, 25 Sep 2015 14:30:18 +0300
> Melleus wrote:
>
> M> Я просто пока не решил, как мне теперь лучше поступить - дать
> M> установить непонятному установщику кучу пакетов из непонятных
> M> репозиториев (он очень приличный список вывалил)
>
> Это не "непонятный установщик". Всё "официально":
> https://www.haskell.org/cabal/
>
> Мэйнстрим.
Я имел в виду, что не системный установщик дебиан и мне действительно не
совсем понятно, как и куда он устанавливает пакеты.
>
> M> или таки переехать на
> M> тестовую ветку со всеми ей присущими рисками.
>
> Так а зачем? pandoc достаточно часто обновляется, через cabal можно в
> любой момент обновить до актуальной версии. Причём поскольку всё это не
> на уровне системы, можно, с другой стороны, в любой момент просто
> грохнуть (вплоть до удаления всего каталога ~/.cabal).
Ага. Если он так все свое компактненько в кучке держит, то, пожалуй,
риски минимальны, буду пробовать. Дебиановские одноименные пакеты
(pandoc и citeproc) я так понимаю, лучше удалить. Чтобы не
запутаться окончательно. У меня это достаточно легко выходит.

Спасибо огромное и за наводку, и за разъяснения.

Re: Стабильная система?

[Melleus]

Алексей Витальевич Коротков  writes:

> On Thu, 24 Sep 2015 22:54:52 +0300
> Melleus wrote:
>
> M> Пытался забекпортить, но опять наткнулся на
> M> взаимоисключающие зависимости.
>
> Так а что там бэкпортить? Он есть же в jessie и в jessie-backports
> (cabal-install). Там, в принципе, есть возможность дебианизации

Я citeproc пытался бэкпортить, не cabal. Cabal установился без шуму и
пыли. Я просто пока не решил, как мне теперь лучше поступить - дать
установить непонятному установщику кучу пакетов из непонятных
репозиториев (он очень приличный список вывалил) или таки переехать на
тестовую ветку со всеми ей присущими рисками. Мне уже как-то приходилось
восстанавливать систему после неудачного обновления. Все закончилось
хорошо, но с того времени я на тестинг перехожу уже как его заморозят.

Re: Стабильная система?

[Алексей Витальевич Коротков]

On Fri, 25 Sep 2015 14:30:18 +0300
Melleus wrote:

M> Я просто пока не решил, как мне теперь лучше поступить - дать
M> установить непонятному установщику кучу пакетов из непонятных
M> репозиториев (он очень приличный список вывалил)

Это не "непонятный установщик". Всё "официально":
https://www.haskell.org/cabal/

Мэйнстрим.

M> или таки переехать на
M> тестовую ветку со всеми ей присущими рисками.

Так а зачем? pandoc достаточно часто обновляется, через cabal можно в
любой момент обновить до актуальной версии. Причём поскольку всё это не
на уровне системы, можно, с другой стороны, в любой момент просто
грохнуть (вплоть до удаления всего каталога ~/.cabal).

Re: Стабильная система?

[Алексей Витальевич Коротков]

On Thu, 24 Sep 2015 22:54:52 +0300
Melleus wrote:

M> Пытался забекпортить, но опять наткнулся на
M> взаимоисключающие зависимости.

Так а что там бэкпортить? Он есть же в jessie и в jessie-backports
(cabal-install). Там, в принципе, есть возможность дебианизации
(cabal-debian) пакетов cabal, но я не стал с этим заморачиваться.
Просто ставлю нужные мне cabal-пакеты в домашний каталог, от юзера
(cabal install нужный-cabal-пакет; в частности, я ставил так себе
pandoc и pandoc-citeproc). Всё это хозяйство обретается после установки
в ~/.cabal.

-- 
С уважением,
Алексей Витальевич Коротков,
mailto:a.v.korot...@gmail.com

Re: Стабильная система?

[Алексей Витальевич Коротков]

On Wed, 16 Sep 2015 12:42:13 +0300
Melleus wrote:

M> теперь вот наступил на грабли с неработающим пандоком

Я себе ставлю его через cabal. Нельзя сказать, что штука беспроблемная,
но pandoc как раз таким образом ставится.

-- 
С уважением,
Алексей Витальевич Коротков,
mailto:a.v.korot...@gmail.com

Re: Стабильная система?

[Melleus]

Алексей Витальевич Коротков  writes:

> Я себе ставлю его через cabal. Нельзя сказать, что штука беспроблемная,
> но pandoc как раз таким образом ставится.

Спасибо за подсказку. Пытался забекпортить, но опять наткнулся на
взаимоисключающие зависимости. Хоть и идеологически неправильно это, но
наверное, придется таки осваивать cabal. Хотя, наверное, это и не самый
правильный, но зато - самый простой способ заполучить работающий пакет в
стабильную ветку. В такие моменты все чаще посещает мысль ближе с Гентой
познакомиться. Но вот если бы еще ее не дало было компилять при каждом
обновлении и стабильность, и комьюнити чтобы. Но, наверное, не бывает в
этом мире чтоб прямо все сразу было хорошо. Всегда чего-то не
хватает. Начинаешь плюсики-минусики на бумажке рисовать - больше всех
плюсиков таки у Дебиана получается.

Еще раз спасибо.

Re: Стабильная система?

[Artem Chuprina]

Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Thu, 17 Sep 2015 
22:46:42 +0300:

 >> добавить dev-src  от тестинга
 >> и потом apt-build install pandoc/testing

 OG> У меня потянуло (хотя я на testing в deb/deb-src):

 OG>   bash# sudo apt-build build-source vim-nox
 OG>   ...
 OG>   After this operation, 20.9 MB disk space will be freed.
 OG>   Get:1 http://ftp.ua.debian.org/debian/ testing/main perl-modules all 
5.20.2-6 [2,540 kB]
 OG>   Get:2 http://ftp.ua.debian.org/debian/ testing/main perl amd64 5.20.2-6 
[2,641 kB]
 OG>   Get:3 http://ftp.ua.debian.org/debian/ testing/main perl-base amd64 
5.20.2-6 [1,209 kB]
 OG>   Get:4 http://ftp.ua.debian.org/debian/ testing/main libperl5.20 amd64 
5.20.2-6 [665 kB]
 OG>   ...

 OG> Оно потянет build dependencies из stable или testing, если бинарные пакеты 
из
 OG> stable, а исходники в testing?

Оно потянет, грубо, из более приоритетного, при равных приоритетах -
более свежий.  Подробнее - man apt_preferences.  Поэтому, если хочется
пересобрать пакет из testing для stable, то надежнее, как тут
советовали, показать apt только deb-src от тестинга (а то и вообще
вытащить исходник вручную), а deb оставить только от stable.

Re: Стабильная система?

[Melleus]

Tim Sattarov  writes:

> On 2015-09-18 11:33, Tim Sattarov wrote:
>> On 2015-09-18 07:20, Melleus wrote:
>>> Tim Sattarov  writes:
>>>
 добавить dev-src  от тестинга
 и потом apt-build install pandoc/testing
>>> Шикарный тул, одной командой все можно теперь. Жаль, что не работает:
>>>
>>> # apt-get source pandoc/stretch
>>> # apt-build source pandoc/stretch
>> Проверить, что в sources прописан именно stretch, а не sid
>> проверить
>> apt-cache policy pandoc
>> все же попробовать
>> apt-build install pandoc/stretch
>> или
>> apt-build install pandoc/sid
>>
>> ну или если хочется совсем все понять (ТМ):
>> man apt-cache
>> man apt_preferences
>> man apt-build
>> man 5 sources.list
>>
>> и в конце внимательно почитать вывод
>> apt-config dump
>>
>> :)
>> Удачи !
>>
>
> я видимо поспешил с ответом.
> в случае, когда зависимости явно требуют пакетов из новой ветки проще
> собрать с
> apt-get source и/или ковырять зависимости в  debian/rules перед сборкой
> если очень хочется оставить все остальное как было.
>
> или ставить пакеты из unstable/testing

Та ото ж. Или бэкпортов дожидаться еще...

ЗЫ Имелось в виду, что apt-get вытягивает исходники. И, кстати,
правильно тянет из сида, которые apt-build по каким-то причинам не
видит, хотя sources.list - настроен. А вот из стабильной ветки apt-build
сорцы потянул. Возможно, так и было задумано. Чтобы умельцы типа меня
чего лишнего не накуролесили. Методом научного тыка это очень легко
делается :)

Еще раз благодарю всех, кто отозвался.

Re: Стабильная система?

[Melleus]

Tim Sattarov  writes:

> On 2015-09-16 08:21, Melleus wrote:
>> Eugene Berdnikov  writes:
>>
>>>  А как насчёт пересобрать новую версию пакета в стейбле?
>> Это не мой конек. Но, наверное, это самое лучшее, что можно попытаться
>> сделать в данной ситуации. Буду разбираться как это правильно
>> делается. По-любому это займет меньше времени и усилий, чем ползание
>> между ветками и/или дистрибутивами.
>>
>> Похоже, что я нашел решение. Всем спасибо за участие.
>>
> добавить dev-src  от тестинга
> и потом apt-build install pandoc/testing

Шикарный тул, одной командой все можно теперь. Жаль, что не работает:

# apt-get source pandoc/stretch
Чтение списков пакетов… Готово
Построение дерева зависимостей
Чтение информации о состоянии… Готово
Selected version '1.13.2.1~dfsg-1' (stretch) for pandoc
ВНИМАНИЕ: упаковка «pandoc» поддерживается в системе контроля версий «Git»:
git://anonscm.debian.org/pkg-haskell/pandoc.git
Необходимо получить 1.622 kб архивов исходного кода.
Получено:1 http://ftp.se.debian.org/debian/ sid/main pandoc 1.13.2.1~dfsg-1 
(dsc)
 [5.547 B]  
Получено:2 http://ftp.se.debian.org/debian/ sid/main pandoc 1.13.2.1~dfsg-1 
(tar)
 [1.579 kB] 
Получено:3 http://ftp.se.debian.org/debian/ sid/main pandoc 1.13.2.1~dfsg-1 
(diff
) [37,1 kB] 
Получено 1.622 kБ за 2с (730 kБ/c)
dpkg-source: инфо: извлечение pandoc в pandoc-1.13.2.1~dfsg
dpkg-source: инфо: распаковывается pandoc_1.13.2.1~dfsg.orig.tar.gz
dpkg-source: инфо: распаковывается pandoc_1.13.2.1~dfsg-1.debian.tar.xz
dpkg-source: инфо: накладывается 1001_online_latexmathml_default.patch
dpkg-source: инфо: накладывается 2001_avoid_missing_files.patch
# apt-build source pandoc/stretch
W: Unable to locate package pandoc/stretch
Unable to find source candidate for pandoc/stretch
#

И кто-то ж пропускает в стабильную ветку эти поделки. А работающий
RusXMMS Taglib flawor выпилили. Так что по старинке буду собирать, без
этих новомодных поделок любителей стиля виндовозов все-в-одном. Вот
время только найду (увы, личного админа у меня нет, познаний чтобы
быстро-все-сделать-и-ничего-не-развалить не хватает /но работаю над
этим/ и полно другой работы)...

Огромное спасибо всем, кто принял участие.

Re: Стабильная система?

[Tim Sattarov]

On 2015-09-18 07:20, Melleus wrote:
> Tim Sattarov  writes:
>
>> добавить dev-src  от тестинга
>> и потом apt-build install pandoc/testing
> Шикарный тул, одной командой все можно теперь. Жаль, что не работает:
>
> # apt-get source pandoc/stretch
> # apt-build source pandoc/stretch

Проверить, что в sources прописан именно stretch, а не sid
проверить
apt-cache policy pandoc
все же попробовать
apt-build install pandoc/stretch
или
apt-build install pandoc/sid

ну или если хочется совсем все понять (ТМ):
man apt-cache
man apt_preferences
man apt-build
man 5 sources.list

и в конце внимательно почитать вывод
apt-config dump

:)
Удачи !



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Стабильная система?

[Tim Sattarov]

On 2015-09-18 11:33, Tim Sattarov wrote:
> On 2015-09-18 07:20, Melleus wrote:
>> Tim Sattarov  writes:
>>
>>> добавить dev-src  от тестинга
>>> и потом apt-build install pandoc/testing
>> Шикарный тул, одной командой все можно теперь. Жаль, что не работает:
>>
>> # apt-get source pandoc/stretch
>> # apt-build source pandoc/stretch
> Проверить, что в sources прописан именно stretch, а не sid
> проверить
> apt-cache policy pandoc
> все же попробовать
> apt-build install pandoc/stretch
> или
> apt-build install pandoc/sid
>
> ну или если хочется совсем все понять (ТМ):
> man apt-cache
> man apt_preferences
> man apt-build
> man 5 sources.list
>
> и в конце внимательно почитать вывод
> apt-config dump
>
> :)
> Удачи !
>

я видимо поспешил с ответом.
в случае, когда зависимости явно требуют пакетов из новой ветки проще
собрать с
apt-get source и/или ковырять зависимости в  debian/rules перед сборкой
если очень хочется оставить все остальное как было.

или ставить пакеты из unstable/testing




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Стабильная система?

[Melleus]

Victor Wagner  writes:

> On 2015.09.16 at 15:10:57 +0300, Melleus wrote:
>
>> Ста Деюс  writes:
>> 
>> > Из моего опыта -- всё работает в стабильной ветке.
>> 
>> За то ее и ценю. Но вот нарвался на pandoc. А там библиотечка такая есть
>> citeproc... А без списка литературы - да, работает. Но список - нужон.
>
> В смысле не работает отдельный пакет pandoc-citeproc, который нужно
> поставить в дополнение к pandoc и указать в командной строке pandoc
> --filter pandoc-citeproc?

Насколько хватает моих познаний и понимания, да. Вот так я к нему
обращаюсь:

--bibliography=... --csl=...

Направление перевода LaTeX -> odt. В тестинге это работает, так что багу
вроде бы как нет смысла вывешивать.

Re: Стабильная система?

[Tim Sattarov]

On 2015-09-17 15:46, Oleksandr Gavenko wrote:
> On 2015-09-16, Tim Sattarov wrote:
>
>> добавить dev-src  от тестинга
>> и потом apt-build install pandoc/testing
> У меня потянуло (хотя я на testing в deb/deb-src):
>
>   bash# sudo apt-build build-source vim-nox
>   ...
>   After this operation, 20.9 MB disk space will be freed.
>   Get:1 http://ftp.ua.debian.org/debian/ testing/main perl-modules all 
> 5.20.2-6 [2,540 kB]
>   Get:2 http://ftp.ua.debian.org/debian/ testing/main perl amd64 5.20.2-6 
> [2,641 kB]
>   Get:3 http://ftp.ua.debian.org/debian/ testing/main perl-base amd64 
> 5.20.2-6 [1,209 kB]
>   Get:4 http://ftp.ua.debian.org/debian/ testing/main libperl5.20 amd64 
> 5.20.2-6 [665 kB]
>   ...
>
> Оно потянет build dependencies из stable или testing, если бинарные пакеты из
> stable, а исходники в testing?
>
из моего опыта, тянутся из того же репозитария, поэтому я бы
рекоммендовал поставить build-depends
и все же оставить только deb-src:  строчку, удалив  deb: для unstable
или сделать правильный пиннинг версий


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Стабильная система?

[Tim Sattarov]

On 2015-09-17 15:46, Oleksandr Gavenko wrote:
> On 2015-09-16, Tim Sattarov wrote:
>
>> добавить dev-src  от тестинга
>> и потом apt-build install pandoc/testing
> У меня потянуло (хотя я на testing в deb/deb-src):
>
>   bash# sudo apt-build build-source vim-nox
>   ...
>   After this operation, 20.9 MB disk space will be freed.
>   Get:1 http://ftp.ua.debian.org/debian/ testing/main perl-modules all 
> 5.20.2-6 [2,540 kB]
>   Get:2 http://ftp.ua.debian.org/debian/ testing/main perl amd64 5.20.2-6 
> [2,641 kB]
>   Get:3 http://ftp.ua.debian.org/debian/ testing/main perl-base amd64 
> 5.20.2-6 [1,209 kB]
>   Get:4 http://ftp.ua.debian.org/debian/ testing/main libperl5.20 amd64 
> 5.20.2-6 [665 kB]
>   ...
>
> Оно потянет build dependencies из stable или testing, если бинарные пакеты из
> stable, а исходники в testing?
>
из моего опыта, тянутся из того же репозитария, поэтому я бы
рекоммендовал поставить build-depends
и все же оставить только deb-src:  строчку, удалив  deb: для unstable
или сделать правильный пиннинг версий


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Стабильная система?

[Oleksandr Gavenko]

On 2015-09-16, Tim Sattarov wrote:

> добавить dev-src  от тестинга
> и потом apt-build install pandoc/testing

У меня потянуло (хотя я на testing в deb/deb-src):

  bash# sudo apt-build build-source vim-nox
  ...
  After this operation, 20.9 MB disk space will be freed.
  Get:1 http://ftp.ua.debian.org/debian/ testing/main perl-modules all 5.20.2-6 
[2,540 kB]
  Get:2 http://ftp.ua.debian.org/debian/ testing/main perl amd64 5.20.2-6 
[2,641 kB]
  Get:3 http://ftp.ua.debian.org/debian/ testing/main perl-base amd64 5.20.2-6 
[1,209 kB]
  Get:4 http://ftp.ua.debian.org/debian/ testing/main libperl5.20 amd64 
5.20.2-6 [665 kB]
  ...

Оно потянет build dependencies из stable или testing, если бинарные пакеты из
stable, а исходники в testing?

-- 
Best regards!

Re: Стабильная система?

[Sohin Vyacheslav]

16.09.2015 12:42, Melleus пишет:

> Что думает уважаемое сообщество?
> 

maybe OpenSuse? как раз скоро обновится до 13.3...

-- 
BW,
Сохин Вячеслав

Re: Стабильная система?

[Andrey Tataranovich]

On Wed, 16 Sep 2015 12:42:13 +0300
Melleus  wrote:

> Всегда (и не без оснований) считал наиболее стабильным вариантом ОС
> стабильную ветку Дебиан. Но, похоже, в последнее время это все меньше
> и меньше соответствует действительности. Сначала третий гном, потом
> системд, теперь вот наступил на грабли с неработающим пандоком,
> который кто-то же ведь пустил в стабильную ветку. И случилось, как
> всегда, невовремя.
> 
> Прошу совета у уважаемого сообщества, есть ли более стабильные
> дистрибутивы, чем стабильная ветка Дебиан? Требований немного -
> мейнстримный дистрибутив (т.е. убунты не подходят) и стабильная
> работа. Машина - скромной конфигурации рабочий ноут на АМД офисно -
> писательского направления. С тестовой ветки Дебиана перелез на
> стабильную именно из-за неожиданно пойманных серьезных глюков после
> одного из обновлений. До этого больше года все было прекрасно, но
> нет. Думал, стейбл меня спасет. И, похоже, опять не угадал.
> 
> Что думает уважаемое сообщество?
> 

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

-- 
WBR, Andrey Tataranovich

Стабильная система?

[Melleus]

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

Прошу совета у уважаемого сообщества, есть ли более стабильные
дистрибутивы, чем стабильная ветка Дебиан? Требований немного -
мейнстримный дистрибутив (т.е. убунты не подходят) и стабильная
работа. Машина - скромной конфигурации рабочий ноут на АМД офисно -
писательского направления. С тестовой ветки Дебиана перелез на
стабильную именно из-за неожиданно пойманных серьезных глюков после
одного из обновлений. До этого больше года все было прекрасно, но
нет. Думал, стейбл меня спасет. И, похоже, опять не угадал.

Что думает уважаемое сообщество?

Re: Стабильная система?

[Artem Chuprina]

Melleus -> debian-russian@lists.debian.org  @ Wed, 16 Sep 2015 12:42:13 +0300:

 M> Всегда (и не без оснований) считал наиболее стабильным вариантом ОС
 M> стабильную ветку Дебиан. Но, похоже, в последнее время это все меньше и
 M> меньше соответствует действительности. Сначала третий гном, потом
 M> системд, теперь вот наступил на грабли с неработающим пандоком, который
 M> кто-то же ведь пустил в стабильную ветку. И случилось, как всегда,
 M> невовремя.

 M> Прошу совета у уважаемого сообщества, есть ли более стабильные
 M> дистрибутивы, чем стабильная ветка Дебиан? Требований немного -
 M> мейнстримный дистрибутив (т.е. убунты не подходят) и стабильная
 M> работа. Машина - скромной конфигурации рабочий ноут на АМД офисно -
 M> писательского направления. С тестовой ветки Дебиана перелез на
 M> стабильную именно из-за неожиданно пойманных серьезных глюков после
 M> одного из обновлений. До этого больше года все было прекрасно, но
 M> нет. Думал, стейбл меня спасет. И, похоже, опять не угадал.

 M> Что думает уважаемое сообщество?

Уважаемое сообщество думает, что остальные еще хуже.  Я бы предложил
снести гном (если нужно DE, попробовать LXDE), заменить systemd на
старый недобрый, но надежный SystemV init (пакет sysvinit-core; без
гнома эта замена, скорее всего, получится), ну а pandoc тупо починить...
И подождать следующего релиза, в котором, есть надежда, systemd снесут
как неудачный эксперимент.  Так уже однажды было с devfs, кажется.

Есть вариант откатиться на wheezy, но там pandoc, кажется, был не просто
сломан, а неработоспособен по построению.  Подробнее - к Витусу.

Re: Стабильная система?

[Sohin Vyacheslav]

16.09.2015 12:42, Melleus пишет:

> Что думает уважаемое сообщество?
> 

а может быть Slackware, если он еще жив?

-- 
BW,
Сохин Вячеслав

Re: Стабильная система?

[Melleus]

Andrey Tataranovich  writes:
> Баг завели?

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

Re: Стабильная система?

[Melleus]

Ста Деюс  writes:

> Из моего опыта -- всё работает в стабильной ветке.

За то ее и ценю. Но вот нарвался на pandoc. А там библиотечка такая есть
citeproc... А без списка литературы - да, работает. Но список - нужон.

Re: Стабильная система?

[Ста Деюс]

Здравствуйте, Melleus.


В Wed, 16 Sep 2015 12:42:13 +0300 вы писали:

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

Из моего опыта -- всё работает в стабильной ветке. Правда, я не
пользуюсь вашим набором программ, а задачи на моих установках
(системах) намного больше программ используют, чем просто «для
писателя». Другими словами, при желании приложения небольших усилий
получается хорошо работающая ОС («Дебиан») -- даже, и для бОльшего
спектра применения.

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

> Прошу совета у уважаемого сообщества, есть ли более стабильные
> дистрибутивы, чем стабильная ветка Дебиан? Требований немного -
> мейнстримный дистрибутив (т.е. убунты не подходят) и стабильная
> работа. Машина - скромной конфигурации рабочий ноут на АМД офисно -
> писательского направления. С тестовой ветки Дебиана перелез на
> стабильную именно из-за неожиданно пойманных серьезных глюков после
> одного из обновлений. До этого больше года все было прекрасно, но
> нет. Думал, стейбл меня спасет. И, похоже, опять не угадал.
> 
> Что думает уважаемое сообщество?

Мой личное мнение: ситуация м/т меняться в любой поставке ОС. -- Не
думаю, что вы, найдя новый «Дебиан», всю жизнь на него не нарадуетесь.
Скорее, н/о либо научиться решать возникающие то там, то сям проблемы,
либо передать эти задачи другим людям.



Всего доброго, Ста.


Справка к моим сокращениям
--
б/т - будет
воз-ть  возможность
к. - кои, коий и т.п.
кол-во - количество
м/о - можно
н/о - нужно
ОЗУ - оперативное запоминающее ус-во
ОС - операционная система
польз-ль - пользователь
т.д. - так далее
т.е. - то есть
ус-во - устройство

Re: Стабильная система?

[Melleus]

Artem Chuprina  writes:
>
> Уважаемое сообщество думает, что остальные еще хуже.  Я бы предложил
> снести гном (если нужно DE, попробовать LXDE), заменить systemd на
>
> Есть вариант откатиться на wheezy, но там pandoc, кажется, был не просто
> сломан, а неработоспособен по построению.  Подробнее - к Витусу.

Давно уже пересел на Awesome, systemd тоже выпилил. Так что
приспособился уже, можно сказать. Pandoc починили уже в тестинге
даже. Но меня туда зависимости не пускают, уже минутой раньше написал. Я
уже как-то запасался терпением, когда на wheezy сидел, думал вот выйдет
новый стейбл и наступит счастье. Ан нет, что-то лучше сделали, а что-то
- нет. И опять история повторяется. Хотя лучшего больше сделали, нужно
отметить.

Re: Стабильная система?

[Melleus]

Eugene Berdnikov  writes:

>  А как насчёт пересобрать новую версию пакета в стейбле?

Это не мой конек. Но, наверное, это самое лучшее, что можно попытаться
сделать в данной ситуации. Буду разбираться как это правильно
делается. По-любому это займет меньше времени и усилий, чем ползание
между ветками и/или дистрибутивами.

Похоже, что я нашел решение. Всем спасибо за участие.

Re: Стабильная система?

[Sergey B Kirpichev]

On Wed, Sep 16, 2015 at 02:40:19PM +0300, Melleus wrote:
> Andrey Tataranovich  writes:
> > Баг завели?
> 
> Насколько я понимаю концепцию Дебиан, то нет смысла заводить баги на
> пакеты из стабильных веток. Именно по моей проблеме - она уже решена в
> версии из тестовой ветки.

Вполне возможно, вы просто чего-то не понимаете.  В принципе, если
проблема критичная, то могут исправить и в stable:
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable

Либо пересобрать, как уже советовали.  Чтобы поправить себе карму -
результат неплохо в backports закинуть.

Re: Стабильная система?

[Eugene Berdnikov]

On Wed, Sep 16, 2015 at 02:40:19PM +0300, Melleus wrote:
> Andrey Tataranovich  writes:
> > Баг завели?
> 
> Насколько я понимаю концепцию Дебиан, то нет смысла заводить баги на
> пакеты из стабильных веток. Именно по моей проблеме - она уже решена в
> версии из тестовой ветки. Но зависимости, блин... Требует сишные
> библиотеки до тестинга обновить, а это почти всю систему за собой
> тянет... Вот и думаю, что лучше - в ногу стрельнуть (другой дистриб
> найти) или сначала за локоть себя укусить (переползти на тестинг) и,
> может быть, потом себе еще и в ногу стрельнуть.

 А как насчёт пересобрать новую версию пакета в стейбле?
-- 
 Eugene Berdnikov

Re: Стабильная система?

[Victor Wagner]

On 2015.09.16 at 13:53:06 +0300, Artem Chuprina wrote:

> Есть вариант откатиться на wheezy, но там pandoc, кажется, был не просто
> сломан, а неработоспособен по построению.  Подробнее - к Витусу.


Там pandoc был вполне работоспособен, но древен как мамонт. Поэтому
делать умел далеко не всё, что умеет свежая версия.

pandoc в jessie тоже, на мой взгляд, вполне работоспособен. Определенный 
набор тэгов markdown умеет, определенный набор выходных форматов умеет.
Если не пытаться им делать fb2 и pdf - вполне.

Но это проблема не debian, а pandoc как такового.
-- 
   Victor Wagner 

Re: Стабильная система?

[Victor Wagner]

On 2015.09.16 at 15:10:57 +0300, Melleus wrote:

> Ста Деюс  writes:
> 
> > Из моего опыта -- всё работает в стабильной ветке.
> 
> За то ее и ценю. Но вот нарвался на pandoc. А там библиотечка такая есть
> citeproc... А без списка литературы - да, работает. Но список - нужон.

В смысле не работает отдельный пакет pandoc-citeproc, который нужно
поставить в дополнение к pandoc и указать в командной строке pandoc
--filter pandoc-citeproc?

-- 
   Victor Wagner 

Re: Стабильная система?

[sergio]

On 09/16/2015 01:53 PM, Artem Chuprina wrote:


> И подождать следующего релиза, в котором, есть надежда, systemd снесут
> как неудачный эксперимент.  Так уже однажды было с devfs, кажется.

А есть что-то, что поддерживает жизнь этой надежде?


-- 
sergio.

Re: Стабильная система?

[sergio]

On 09/16/2015 03:19 PM, Sergey B Kirpichev wrote:

> Либо пересобрать, как уже советовали.  Чтобы поправить себе карму -
> результат неплохо в backports закинуть.

Не стоит думать, что backports это помойка что бы туда что-либо скидывать.

-- 
sergio.

Re: Стабильная система?

[Tim Sattarov]

On 2015-09-16 08:21, Melleus wrote:
> Eugene Berdnikov  writes:
>
>>  А как насчёт пересобрать новую версию пакета в стейбле?
> Это не мой конек. Но, наверное, это самое лучшее, что можно попытаться
> сделать в данной ситуации. Буду разбираться как это правильно
> делается. По-любому это займет меньше времени и усилий, чем ползание
> между ветками и/или дистрибутивами.
>
> Похоже, что я нашел решение. Всем спасибо за участие.
>
добавить dev-src  от тестинга
и потом apt-build install pandoc/testing




smime.p7s
Description: S/MIME Cryptographic Signature