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


S>>Вызов такой main не приводит к сайд эффектам.

M>Не приводит, а все файлы в системе удаляются через sudo. Парадокс-с
файлы удаляются при вызове action, которую вернула чистая putStr. Никакого парадокса. Еще раз смотри пример с английским текстом, что ты мне показывал выше.

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

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

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

I>Абсолютно чистая — это без IO ? Или под этим подразумевается "чуточку грязная" ?
Чуточку грязная — это о результате работы абсолютно чистой программы, включая абсолютно чистый main. Вот когда в результат подадут воду world0, результат будет делать вид что прогоняет мир через цепочку преобразований, формально на каждом этапе изменяя мир вплоть до worldXYZ, но тот world на самом деле не существует и результирующий экшн будет пачкать мир реальный.

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

S>Причины формальной чистоты putStr заключаются в частичном применении. Т.е. принимая строку в качестве единственного своего аргумента, она возвращает грязную функцию IO(), которая возьмет world1 и вернет world2, который уже со строкой в консоли.

Вот тут я снова поторопился.

putStrH = putStr "Hellow"

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

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

S>Вот здесь я должен сказать тебе спасибо.



ARK>>Тогда такой вопрос: каким образом, глядя в исходники, ты понимаешь, что функция putStr чиста? Она не вызывает никаких "грязных" функций, не так ли?
S>Не вызывает, хотя и создает грязный action, чернее мазута.

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

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

void main()
{
    Action action = EvaluatePureSourceAndReturnDirtyAction();

    ExecuteDirtyAction(action);

    return void;
}

2) Вычислителя вообще нет, он где-то снаружи:

Action main()
{
    return EvaluatePureTextAndReturnDirtyAction();
}

Возникают такие вопросы.

Если корректен вариант 1, то в чем состоит смысл выделения всей программы в action? Ведь, "раскрыв скобки", т.е. применив к чистой части ExecuteDirtyAction, мы все равно получим обычную грязную программу, с отдельными чистыми островками внутри. Почему бы сразу, без промежуточного этапа, не написать программу в виде набора грязных и чистых функций? В чем ценность этого промежуточного этапа?

Если корректен вариант 2, то в чем его отличие от программы на C++? Любая программа на С++ это тоже по сути некий грязный action, который сам по себе не выполнится, пока его кто-то не вызовет.

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

ARK>Разница с хаскелем состоит только в том, что в хаскеле еще есть и "действительно чистые" функции, для которых возможны все полезные оптимизации и рассуждения. Вопрос состоит в том, зачем "онанировать вприсядку" (с), называя грязные функции чистыми, когда можно просто явно выделить чистые функции, как в D.

Таков хаскель. Решили остаться в рамках ФП с чистыми функциями, но тк без общения с внешним миром никуда, то пришлось придумать такой трюк.
IMHO решение по натягиванию и укладке явного императива, особенно взаимодействия с внешним миром/средой, в рамки чистых функций не айс.
Так как не соответствует сути, если мы общаемся с внешним миром и особенно меняем его то и проще и думать об этом так и моделировать так, чем делать в уме трансформацию и трюки чтоб уложиться в ограничения чистых функций.
То есть вместо упрощения, мы получаем усложнение — надо понять концепцию IO (что не так-то уж и просто) и потом всегда держать в уме как оно работает.

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

S>Отож. Правда, на эту работу уйдёт несколько лет, т.к. придётся очень сильно перепахать спецификацию языка, и
S>1. Не факт, что существующие программы на С++ продолжать компилироваться компилятором, написанным по этой новой спецификации, и
S>2. Не факт, что семантика существующих компилирующихся программ будет сохранена.
S>На всякий случай поясню очевидное: если у нас теперь любая int-функция возвращает не int, а computation, то вот такая программа:
S>

