>> Боюсь, что если мы начнём сравнивать де-факто стандарт GHC и его отличия от репорта, то джава по фичам будет выглядеть вообще блекловато
А вы не бойтесь, вы сравните. Раз взялись — надо за слова отвечать, правильно? Вот и выполните этот приличный по объёму труд. Потом напишете статью на хабре про ваши мега-доводы в пользу функциональщины, ну а мы вас дружно покритикуем.
Но имейте в виду — вы постоянно передёргиваете и уходите от очевидных всем доказательств в сторону каких-то произвольных измышлений, лишь бы не признавать очевидного, а потому заминусуют вас, скорее всего.
И да, по спецификации Java — она полная. А спецификация хаскеля — недоношеный выкидыш, из которого вырезали такие скромные запчасти, как например лямбда-исчисление, я уж не говорю про теорию категорий. Но пояснения в спеке, естественно, приводятся с активнейшим использованием терминологии и лямбда-исчисления и теории категорий и ещё множества математических теорий. Ну и да, если из спеки Java вырезать все пояснения, делающие понятным механизм исполнения, то останется текста на пару десятков страниц.
И не забудьте включить в спецификацию хаскеля ещё и спецификацию компилятора, ибо без неё опять совершенно непонятно, как работает программа. Плюс расширьте спецификацию на все известные компиляторы, ведь они все по разному обеспечивают исполнение. Ну и до кучи — добавьте множество подвидов хаскеля, всяческие расширения самого языка вне спецификации, все их версии, ну а к этому, естественно, ещё и всё месиво библиотек под разные версии языка и компилятора. И в итоге получите тома, которые на порядки обгонят по толщине все виды вариабельности спецификации многоплатформенного Си вместе с расширениями в виде ++.
Но да, все эти тома никогда не будут написаны, в отличии от тех, кто вменяемо подходит к стандартизации языков. Ибо не заставишь тысячи подобных вам заняться систематическим и довольно нудным трудом, автоматической системы документирования для вас пока не придумали, а вручную — ну нет, это не ваш метод.
>> У меня таки есть маленькая, но выборка по общению с разными не умеющими программировать людьми
Ну я же говорил — каждый ребёнок с рождения мыслит рекурсиями, а как ещё доказать нужность функциональщины?
>> Так я ж не на бумажке ручкой доказываю всё же. ПруфТайпчекер мои доказательства проверяет.
Я вам уже раз сто разжевал простую истину — инструмент не знает, чего хочет программист. Но вы, конечно, можете продолжать настаивать на том, что магия вас обязательно спасёт.
Я не математик, но скажу вам одну важную истину — математика родилась от людских потребностей. И если математики об этом забудут — про них тоже все забудут.
А в плане приведённой вами последовательности, я бы (будь я популяризатором) постарался показать её значимость всем, а не очень узкому кругу фанатеющих по головоломкам. И для этого много не надо, ведь достаточно чуть пошире взглянуть на людские проблемы и найти в математике их решения. Так, например, последовательность простых чисел (слово «последовательность» не напоминает вам о необходимости увидеть общее?) даёт простым гражданам защиту от кражи их денег в интернете, а защита нужна для того, что бы не отрывая известное место от дивана оплачивать различные услуги. Вот вам и связь изучения последовательностей с очень удобным сервисом. И что вам мешало примерно так же указать класс задач, которые решаются именно при помощи алгоритмов, наработанных при исследовании аналогичных последовательностей? То есть общее между «последовательностями вообще» вижу даже я, ни разу не математик, а вы (ведь вроде математик) могли бы расширить классификацию, показать место вашей последовательности в вашей онтологии головоломок, рассказать о достижениях на пути исследования задач из данного класса, и т.д. и т.п.
Но вы просто бросили необработанный кирпич в толпу, на что толпа отреагировала абсолютно адекватно — да это же кирпич! Вот обработаете камешек, покажете блеск граней, вот тогда вам скажут — мужик, ты меня удивил!
Ну раз уж вы решились заняться членомерством, то объясняю популярно — для освоения хаскеля нужно много больше времени, по сравнению с написанием программ на Java в стиле а-ля-бэйсик. Это следствие самого функционального подхода, который противоестественен для подавляющего большинства населения, ибо в обычной жизни люди делают шаг А, потом Б, потом В, а в функциональщине все шаги нужно сконвертировать в рекурсивные вызовы функций. И понятно, что вы опять начнёте упираться и доказывать, что рекурсивные вызовы дети знают с самого рождения, но на такой трэш я отвечать уже не собираюсь.
Ну а по поводу ваших ошибок — повторю, что вы программу не запустили, а потому все ваши доказательства обязательно (рано или поздно) приведут вас к эпическому фэйлу — вы напишите сотни страниц доказательств, а работать у вас ничего не будет.
Хорошо разложено по полкам понятие индексирования. Своего рода гайд по выбору типа индекса.
Но всё же нет завершённости. Нет вывода, нет рекомендаций. То есть — есть куда ещё копать. В идеале — на входе описание предметной области (многомерного пространства), а на выходе — тип индекса.
Это же идрисовский инструмент, поэтому и не имею понятия.
Хотя да, прикрутить достижения теории рекурсивных функций к программированию с использованием рекурсивных функций — абсолютно логично. Поэтом я за такие инструменты.
>> Да и какая разница, стандартные операторы или нет, если почти все проекты не ограничиваются стандартной библиотекой, и, соответственно, вполне могут пользоваться дополнительными операторами?
Собственно это ведь тоже аргумент против широкого использования функциональных языков. Хотя я вполне был готов успокоиться на аргументе «стандартный набор приоритетов больше».
>> На идрисе доказал
Смотрите, вы сами признались, что приоритеты не помните, отсюда возможность ошибки в семантике кода, который при этом без ошибок компилируется. Что вы дальше доказывали при помощи идрис — точно так же зависит от приоритетов, то есть приоритеты вы и там могли попутать. Вот вам две причины, которые легко приведут к корректному доказательству, но некорректной работе программы относительно ваших ожиданий.
Не помню уж где, но про системы автоматического вывода было примерно такое упоминание — в одном случае программа была написана неправильно, доказательство показывало корректность программы, но в доказательстве была ошибка, и при этом в каких-то важных аспектах программа полностью оправдывала ожидания разработчиков.
В вашем случае не обязательно всё совпадёт так, что ожидания оправдаются.
>> А кстати, когда вы на С пишете, вы точно помните весь стандарт и всю семантику абстрактной машины, чтобы быть уверенным, что ваш код правильно скомпилируется?
В основном у меня — Java, но не суть, в любом случае я очень во многих случаях вспоминаю стандарт. Раньше было хуже (меньше помнил), но с опытом стало очевидно, что помнить нужно много, благо было время на неспешное запоминание, ведь в обычном коде нечасто используются многие конструкции, либо вообще заменяются на «безопасные» (например когда не заморачивался запомнить приоритет ++ заменял его на обычное сложение).
>> Вы фактически предлагаете создать гибрид между ракетой-носителем и автоматическим самолётом-дроном. В результате чего обычно не получается полноценно ни то ни другое
Зачем вы сочиняете за меня, что я предлагаю? А потом заявляете, что из предложенного вами сочинения «обычно» ничего не получается. Но «обычно», означает, что кто-то уже такое делал. Интересно — кто же это на трос ловил ракеты?
>> все эти манёвры сегодня не доступны даже для лучших и специализированных самолётных дронов
С чего вы это взяли? Дроны не умеют лететь горизонтально? Вы правда в это верите?
Завязывайте с такими безосновательными возражениям.
Речь о стандартных, поэтому не надо передёргивать.
>> Я вообще не помню приоритеты операторов
Тогда с чего вы решили, что ваш код — правильный?
>> Похоже, пришло время нудного заучивания
Убираем из этого списка скобки и прочее очевидное, получаем за исключением арифметики (включая очевидные булевы операции) в разы меньше, чем в функциональщине.
>> И таки ещё раз советую обратить внимание на уже летающие Фалконы
Обратил. Вот список различий:
1) Фалкон должен попасть в точку, а ракета должна попасть в туннель многокилометровой длины и с километр ширины. Точнее — это воронка, где на входе диаметр километров 10, а на выходе — метров 5.
2) Фалкон не имеет возможности корректировать поведение после сближение с точкой, а ракета (и самолёт тоже) могут смещаться на километры.
3) последний десяток метров фалкон вообще падает без каких-либо шансов на реакцию, а ракета может совершить несколько попыток стыковки с многократным удалением и сближением.
4) Ну и турбулентность — для попадания в точку фалкону нужно гарантировать компенсацию ветровой нагрузки в самых плотных слоях, плюс изменение аэродинамики из-за раздвигания ног (из-за неё он и взрывался), а ракете нет нужды в стиле камикадзе садиться с первого раза, она легко дождётся результатов зондирования атмосферы лидарами и подойдёт в самый спокойный момент, без значимых турбулентностей.
В целом на стороне ракеты — огромное резервное время. Просто бесконечно большое в сравнении с миллисекундами фалкона.
А трос будет выпускать тот, для кого это выгоднее. Сверху ракете вроде проще (ибо сила тяжести), но прицельные приспособления и механизмы притягивания — лишний вес. Надо считать.
В статье (да и во всех подобных) указывается, что мутаций много. В частности здесь приведён пример 80-20, когда 80% вредных клеток можно убить таргетировано, но 20% оставшихся будут делиться и создадут новую проблему. Плюс они мутируют «по ходу пьессы». Поэтому просто пройтись по всем и отстрелить «неправильные» ДНК не получится. К тому же «неправильные» ДНК бывают безопасными, а потому придётся убивать много полезных клеток. Ну а разобраться во всей этой каше могут далеко не все врачи, поэтому и со стороны выбора метода лечения тоже есть засада.
>> А вы предлагаете фактически падающую (!) ракету ловить
Я предлагаю ловить летящую ракету, а не падающую. И да, самолёты для вывода и для спуска могут быть разными, потому что возвращаемая масса во много раз меньше выводимой. В пределе можно возвращать только самое ценное — двигатели, плюс ещё какое-то дорогое оборудование, что уместится в компактный спускаемый аппарат с, возможно, немного выдвигаемыми крыльями для поддержания планирования в течении минут пяти. Ну а электроника выведет аппарат точно на возвращающий самолёт. Собственно стыковка так же возможна без жёсткого соприкосновения, а по используемому для дозаправки «методу шланга», то есть ракета притягивается в «гездо» тросом, ошибка в наведении которого может быть метров 10 продольная и метров 5 поперечная.
В общем — никаких катастроф при элементарном обдумывании.
А не проще обычный самолёт, ну может сверхзвуковой, обеспечивающий взлёт и посадку, а над ним — ракета с микро-крыльями. После взлёта самолёт выводит ракету в разряжённые слои и запускает под каким-то приличным углом (как в давно известных проектах воздушного старта), а при посадке ракета некоторое время обеспечивает с помощью микро-крыльев скорость (плюс выводится в точку стыковки), соответствующую скорости самолёта-носителя, который и подхватывает ракету вместо вертолёта, предлагаемого в статье. Затем обычная самолётная посадка, ну а вместо топлива при посадке ракету можно загрузить, понятное дело, золотом и прочими алмазами с так распространённых в космосе астероидов с самоцветами :)
>> поэтому некорректный порядок поймается на уровне типов
В данном случае не поймается — на входе функции список, на выходе конкатенации тоже; на выходе функции список, на входе конкатенации тоже. То есть хоть так, хоть так — будет валидный код.
В Хаскеле, например (а он похож по синтаксису на Идрис), есть 22 оператора с приоритетами от 3 до 9 и двумя ассоциативностями — левой и правой. Приоритетов №9 — два, №8 — два, №7 — 4, №6 — 2, №5 — 2, №4 — 8, №3 — 2. Это без учёта приоритета аргументов функции и конструкций типа &.
И это всё должен знать каждый участник команды разработки, просто что бы понимать код коллег. Без такого знания будут муки и адское затягивание сроков.
В Си-подобных языках из приоритетов, кроме стандартных арифметических, вот разве что битовые операции. И всё. Плюс обязательность использования скобок, что само по себе устраняет массу вопросов типа того, который мы сейчас обсуждаем.
А вы не бойтесь, вы сравните. Раз взялись — надо за слова отвечать, правильно? Вот и выполните этот приличный по объёму труд. Потом напишете статью на хабре про ваши мега-доводы в пользу функциональщины, ну а мы вас дружно покритикуем.
Но имейте в виду — вы постоянно передёргиваете и уходите от очевидных всем доказательств в сторону каких-то произвольных измышлений, лишь бы не признавать очевидного, а потому заминусуют вас, скорее всего.
И да, по спецификации Java — она полная. А спецификация хаскеля — недоношеный выкидыш, из которого вырезали такие скромные запчасти, как например лямбда-исчисление, я уж не говорю про теорию категорий. Но пояснения в спеке, естественно, приводятся с активнейшим использованием терминологии и лямбда-исчисления и теории категорий и ещё множества математических теорий. Ну и да, если из спеки Java вырезать все пояснения, делающие понятным механизм исполнения, то останется текста на пару десятков страниц.
И не забудьте включить в спецификацию хаскеля ещё и спецификацию компилятора, ибо без неё опять совершенно непонятно, как работает программа. Плюс расширьте спецификацию на все известные компиляторы, ведь они все по разному обеспечивают исполнение. Ну и до кучи — добавьте множество подвидов хаскеля, всяческие расширения самого языка вне спецификации, все их версии, ну а к этому, естественно, ещё и всё месиво библиотек под разные версии языка и компилятора. И в итоге получите тома, которые на порядки обгонят по толщине все виды вариабельности спецификации многоплатформенного Си вместе с расширениями в виде ++.
Но да, все эти тома никогда не будут написаны, в отличии от тех, кто вменяемо подходит к стандартизации языков. Ибо не заставишь тысячи подобных вам заняться систематическим и довольно нудным трудом, автоматической системы документирования для вас пока не придумали, а вручную — ну нет, это не ваш метод.
Ну я же говорил — каждый ребёнок с рождения мыслит рекурсиями, а как ещё доказать нужность функциональщины?
>> Так я ж не на бумажке ручкой доказываю всё же. ПруфТайпчекер мои доказательства проверяет.
Я вам уже раз сто разжевал простую истину — инструмент не знает, чего хочет программист. Но вы, конечно, можете продолжать настаивать на том, что магия вас обязательно спасёт.
А в плане приведённой вами последовательности, я бы (будь я популяризатором) постарался показать её значимость всем, а не очень узкому кругу фанатеющих по головоломкам. И для этого много не надо, ведь достаточно чуть пошире взглянуть на людские проблемы и найти в математике их решения. Так, например, последовательность простых чисел (слово «последовательность» не напоминает вам о необходимости увидеть общее?) даёт простым гражданам защиту от кражи их денег в интернете, а защита нужна для того, что бы не отрывая известное место от дивана оплачивать различные услуги. Вот вам и связь изучения последовательностей с очень удобным сервисом. И что вам мешало примерно так же указать класс задач, которые решаются именно при помощи алгоритмов, наработанных при исследовании аналогичных последовательностей? То есть общее между «последовательностями вообще» вижу даже я, ни разу не математик, а вы (ведь вроде математик) могли бы расширить классификацию, показать место вашей последовательности в вашей онтологии головоломок, рассказать о достижениях на пути исследования задач из данного класса, и т.д. и т.п.
Но вы просто бросили необработанный кирпич в толпу, на что толпа отреагировала абсолютно адекватно — да это же кирпич! Вот обработаете камешек, покажете блеск граней, вот тогда вам скажут — мужик, ты меня удивил!
Ну а по поводу ваших ошибок — повторю, что вы программу не запустили, а потому все ваши доказательства обязательно (рано или поздно) приведут вас к эпическому фэйлу — вы напишите сотни страниц доказательств, а работать у вас ничего не будет.
Но всё же нет завершённости. Нет вывода, нет рекомендаций. То есть — есть куда ещё копать. В идеале — на входе описание предметной области (многомерного пространства), а на выходе — тип индекса.
Хотя да, прикрутить достижения теории рекурсивных функций к программированию с использованием рекурсивных функций — абсолютно логично. Поэтом я за такие инструменты.
Собственно это ведь тоже аргумент против широкого использования функциональных языков. Хотя я вполне был готов успокоиться на аргументе «стандартный набор приоритетов больше».
>> На идрисе доказал
Смотрите, вы сами признались, что приоритеты не помните, отсюда возможность ошибки в семантике кода, который при этом без ошибок компилируется. Что вы дальше доказывали при помощи идрис — точно так же зависит от приоритетов, то есть приоритеты вы и там могли попутать. Вот вам две причины, которые легко приведут к корректному доказательству, но некорректной работе программы относительно ваших ожиданий.
Не помню уж где, но про системы автоматического вывода было примерно такое упоминание — в одном случае программа была написана неправильно, доказательство показывало корректность программы, но в доказательстве была ошибка, и при этом в каких-то важных аспектах программа полностью оправдывала ожидания разработчиков.
В вашем случае не обязательно всё совпадёт так, что ожидания оправдаются.
>> А кстати, когда вы на С пишете, вы точно помните весь стандарт и всю семантику абстрактной машины, чтобы быть уверенным, что ваш код правильно скомпилируется?
В основном у меня — Java, но не суть, в любом случае я очень во многих случаях вспоминаю стандарт. Раньше было хуже (меньше помнил), но с опытом стало очевидно, что помнить нужно много, благо было время на неспешное запоминание, ведь в обычном коде нечасто используются многие конструкции, либо вообще заменяются на «безопасные» (например когда не заморачивался запомнить приоритет ++ заменял его на обычное сложение).
То есть у вас кончились аргументы против?
>> Вы фактически предлагаете создать гибрид между ракетой-носителем и автоматическим самолётом-дроном. В результате чего обычно не получается полноценно ни то ни другое
Зачем вы сочиняете за меня, что я предлагаю? А потом заявляете, что из предложенного вами сочинения «обычно» ничего не получается. Но «обычно», означает, что кто-то уже такое делал. Интересно — кто же это на трос ловил ракеты?
>> все эти манёвры сегодня не доступны даже для лучших и специализированных самолётных дронов
С чего вы это взяли? Дроны не умеют лететь горизонтально? Вы правда в это верите?
Завязывайте с такими безосновательными возражениям.
Речь о стандартных, поэтому не надо передёргивать.
>> Я вообще не помню приоритеты операторов
Тогда с чего вы решили, что ваш код — правильный?
>> Похоже, пришло время нудного заучивания
Убираем из этого списка скобки и прочее очевидное, получаем за исключением арифметики (включая очевидные булевы операции) в разы меньше, чем в функциональщине.
Обратил. Вот список различий:
1) Фалкон должен попасть в точку, а ракета должна попасть в туннель многокилометровой длины и с километр ширины. Точнее — это воронка, где на входе диаметр километров 10, а на выходе — метров 5.
2) Фалкон не имеет возможности корректировать поведение после сближение с точкой, а ракета (и самолёт тоже) могут смещаться на километры.
3) последний десяток метров фалкон вообще падает без каких-либо шансов на реакцию, а ракета может совершить несколько попыток стыковки с многократным удалением и сближением.
4) Ну и турбулентность — для попадания в точку фалкону нужно гарантировать компенсацию ветровой нагрузки в самых плотных слоях, плюс изменение аэродинамики из-за раздвигания ног (из-за неё он и взрывался), а ракете нет нужды в стиле камикадзе садиться с первого раза, она легко дождётся результатов зондирования атмосферы лидарами и подойдёт в самый спокойный момент, без значимых турбулентностей.
В целом на стороне ракеты — огромное резервное время. Просто бесконечно большое в сравнении с миллисекундами фалкона.
А трос будет выпускать тот, для кого это выгоднее. Сверху ракете вроде проще (ибо сила тяжести), но прицельные приспособления и механизмы притягивания — лишний вес. Надо считать.
Наутилусы во всю под водой путешествуют. Тоже дичь?
Я предлагаю ловить летящую ракету, а не падающую. И да, самолёты для вывода и для спуска могут быть разными, потому что возвращаемая масса во много раз меньше выводимой. В пределе можно возвращать только самое ценное — двигатели, плюс ещё какое-то дорогое оборудование, что уместится в компактный спускаемый аппарат с, возможно, немного выдвигаемыми крыльями для поддержания планирования в течении минут пяти. Ну а электроника выведет аппарат точно на возвращающий самолёт. Собственно стыковка так же возможна без жёсткого соприкосновения, а по используемому для дозаправки «методу шланга», то есть ракета притягивается в «гездо» тросом, ошибка в наведении которого может быть метров 10 продольная и метров 5 поперечная.
В общем — никаких катастроф при элементарном обдумывании.
В данном случае не поймается — на входе функции список, на выходе конкатенации тоже; на выходе функции список, на входе конкатенации тоже. То есть хоть так, хоть так — будет валидный код.
И это всё должен знать каждый участник команды разработки, просто что бы понимать код коллег. Без такого знания будут муки и адское затягивание сроков.
В Си-подобных языках из приоритетов, кроме стандартных арифметических, вот разве что битовые операции. И всё. Плюс обязательность использования скобок, что само по себе устраняет массу вопросов типа того, который мы сейчас обсуждаем.