Концепции программирования для разных логик.

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

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

Тем не менее, выставляя Форт, можно императивные языки поставить в середину между ним и языками функциональными.

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

- Форт - это язык для БЛ. Общую структуру программы программист прекрасно держит в голове, взаимосвяз объектов очевидна, но, у всех БЛ проблема - безошибочная компоновка низкоуровневых, конечных, чернологичных элементов. Форт тут приодит на помощь, позволяя составлять программу из крошечных элементов, связи которых с внешними элементами строго заданы, а размер такой ("психологические" 7+/-2 активных элемента), что просто не позволяет развиться в них паразитным связям и особым ситуациям, которы программист-статик легко зевнёт. Зато, каждый такой кирпичик, легко отлаживается отдельно. Имея же набор безошибочно работающих кирпичиков, белый логик легко потом их соединить в целостную большую структуру - программу.

- Императивные языки находятся прмерно посередине, имея достоинства и недостатки и того и другого подхода...

...

Кстати, общая тенденция "чернологизации" программирования последних 10..15 лет, наверное, и объясняет то, что тот же Форт был практически вытеснен с рынка. Чёрному логику довольно неуютно в нём.

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

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

К сожалению, не работал с Фортом настолько, чтобы его заценить с этой стороны

Кроме того, нельзя забывать про вторую сильную ментальную. Не знаю, как с БС, но БИ очень даже помогает в цельном восприятии программы со всеми ее связями. Но представляется скорее не структура, а поток (в динамике). (Собственно, восприятие программы именно как БЛ-структуры - не универсально, это лишь частный случай). Что опять же склоняет к императивным язкам. Функциональные - это как раз чистая статика Может, ЧЛ-статикам они действительно ближе?

Zeus> Хмм... Что-то тут не так. Как раз наоборот, ЧЛ (особенно творческие) хорошо знают, как что-то делать. Они легко описывают способ решения, порядок действий.

Вот о чём я и говорю! Они легко описывают порядок действий, но не могут увязать этот порядок в структуру программы. За них это должен делать язык!

>Поэтому им нужен императивный язык.

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

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

Ты просто, работая с императивными языками, прявык не доверять языку. И пытаешься сам контролировать всё. Доверься языку. Тем более, что те же O'Caml или Haskell сделают всё настолько грамотно, насколько чёрному логику будет сделать что либо тяжело даже при интенсивном, так сказать, приложении силы

Zeus> К сожалению, не работал с Фортом настолько, чтобы его заценить с этой стороны

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

Zeus> Кроме того, нельзя забывать про вторую сильную ментальную. Не знаю, как с БС, но БИ очень даже помогает в цельном восприятии программы со всеми ее связями.

Ну да... "Интуиция - та же логика, только быстрая". Увы, тут это не прокатит. Т.к. структуру нужно знать не примерно, а точно Т.е. определённая помощь будет, но безошибочно писать программы не поможет

>(Собственно, восприятие программы именно как БЛ-структуры - не универсально, это лишь частный случай).

А я и не говорил этого. Я, мне казалось, совершенно недвусмысленно указал, что любая программа - это ЧЛ+БЛ И, соответственно, чёрным логикам приходится затыкать пробелы в своей БЛ, а белым - слабости в ЧЛ

>Функциональные - это как раз чистая статика

Ты не с той точки зрения смотришь Функциональные языки - это БЛ-подпорка для ЧЛ-программистов

Balancer> Э... Мсье видел Azureus? Eclipse-SDK? Coccinella? Замечательные приложения. Если что и не по душе, так это то, что по дефолту интерфейс имеет свой Java-стиль, а не системный, скажем, GTK. Он неплох, но хочется единообразия

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

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

Balancer> Нужно знать что там есть. Это всегда и для всего. А вот как оно работает - тебе не пофиг ли? Ты же не хочешь в своей программе заниматься отрисовкой каждого пиксела? Более того - управлять выводом каждого бита в ЦАП

Ну... Не, я согласен, что чаще всего этого не надо, или не стоит трудов. Но я все равно предпочитаю знать Это порой позволяет понять, откуда уши растут у каких-нибудь глюков/особенностей/неработоспособности/проблем производительности. И даже их обходить. Вот, кстати, особенности опроса ЦАП (не видео, специальной) мне оказались нужны в свое время То есть именно знание его работы позволило понять странности поведения системы. И таких случаев очень много. Но они проходят скорее по разделу БИ Бальзачья привычка собирать всякую информацию (даже неосознанно подмечать) - "а вдруг пригодится"

Zeus>> А я вижу, я говорил, простейший вариант восприятия - поток команд.
Balancer> А как же асинхронность тогда?

Точно так же. Вернее, не совсем. Сам процесс взаимодействия (двух нитей, например) можно рассматривать как набор команд. Или лучше сказать - транзакций, или что-то такое.