int a()
S>{
S>  printf("Hello,");  
S>  return 42;
S>}
S>int b()
S>{
S>  printf(" world!);
S>}
S>int main()
S>{
S>  auto varA = a();
S>  auto varB = b();
S>  return (rand() > 50) ? varA : varB;
S>}

S>Выведет только половину фразы. Почему это так — понятно? Почему недостаточно просто "переобозвать" функции чистыми — понятно?

Это всё ты конечно правильно написал. Но в данной темке речь совсем о другом. А именно о том, что если я сделаю например такую статическую библиотечку (с одной функциий) на C++:

//cleaner.cxx
extern function<int> main(vector<string> args);

int main(int argc, char *argv[])
{
    return main(vector<string>(argv, argv+argc))();
}

И буду все свои дальнейшие проекты начинать так (с использованием новой main):

function<int> main(vector<string> args)
{
    return []{
        cout<<"Hello world!"<<endl;
        //и здесь ещё любое количество любого грязного императивного кода
        return 0;
    }
}

То по сомнительной логике samius'а, пытающегося оправдать кривизну Хаскеля, все эти мои проекты на C++ будут абсолютно чистыми программами без малейших побочных эффектов.

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

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

S>>Вот здесь я должен сказать тебе спасибо.

ARK>

ARK>>>Тогда такой вопрос: каким образом, глядя в исходники, ты понимаешь, что функция putStr чиста? Она не вызывает никаких "грязных" функций, не так ли?
S>>Не вызывает, хотя и создает грязный action, чернее мазута.

ARK>ОК, таким образом идеологически мы представляем программу на хаскеле одним из следующих способов.

ARK>1) Некоторый грязный вычислитель встроен прямо в программу, но на самом верху:

ARK>

ARK>void main()
ARK>{
ARK>    Action action = EvaluatePureSourceAndReturnDirtyAction();

ARK>    ExecuteDirtyAction(action);

ARK>    return void;
ARK>}
ARK>

да, я думаю что это близко к реальности.

ARK>2) Вычислителя вообще нет, он где-то снаружи:

ARK>

ARK>Action main()
ARK>{
ARK>    return EvaluatePureTextAndReturnDirtyAction();
ARK>}
ARK>

Тоже реально, если говорить о запуске интерпретатором. Не знаю, как на самом деле, но допускаю такую идеологическую форму.

ARK>Возникают такие вопросы.

ARK>Если корректен вариант 1, то в чем состоит смысл выделения всей программы в action? Ведь, "раскрыв скобки", т.е. применив к чистой части ExecuteDirtyAction, мы все равно получим обычную грязную программу, с отдельными чистыми островками внутри. Почему бы сразу, без промежуточного этапа, не написать программу в виде набора грязных и чистых функций? В чем ценность этого промежуточного этапа?
Это педалирование пользователей языка в сторону написания чистых своих функций и минимальному использованию "грязных" чужих библиотечных. Т.е. как бы и не запрещают иметь дело с IO, но толкают к минимуму написания своих функций, имеющих дело с IO. Если никак не контролировать этот процесс (распространения IO), то грязным будет чуть ли не весь код. Так это обычно и происходит в языках, где распространение IO не контролируется.

ARK>Если корректен вариант 2, то в чем его отличие от программы на C++? Любая программа на С++ это тоже по сути некий грязный action, который сам по себе не выполнится, пока его кто-то не вызовет.
Вот в этом контроле на уровне типов и есть отличие. В C++ можно вставить вывод записи в лог в любое место, хоть в вычисление длины списка. Оно никому не мешает, пользователи не заметят. В хаскеле при таком подходе возникает резонный вопрос, а где взять RealWorld, что бы провернуть вычисление длины списка из того места, где нет под рукой RealWorld-а. И тогда либо писать весь код в IO, что дико неудобно, либо минимизировать контакт с IO, что приносит плоды.

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

ARK>Подобное изменение спецификации С++ приведет к тому, что _формально_ все функции будут считаться чистыми. Что, на мой взгляд, есть лютый бред, обесценивающий все понятие чистоты функций.
Нет, не все. Ведь всё же функция, возвращаемая из a(), должна провзаимодействовать с IO. Вот она ни с какого боку чистой быть не может.

S>>А хаскелл тем временем вводит практически полезное определение чистоты функций.
ARK>Разница с хаскелем состоит только в том, что в хаскеле еще есть и "действительно чистые" функции, для которых возможны все полезные оптимизации и рассуждения.
Я не очень понимаю разницу между "действительно чистыми" и "чистыми" функциями в хаскеле.

S>Я не очень понимаю разницу между "действительно чистыми" и "чистыми" функциями в хаскеле.

Мне нравится подход тут: https://chadaustin.me/2015/09/haskell-is-not-a-purely-functional-language/

Everyone describes Haskell as purely-functional. Even the haskell.org front page uses the phrase "purely-functional" within the first ten words. I argue that purely-functional, while in some ways accurate, gives the wrong impression about Haskell.

I propose instead that, for most programmers, it's better to think of Haskell as a language with restricted effects.

...

Should it be called a "restricted effects language"? No, I don't think so. It is totally possible to write all of your code in IO with imperative variable updates and mutable data structures, just like you would in Python or C. It's also fine to write all of your code with pure functions invoked from a minimal main function. That is, Haskell supports many styles of programming.

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

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

I>> Это пример того, как второе значение увеличивает сложность.
S>Этот пример увеличивает сложность как с применением кортежа, так и без него.

Именно. Если не брать во внимание кортеж, про который тебе хочется поговорить, то получится "пример увеличения сложности". См ниже.

I>>Ты путаешь контекст — это пример увеличения сложности. Если ты запихал это в кортеж, часть кода станет короче, но сложность никуда не денется — как была, так и осталась. Проявляется, например, в том, что на UI нужно бОльше тестов, на API нужно бОльше тестов. В разработке аналогично — всё равно надо валидировать, т.к. инпут вида Балтимор+Россия.
S>Эта сложность появилась не от применения кортежа.

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

I>>>>Сложность восстановления(и частота ошибок) почему то зависит от количества фигур. Странно, да ?
S>>>Что это меняет?

I>>Известно что — принципиально отсутствует возможность бесплатного отката.
S>Верно для неперсистентных структур данных.

Более того — это признак неперсистентных структур данных.

I>>Итого — 1 ты согласен, что выдал огрызок и 2 пояснять отказываешься.
S>Для тебя это огрызок. И если учителя в школе не смогли пояснить, то мне это зачем?

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

I>>Совсем необязательно. Значительная часть типичного веб-приложения написана на самом православном функциональном языке — SQL, а другая — на декларативном CSS где вообще нет никакой императивщины. Что характерно, и там и там обычно багов пруд пруди. Одни заметны глазом, вызывают негатив и недоверие, а другие стоят огромных денег Что интересно — когда SQL писали руками, багов было еще больше.

S>А я и не писал что это обязательно. Наоборот, отметил что это субъективные ощущения.

А мне субъективно кажется, что количество багов зависит от
1) качества требований
2) уровень планирования, например прессинг "давай-давай" всегда ведет к увеличению багов
3) отношения разработчика к работе
4) от квалификации разработчика
5) уровень разработки на проекте, например, подходы к тестированию, проектированию и тд

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

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

S>Это педалирование пользователей языка в сторону написания чистых своих функций и минимальному использованию "грязных" чужих библиотечных. Т.е. как бы и не запрещают иметь дело с IO, но толкают к минимуму написания своих функций, имеющих дело с IO. Если никак не контролировать этот процесс (распространения IO), то грязным будет чуть ли не весь код. Так это обычно и происходит в языках, где распространение IO не контролируется.

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

ARK>>Если корректен вариант 2, то в чем его отличие от программы на C++? Любая программа на С++ это тоже по сути некий грязный action, который сам по себе не выполнится, пока его кто-то не вызовет.
S>Вот в этом контроле на уровне типов и есть отличие. В C++ можно вставить вывод записи в лог в любое место, хоть в вычисление длины списка. Оно никому не мешает, пользователи не заметят. В хаскеле при таком подходе возникает резонный вопрос, а где взять RealWorld, что бы провернуть вычисление длины списка из того места, где нет под рукой RealWorld-а. И тогда либо писать весь код в IO, что дико неудобно, либо минимизировать контакт с IO, что приносит плоды.