Balancer> У тебя не динамику отбирают, а рутину Или ты собрался в машинных кодах писать? По мере роста вычислительных мощностей компьютеров, объём задач, которые они могут решать эффективнее программиста всё растёт. Сначала - расстановка адресов при переходе от машкода к ассемблеру. Потом - макросы. Императивные конструкиции. Сейчас приходит время конструкций функциональных. Компьютеры становятся слишком сложными, чтобы эффективно расписывать задачу на последовательность действий вручную. Решая эту задачу вместо компьютера ты теряешь в производительности

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

Balancer> А, возвращаясь к исходной постановке задачи, ФП-языки с тебя, как с ЧЛ, и снимают чернологичную рутину. Да, ты бы и сам её легко, может быть, сделал, но компьютер это сделает лучше. А ты сможешь больше внимания уделить тому, что для тебя сложнее - БЛ

Так это нелогично! (С моей как бы точки зрения). Логичным было бы наоборот: пусть компьютер делает то, что мне трудно, т.е. БЛ. А то, что мне просто, я и сам сделаю

А так, получается, мне работу практически не облегчают. "При прочих равных", если комп даже ЧЛ-работу делает лучше меня, то БЛ-работу он тем более лучше сделает (просто потому, что она у меня хуже получается). Что, не умеет? Тогда, наоборот, странно, откуда "ЧЛ-изация" программирования. Наоборот, БЛогикам должно быть раздолье: наконец-то комп трудную для них ЧЛ-работу делает хорошо. ФП им в руки
Так?

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

Гы. В sun-jdk, например, среди прочих демок поставляется SwingSet2. Запусти и посмотри - в Look&Fill можно выбрать ажно три разных (по карйней мере под Linux) варианта интерфейса. Родной Java, Motiff и GTK2. Самый приятный и вылизанный - как раз родной

Zeus> Мне вот Матлаба хватает, я на него смотрю И я утверждаю, что его интерфейс глючит неимоверно, причем в совершенно "детских" местах, вроде скроллирования.

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

Zeus> К чему это мы? Видимо, к тому, что "вручную" все-таки нередко имеет смысл делать и, соответственно, знать, как оно работает. Это верно как для того, чтобы писать "с нуля", команда за командой, так и для "обхождения глюков".

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

Zeus> Ну... Не, я согласен, что чаще всего этого не надо, или не стоит трудов. Но я все равно предпочитаю знать Это порой позволяет понять, откуда уши растут у каких-нибудь глюков/особенностей/неработоспособности/проблем производительности. И даже их обходить. Вот, кстати, особенности опроса ЦАП (не видео, специальной) мне оказались нужны в свое время То есть именно знание его работы позволило понять странности поведения системы. И таких случаев очень много. Но они проходят скорее по разделу БИ

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

Zeus> Так это нелогично! (С моей как бы точки зрения). Логичным было бы наоборот: пусть компьютер делает то, что мне трудно, т.е. БЛ.

Вот ФПЯ БЛ-связыванием (точнее, детальной его проработкой) и займутся

Zeus> А так, получается, мне работу практически не облегчают.

А ещё, такое впечатление, что ЧЛ плохо оценивают объёмы работ

Zeus> Наоборот, БЛогикам должно быть раздолье: наконец-то комп трудную для них ЧЛ-работу делает хорошо. ФП им в руки

Это уже не ФП, а любой оптимизирующий компилятор. Я им стал доверять ещё во времена Watcom 10, когда увидел, что на средней задаче компилятор быстрее и эффективнее меня оптиимзирует код

Balancer> Гы. В sun-jdk, например, среди прочих демок поставляется SwingSet2. Запусти и посмотри - в Look&Fill можно выбрать ажно три разных (по карйней мере под Linux) варианта интерфейса. Родной Java, Motiff и GTK2. Самый приятный и вылизанный - как раз родной

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

Balancer> Скорее он пользуется какими-то весьма древними библиотеками. Тот же Eclipse не только нигде не тормозит, но и на сегодня это едва ли не самая лучшая межплатформенная (и в плане хостов и в плане проектов) IDE. Вряд ли бы эту IDE за первый месяц скачали миллион раз, если б она была отстоем

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

Balancer> Это, безусловно полезно. Вот только мы с тобой проводим границу допустимого в разных местах

Очевидно

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

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

Balancer> Вот ФПЯ БЛ-связыванием (точнее, детальной его проработкой) и займутся

Ты ведь только что утверждал, что ФПЯ именно грубую ЧЛ-работу делают? (И причем здесь оптимизация, мы же не об этом уровне говорим).

Zeus>> А так, получается, мне работу практически не облегчают.
Balancer> А ещё, такое впечатление, что ЧЛ плохо оценивают объёмы работ

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