Вопрос был в другом. Если мы принимаем такой вариант, то в чем состоит идеологическое отличие любой программы на С++ и программы на хаскеле, состоящей исключительно из IO-функций? Я такого отличия не вижу. Но при этом хаскель утверждает, что все функции во всех программах чисты.

То есть, по пунктам:
1) есть некоторое подмножество из множества всех хаскельных программ, характеризующееся тем фактом, что ВСЕ функции в принадлежащих этому подмножеству программах являются IO;
2) спецификация хаскеля утверждает, что любые его программы — очевидно, в том числе и входящие в указанное подмножество — чисты;
3) лично я не вижу идеологических отличий любой программы ИЗ ЭТОГО ПОДМОЖЕСТВА от любой программы на С++ — вот в этом и состоит мой вопрос — есть ли тут разница, в чем она?
4) получается, если в пункте 3 разницы нет, то мы можем считать любую программу на С++ совершенно чистой.

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

ARK>>Подобное изменение спецификации С++ приведет к тому, что _формально_ все функции будут считаться чистыми. Что, на мой взгляд, есть лютый бред, обесценивающий все понятие чистоты функций.
S>Нет, не все. Ведь всё же функция, возвращаемая из a(), должна провзаимодействовать с IO. Вот она ни с какого боку чистой быть не может.

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

S>>>А хаскелл тем временем вводит практически полезное определение чистоты функций.
ARK>>Разница с хаскелем состоит только в том, что в хаскеле еще есть и "действительно чистые" функции, для которых возможны все полезные оптимизации и рассуждения.
S>Я не очень понимаю разницу между "действительно чистыми" и "чистыми" функциями в хаскеле.

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

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

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

S>>Этот пример увеличивает сложность как с применением кортежа, так и без него.

I>Именно. Если не брать во внимание кортеж, про который тебе хочется поговорить, то получится "пример увеличения сложности". См ниже.
Нет увеличения сложности, если сравнивать передачу двух параметров и одного, содержащего 2 поля.

I>Не совсем понятно, почему тебе хочется про кортеж говорить Как только в требованиях вместо "страна" появились "страна+город", сложность вырастает сама собой. И никакие "декартовы произведения", ни кортежы, ни прочие приседания тебя не спасут.
Кортеж не спасает от изменения ТЗ. Я такое не утверждал, не знаю, что ты пытаешься опровергнуть.

I>>>Известно что — принципиально отсутствует возможность бесплатного отката.
S>>Верно для неперсистентных структур данных.

I>Более того — это признак неперсистентных структур данных.
+

I>>>Итого — 1 ты согласен, что выдал огрызок и 2 пояснять отказываешься.
S>>Для тебя это огрызок. И если учителя в школе не смогли пояснить, то мне это зачем?

I>Снова из тебя понты лезут Когда говорят "удельный" то это всегда соотношение двух величин. Из твоего огрызка непонятно, про какие именно величины идет речь
За понты извини.
Что там может быть не понятно? Кол-во случаев освоения за 1-2 недели на общее кол-во попыток освоить. Например (цифры с потолка), ты утверждаешь что 20 из 100 (т.е. 0.2) студентов осваивают ип за 2 недели. Но только 1 из 100 (0.01) осваивает фп за 2 недели. Если у тебя нет таких данных, то я вообще не понимаю, что и с чем ты сравниваешь.

S>>А я и не писал что это обязательно. Наоборот, отметил что это субъективные ощущения.

I>А мне субъективно кажется, что количество багов зависит от
I>1) качества требований
I>2) уровень планирования, например прессинг "давай-давай" всегда ведет к увеличению багов
I>3) отношения разработчика к работе
I>4) от квалификации разработчика
I>5) уровень разработки на проекте, например, подходы к тестированию, проектированию и тд
Безусловно зависит от. Но это перечисление, т.е. пункты неполного и неупорядоченного списка.

I>И где то во втором десятке идут языки программирования и парадигмы. Например, при прочих равных, функционалист, которому наплевать и на работу, и на команду, и на результат, гораздо хуже ответственного педантичного студента императивщика.
Языки программирования и парадигмы не могут идти во втором десятке. Пример, возьмем для сравнения C++ с богатыми (даже стандартными) библиотеками и какой-нибудь срисованный с него MQL без спецификаций, почти без документации и абсолютно без совместимых библиотек. Почти на любом нетривиальном проекте при прочих равных мы обнаружим такую разницу в кол-ве багов, что она с головой покроет весь твой список. Это даже учитывая то, что работа с MQL не требует специальной подготовки специалиста, владеющего C или С++.
Я уж не говорю про разницу в кол-ве багов между исполнением проекта на ассемблере и C#.

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

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

ARK>В целом согласен. Это именно сознательная геморроизация написания грязного кода. Другой вопрос, что в очень многих (возможно, в большинстве) реальных программ грязный код занимает существенное место.
Вот, пришло в голову, с чем можно сравнить IO в отношении распространения в коде (и только в этом отношении). С const-ом в C++. С ним можно вообще не париться и не писать const нигде, либо лучше очень хорошо думать, где его писать, где нет. Иначе, на стыке const и не-const кода будет тихий ужас, который принудит либо снимать const в одном месте (и далее по цепочке), либо добавлять в другом. Лично я предпочитаю использовать const и это приемлемо, пока работаю над проектом один. В команде уже придется договариваться.

ARK>Вопрос был в другом. Если мы принимаем такой вариант, то в чем состоит идеологическое отличие любой программы на С++ и программы на хаскеле, состоящей исключительно из IO-функций? Я такого отличия не вижу. Но при этом хаскель утверждает, что все функции во всех программах чисты.

ARK>То есть, по пунктам:
ARK>1) есть некоторое подмножество из множества всех хаскельных программ, характеризующееся тем фактом, что ВСЕ функции в принадлежащих этому подмножеству программах являются IO;
Да, о таком подмножестве можно рассуждать. И даже если его нет, его можно создать. Одно бы я для эксперимента добавил — требования IO лишь для пользовательских функций и кода, т.е. мы не переписываем Prelude для эксперимента.

ARK>2) спецификация хаскеля утверждает, что любые его программы — очевидно, в том числе и входящие в указанное подмножество — чисты;
Нет, она не может такое утверждать (не знаю, утверждает ли на самом деле), просто потому что есть бэкдоры, позволяющие влезть с IO в функцию без сигнатуры IO. Ты сам приводил пример. Но давай представим что unsafe под табу.

ARK>3) лично я не вижу идеологических отличий любой программы ИЗ ЭТОГО ПОДМОЖЕСТВА от любой программы на С++ — вот в этом и состоит мой вопрос — есть ли тут разница, в чем она?
Здесь разница есть и она в формальном применении определения чистой функции. В практическом плане я не вижу как это можно использовать для оптимизации или для понимания кода.

ARK>4) получается, если в пункте 3 разницы нет, то мы можем считать любую программу на С++ совершенно чистой.
Считать чистой любую? Нет, не можем. Но мы не можем так же говорить о преимуществах программ хаскеля из нашего подмножества в отношении чистоты. По-крайней мере я их затрудняюсь обозначить.

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

S>Что там может быть не понятно? Кол-во случаев освоения за 1-2 недели на общее кол-во попыток освоить. Например (цифры с потолка), ты утверждаешь что 20 из 100 (т.е. 0.2) студентов осваивают ип за 2 недели. Но только 1 из 100 (0.01) осваивает фп за 2 недели. Если у тебя нет таких данных, то я вообще не понимаю, что и с чем ты сравниваешь.

Статистики я не веду. Из наблюдений функциональщину легко осваивают студенты математических специальностей. У остальных в норме ожидать затруднений.
Что касается детей на кружках алгоритмики/робототехники, то я как то не вижу смысла давать функции за 5 лет до того, как их дадут в школе
Собственно, у меня была идея вести такой кружок, но в данный момент это просто идея.

I>>5) уровень разработки на проекте, например, подходы к тестированию, проектированию и тд
S>Безусловно зависит от. Но это перечисление, т.е. пункты неполного и неупорядоченного списка.

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

I>>И где то во втором десятке идут языки программирования и парадигмы. Например, при прочих равных, функционалист, которому наплевать и на работу, и на команду, и на результат, гораздо хуже ответственного педантичного студента императивщика.
S>Языки программирования и парадигмы не могут идти во втором десятке. Пример, возьмем для сравнения C++ с богатыми (даже стандартными) библиотеками и какой-нибудь срисованный с него MQL без спецификаций, почти без документации и абсолютно без совместимых библиотек. Почти на любом нетривиальном проекте при прочих равных мы обнаружим такую разницу в кол-ве багов, что она с головой покроет весь твой список. Это даже учитывая то, что работа с MQL не требует специальной подготовки специалиста, владеющего C или С++.

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

S>Я уж не говорю про разницу в кол-ве багов между исполнением проекта на ассемблере и C#.

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

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

Фнукциональщина близка к математике, где Y = F(X) = X + 2 понятно и имеет понятное значение и детерминированное поведение.

Проблема в языках с функциональной парадигмой. Большинство из них требуют или сильно больше знаний поверх (Хаскель с его системой типов) или закручивания мозгов в достаточно противоестественные формы (Лисп с его + (1 2 3) и макросами).


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

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

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

S>>Что там может быть не понятно? Кол-во случаев освоения за 1-2 недели на общее кол-во попыток освоить. Например (цифры с потолка), ты утверждаешь что 20 из 100 (т.е. 0.2) студентов осваивают ип за 2 недели. Но только 1 из 100 (0.01) осваивает фп за 2 недели. Если у тебя нет таких данных, то я вообще не понимаю, что и с чем ты сравниваешь.

I>Статистики я не веду. Из наблюдений функциональщину легко осваивают студенты математических специальностей. У остальных в норме ожидать затруднений.
Ок, статистики нет, а рассуждать о чем-либо на основе твоих наблюдений я смысла не вижу. Я их и не оспариваю. Просто давай это примем и все.
I>Что касается детей на кружках алгоритмики/робототехники, то я как то не вижу смысла давать функции за 5 лет до того, как их дадут в школе
I>Собственно, у меня была идея вести такой кружок, но в данный момент это просто идея.
Нет смысла. Нужна самая доступная форма. Видел где-то интерактивный web-учебник для детей с автоматизацией робота на питоне. Не проникся. Моим по-крайней мере рано. Что-то вот такое (https://lightbot.com/) планирую подсунуть.

I>>>5) уровень разработки на проекте, например, подходы к тестированию, проектированию и тд
S>>Безусловно зависит от. Но это перечисление, т.е. пункты неполного и неупорядоченного списка.

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

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

I>Как только приняли решение в пользу MQL, автоматически планка качества упала, даже если мы еще ни одной строчки не написали.
I>Соответсвенно, сам принцип принятия решения важнее особенностей технологии.
Мы говорим не о принципах принятия решения, а о наличии влияния яп на качество результата. Ты выяснил, что влияет, даже если ни одной строчки еще не написали. А ты говоришь, во втором десятке факторов!

S>>Я уж не говорю про разницу в кол-ве багов между исполнением проекта на ассемблере и C#.

I>Здесь ровно так же — все известно на этапе принятия решения. Соответсвенно критическая часть не парадигма, а то, как принимают решения о выборе технологий.
Принятие решения (у меня по-крайней мере) — процесс итерационный. Выкатываешь продукт, требования меняются с ростом эксплуатации, старое решение не тащит. Тут и начинается самое интересное в принятии решений.

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

I>>Что касается детей на кружках алгоритмики/робототехники, то я как то не вижу смысла давать функции за 5 лет до того, как их дадут в школе
I>>Собственно, у меня была идея вести такой кружок, но в данный момент это просто идея.
S>Нет смысла. Нужна самая доступная форма. Видел где-то интерактивный web-учебник для детей с автоматизацией робота на питоне. Не проникся. Моим по-крайней мере рано. Что-то вот такое (https://lightbot.com/) планирую подсунуть.

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

I>>Как только приняли решение в пользу MQL, автоматически планка качества упала, даже если мы еще ни одной строчки не написали.
I>>Соответсвенно, сам принцип принятия решения важнее особенностей технологии.
S>Мы говорим не о принципах принятия решения, а о наличии влияния яп на качество результата. Ты выяснил, что влияет, даже если ни одной строчки еще не написали. А ты говоришь, во втором десятке факторов!

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

Или такие варианты:
"А давай ты до конца митинга вот эту фичу запилишь"
"Мы договорились на месяц, но надо сделать за 10 дней, + дополнительно две новые фичи, что бы показать какие мы крутые"
"Давай ты за выходные дофиксишь баклог"
Надо объяснять, что все функционалисты выпилились из того проекта?

S>>>Я уж не говорю про разницу в кол-ве багов между исполнением проекта на ассемблере и C#.

I>>Здесь ровно так же — все известно на этапе принятия решения. Соответсвенно критическая часть не парадигма, а то, как принимают решения о выборе технологий.
S>Принятие решения (у меня по-крайней мере) — процесс итерационный. Выкатываешь продукт, требования меняются с ростом эксплуатации, старое решение не тащит. Тут и начинается самое интересное в принятии решений.

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

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

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

I>Я такое давал своим детям несколько лет назад, кроме рекурсии. Это была настольная игра. Дочка только-только пошла в школу и нормально справлялась.
Есть координаты настольной игры?

S>>Мы говорим не о принципах принятия решения, а о наличии влияния яп на качество результата. Ты выяснил, что влияет, даже если ни одной строчки еще не написали. А ты говоришь, во втором десятке факторов!

I>Влияет, но только после принятия решения, и никак не раньше и поправить/скомпенсировать часто уже нет возможнсти.
I>Человек, который принимает решения определяет вообще всё, соответсвенно степень влияния менеджмента выше любых технических вопросов. Например, менеджер не только может принять решение о технологии, но и может убрать бюджет из разработки и передать в тестирование "а для багфикса студентов наймём"
Конечно, но когда я сравниваю влияние яп, я пытаюсь мысленно изолировать все остальные факторы. Т.е. берем 2 равные команды и при прочих равных одной даем писать на одном языке, другой — на другом.
I>Более того в ряде случаев менеджмент выше даже требований, если менеджеру вздумается разбавлять эти требования отсебятиной. В данном случае наличие такой отсебятины определяет качество задолго до того, как требования будут готовы.
I>Пример из жизни, менеджер и архитект по совместительству: "давайте на нетворк драйв поместим Хромиум портабл, что бы юзерам не надо было ни инсталировать, ни копировать". А тот факт, что Хромиум так работать не может, его не сильно интересует, и менеджер включает "гестапо": "Крешится Хромиум — вы неправильно ваш жээс пишете, не надо мне сказки рассказывать".
I>В итоге — полгода война между менеджером и командой разработчиков закончилась пирровой победой разработчиков, а времени на внятное решение уже нет.

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

I>Или такие варианты:
I>"А давай ты до конца митинга вот эту фичу запилишь"
I>"Мы договорились на месяц, но надо сделать за 10 дней, + дополнительно две новые фичи, что бы показать какие мы крутые"
I>"Давай ты за выходные дофиксишь баклог"
I>Надо объяснять, что все функционалисты выпилились из того проекта?
Если можно выпиливаться, то в порядке вещей вообще выпиливаться из такого проекта, невзирая на парадигму. Выглядит так, будто функционалисты оказались прошареннее.

S>>Принятие решения (у меня по-крайней мере) — процесс итерационный. Выкатываешь продукт, требования меняются с ростом эксплуатации, старое решение не тащит. Тут и начинается самое интересное в принятии решений.

I>Некоторые решения необратимы. Например "у нас на бенче 100 джаваскрипт сеньоров, будем писать на node" Наличие таких мер влияет на качество гораздо сильнее парадигмы.
Безусловно. Но кто заставляет держать таких решал на местах, где они принимают такие решения? Это же просто враги любой разработки, не говоря уж о бизнесе.

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

I>>Я такое давал своим детям несколько лет назад, кроме рекурсии. Это была настольная игра. Дочка только-только пошла в школу и нормально справлялась.
S>Есть координаты настольной игры?

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

I>>Человек, который принимает решения определяет вообще всё, соответсвенно степень влияния менеджмента выше любых технических вопросов. Например, менеджер не только может принять решение о технологии, но и может убрать бюджет из разработки и передать в тестирование "а для багфикса студентов наймём"
S>Конечно, но когда я сравниваю влияние яп, я пытаюсь мысленно изолировать все остальные факторы. Т.е. берем 2 равные команды и при прочих равных одной даем писать на одном языке, другой — на другом.

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

В целом, при прочих равных чистое ФП нужно там, где гарантии корректной и надежной работы намного важнее перформанса и потребления памяти.

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

I>>Пример из жизни, менеджер и архитект по совместительству: "давайте на нетворк драйв поместим Хромиум портабл, что бы юзерам не надо было ни инсталировать, ни копировать". А тот факт, что Хромиум так работать не может, его не сильно интересует, и менеджер включает "гестапо": "Крешится Хромиум — вы неправильно ваш жээс пишете, не надо мне сказки рассказывать".
I>>В итоге — полгода война между менеджером и командой разработчиков закончилась пирровой победой разработчиков, а времени на внятное решение уже нет.

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

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

I>>Или такие варианты:
I>>"А давай ты до конца митинга вот эту фичу запилишь"
I>>"Мы договорились на месяц, но надо сделать за 10 дней, + дополнительно две новые фичи, что бы показать какие мы крутые"
I>>"Давай ты за выходные дофиксишь баклог"
I>>Надо объяснять, что все функционалисты выпилились из того проекта?
S>Если можно выпиливаться, то в порядке вещей вообще выпиливаться из такого проекта, невзирая на парадигму. Выглядит так, будто функционалисты оказались прошареннее.

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

I>>Некоторые решения необратимы. Например "у нас на бенче 100 джаваскрипт сеньоров, будем писать на node" Наличие таких мер влияет на качество гораздо сильнее парадигмы.
S>Безусловно. Но кто заставляет держать таких решал на местах, где они принимают такие решения? Это же просто враги любой разработки, не говоря уж о бизнесе.

Я больше скажу — бизнес сам слишком часто рубит свои же хорошие начинания. Например, сами проводят собеседования на проект, который написан в функционально-реактивном стиле. Парадокс — собеседования успешно проходят в основном студенты или недавние студенты, а вот сеньоры разных сортов или не проходят, или проходят и уходят не задерживаясь. Я посмотрел, что же они спрашивают. Оказалось, что алгоритмические задачи типа рюкзаков, при чем хотят не перебор а какое нибудь эффективно решение на динамическом программировании и тд.
Фактически, эти задачи проверяют один единственный аспект, который на проекте вобщем не востребован — ну негде в рядовом приложении применить знания динамического программирования. Студенты еще помнят такие вещи, худо-бедно проходят собеседования. Сеньоры такое встречают не каждый день и даже не каждые полгода. А если проходят собес, то быстро теряют к нему интерес, т.к. математику там применить негде.
Итого — в проекте очень быстро начинается хаос. Пример хаоса — десериализуем и процессим 20мб граф в виде json в браузере. Очевидно, что все будет мерзнуть. Решение — граф транслируем в массив на сервере, а на клиент отдадим немного другим json теми же 20мб Теперь мерзнет и сервер и браузер. "Ну и что — у нас всего 5 запросов в минуту!"

Другой пример — бизнес вынуждает людей уровня сеньора заниматься всевозможными monkey job, при этом не хочет набирать ни опсов, ни девопсов, ни тестировщиков, типа "это всё код, а код лучше всего умеют писать девелоперы!!!"
Почему этим занят бизнес — а потому, что они платят деньги и вот так они обращались со своими разработчиками. Идея зашла в тупик, но они проигрывают её еще раз, но уже с оффшорными командами.