Программирование-в-малом — это программирование в рамках одного процесса (адресного пространства оперативной памяти).
Программирование-в-большом — это обеспечение координированной работы многих процессов, как в пространстве (распределенное программирование) так и во времени (файловые системы и базы данных).
Про функциональное програмирование здесь уже дискутировали много раз — но только в рамках программирования-в-малом.
Внимание, вопрос — кто какие наработки знает по теме функционального программирования-в-большом?
Ведь казалось бы, преимущества функционального программирования здесь должны проявится ярче, а недостатки не так важны.
Я могу привести лишь один пример — системы контроля версий (SVN, CVS, Git и т.п.). Используемые а них структуры данных — change set'ы, иммутабельные состояния рабочих пространств — вполне себе функциональны. Но разработчики таких систем нигде открыто не заявляют о приверженности фйнкциональному программированию. Похоже что они, как и неграмотный господин Журден, и не подозревают, что "говорят прозой". Во всяком случае, они при любом удобном случае готовы вернуться в лоно процедурного программирования.
А между тем, последовательное применение функционального программирования сняло бы множество проблем, в первую очередь проблему воспроизводимости. Меня эта проблема уже достала, например:
— я сделал версию, закоммитил, коллега ее подкачал и говорит: "не работает". Я все бросаю, теряю время на выснение причины.
— коллега сделал версию, я ее скачал, и ... (см выше).
И это при условии приминения системы контроля версий, которая уже берет на себя массу необходимых действий. Но остается еще много дыр — переменные окружения, настроенные по разному, из-за чего используются разные версии утилит (make, sh, etc) и другие.
Итак, начинаем марафон по замене процедурного программирования функциональным в области программирование-в-большом. Собираем уже работающие ростки и проблемы процедурного программирования, от которых можно будет избавится.
Если кто захочет написать, что у меня ничего не выйдет — пусть пишет, будем учиться переубеждать скептиков.
Здравствуйте, rfq, Вы писали:
rfq>Итак, начинаем марафон по замене процедурного программирования функциональным в области программирование-в-большом. Собираем уже работающие ростки и проблемы процедурного программирования, от которых можно будет избавится.
Кэп: проблема как правило не в инструменте, а в его применении.
Попробуйте сначала сформулировать чётко и коротко, что вы хотите получить в итоге и как вы собираетесь убедиться, что оно того стоило. Буквально пара предложений, только без лозунгов "за всё хорошее и против всего плохого".
Получится — можно и в крестовый поход сходить. Нет — на что вы тогда надеетесь?
Здравствуйте, rfq, Вы писали:
rfq>Программирование-в-малом — это программирование в рамках одного процесса (адресного пространства оперативной памяти). rfq>Программирование-в-большом — это обеспечение координированной работы многих процессов, как в пространстве (распределенное программирование) так и во времени (файловые системы и базы данных).
Программирование по-малому и программирование по-большому.
Простите, не удержался...
Нет такого преступления, на которое не пошло бы суверенное родоплеменное быдло ради продления своего бессмысленного рода и распространения своего бессмысленного генома.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, rfq, Вы писали: S>Попробуйте сначала сформулировать чётко и коротко, что вы хотите получить в итоге и как вы собираетесь убедиться, что оно того стоило. Буквально пара предложений, только без лозунгов "за всё хорошее и против всего плохого".
"сформулировать чётко и коротко" — это самое трудное в нашей жизни. Я размышляю об этой проблеме 30 лет. Сначала это были смутные ощущения, что что-то где-то не так. Затем пришло некоторое понимание, как правильно организовывать распределенные вычисления и как — неправильно. Затем возникла мысль, что существует программирование-в-большом и оно устроено неправильно. Послушали бы вы мои тогдашние попытки рассказать о мучившей меня проблеме — вот где было расплывчато и длинно. И вот наконец, я сформулировал четко и коротко: функциональное программирование-в-большом. Если для вас это не четко и не коротко, ждите другие 30 лет — или помогите мне в улучшении этой формулировки.
Здравствуйте, rfq, Вы писали:
rfq> функциональное программирование-в-большом. Если для вас это не четко и не коротко, ждите другие 30 лет — или помогите мне в улучшении этой формулировки.
Это не формулировка, это баззворд, как DevOps или XaaS.
Ну, т.е. воевать за всё хорошее можно до бесконечности, но конкретики обычно не бывает.
Если вернуться к стартовому сообщению: как заключение "Теперь у нас всё — ФП" поможет бороться с "у меня всё работает"?
Проблема-то как правило в повторении входных данных, а не в "код сделан не по фен-шую".
Здравствуйте, rfq, Вы писали:
rfq>Программирование-в-малом — это программирование в рамках одного процесса (адресного пространства оперативной памяти). rfq>Программирование-в-большом — это обеспечение координированной работы многих процессов, как в пространстве (распределенное программирование) так и во времени (файловые системы и базы данных). rfq>Про функциональное програмирование здесь уже дискутировали много раз — но только в рамках программирования-в-малом.
А если используется shared memory между процессами? А если используется RDMA?
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, rfq, Вы писали:
rfq>>Программирование-в-малом — это программирование в рамках одного процесса (адресного пространства оперативной памяти). rfq>>Программирование-в-большом — это обеспечение координированной работы многих процессов, как в пространстве (распределенное программирование) так и во времени (файловые системы и базы данных). rfq>>Про функциональное програмирование здесь уже дискутировали много раз — но только в рамках программирования-в-малом.
A>А если используется shared memory между процессами? А если используется RDMA?
Четкой границы тут нет, всегда найдутся пограничные варианты типа приведенных вами. Как удобнее, так и считайте. Важно, используются функциональные структуры или нет.
Базовая функциональная структура данных — это поток сообщений, связывающий два процесса. Даже если он реализован с помощью shared memory, он остается функциональным, и свзываеме процессы могут образовывать функциональную систему — если не будет других препятствий.
Здравствуйте, rfq, Вы писали:
rfq>Здравствуйте, Sinix, Вы писали:
rfq>"сформулировать чётко и коротко" — это самое трудное в нашей жизни.
вероятно вы не знакомы с наработками в этой области. функциональное распределенное программирование -- оно же повсюду.
покажем на примере задачи заварить чай. кто-то реализует сущность вода, кто-то реализует сущность водопровод, кто-то реализует сущность кухонный кран.
ничего не напоминает? вода это контент. водопровод это транспорт. если водопровод прорвало, то есть сущность "доставка воды водовозом".
можно и другие сущности реализовать...
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, rfq, Вы писали:
rfq>Программирование-в-малом — это программирование в рамках одного процесса (адресного пространства оперативной памяти). rfq>Программирование-в-большом — это обеспечение координированной работы многих процессов, как в пространстве (распределенное программирование) так и во времени (файловые системы и базы данных). rfq>Про функциональное програмирование здесь уже дискутировали много раз — но только в рамках программирования-в-малом.
Ээээ. Месье не слышал про эрланг?
Здравствуйте, nigh, Вы писали:
N>Здравствуйте, rfq, Вы писали:
rfq>>Программирование-в-малом — это программирование в рамках одного процесса (адресного пространства оперативной памяти). rfq>>Программирование-в-большом — это обеспечение координированной работы многих процессов, как в пространстве (распределенное программирование) так и во времени (файловые системы и базы данных). rfq>>Про функциональное програмирование здесь уже дискутировали много раз — но только в рамках программирования-в-малом. N>Ээээ. Месье не слышал про эрланг?
А что, эрланг может заменить операционную cистему с ее переменными окружения, файловской системой и всем остальным, что не укладывается в парадигму функционального программирования?
Интересно бы послушать детали такой революции.
Здравствуйте, rfq, Вы писали:
rfq>Программирование-в-малом — это программирование в рамках одного процесса (адресного пространства оперативной памяти). rfq>Программирование-в-большом — это обеспечение координированной работы многих процессов, как в пространстве (распределенное программирование) так и во времени (файловые системы и базы данных). rfq>Про функциональное програмирование здесь уже дискутировали много раз — но только в рамках программирования-в-малом.
Паради́гма программи́рования — это совокупность идей и понятий, определяющих стиль написания компьютерных программ (подход к программированию). Это способ концептуализации, определяющий организацию вычислений и структурирование работы, выполняемой компьютером.
Дальше смотрите список, чтобы было понятнее напишу парадигмы реализуемые в чистом C++, то есть без библиотек алгоритмов (процедурная, функциональная, обобщённая, объектно-ориентированная):
Процеду́рное программи́рование — программирование на императивном языке, при котором последовательно выполняемые операторы можно собрать в подпрограммы, то есть более крупные целостные единицы кода, с помощью механизмов самого языка.
Функциона́льное программи́рование — раздел дискретной математики и парадигма программирования, в которой процесс вычисления трактуется как вычисление значений функций в математическом понимании последних (в отличие от функций как подпрограмм в процедурном программировании).
Обобщённое программирование (англ. generic programming) — парадигма программирования, заключающаяся в таком описании данных и алгоритмов, которое можно применять к различным типам данных, не меняя само это описание.
Объе́ктно-ориенти́рованное программи́рование (ООП) — методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования.
Упрощённо я это понимаю как: процедурное — значение как аргумент, функциональное — функция как аргумент, обобщённое — тип как аргумент, объектно-ориентированное — разделение на объекты. Можно так же углубиться в тему, каждая парадигма программирования будет содержать в себе некие особенности в конкретной реализации. Например, в функциональном в C++ есть указатель на функцию, хотя это в общем-то не новость, и два плюса относятся скорее к двум последним парадигмам, а не к двум первым.
Что касается параллельного программирования, то здесь дело в другом.
Одним из наиболее распространенных способов классификации ЭВМ является систематика Флинна (Flynn), в рамках которой основное внимание при анализе архитектуры вычислительных систем уделяется способам взаимодействия последовательностей (потоков) выполняемых команд и обрабатываемых данных. При таком подходе различают следующие основные типы систем (см. [2, 31, 59]):
SISD (Single Instruction, Single Data) – системы, в которых существует одиночный поток команд и одиночный поток данных. К такому типу можно отнести обычные последовательные ЭВМ;
SIMD (Single Instruction, Multiple Data) – системы c одиночным потоком команд и множественным потоком данных. Подобный класс составляют многопроцессорные вычислительные системы, в которых в каждый момент времени может выполняться одна и та же команда для обработки нескольких информационных элементов; такой архитектурой обладают, например, многопроцессорные системы с единым устройством управления. Этот подход широко использовался в предшествующие годы (системы ILLIAC IV или CM-1 компании Thinking Machines), в последнее время его применение ограничено, в основном, созданием специализированных систем;
MISD (Multiple Instruction, Single Data) – системы, в которых существует множественный поток команд и одиночный поток данных. Относительно этого типа систем нет единого мнения: ряд специалистов считает, что примеров конкретных ЭВМ, соответствующих данному типу вычислительных систем, не существует и введение подобного класса предпринимается для полноты классификации; другие же относят к данному типу, например, систолические вычислительные системы (см. [51, 52]) или системы с конвейерной обработкой данных;
MIMD (Multiple Instruction, Multiple Data) – системы c множественным потоком команд и множественным потоком данных. К подобному классу относится большинство параллельных многопроцессорных вычислительных систем.
rfq>Я могу привести лишь один пример — системы контроля версий (SVN, CVS, Git и т.п.). Используемые а них структуры данных — change set'ы, иммутабельные состояния рабочих пространств — вполне себе функциональны.
А это и вовсе наталкивает на мысль, что речь не о парадигме, а о методологии программирования Feature driven development.
Feature driven development (FDD, разработка, управляемая функциональностью) — итеративная методология разработки программного обеспечения, одна из гибких методологий разработки (agile). FDD представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. Основной целью данной методологии является разработка реального, работающего программного обеспечения систематически, в поставленные сроки.
Дело в том, что слово feature применительно к программированию я перевожу как функционал, хотя на самом деле дословный перевод иной. И понятное дело данное понятие не будет иметь никакого отношения к функциональному программированию. Как-то тоже задумывался над этим вопросом Модифицируемость кода (Changeability QA) и Отсечение целей (сложность разработки).
rfq>Итак, начинаем марафон по замене процедурного программирования функциональным в области программирование-в-большом. Собираем уже работающие ростки и проблемы процедурного программирования, от которых можно будет избавится.
Для начала надо всё же определиться с понятиями, может сишники и делают какую-то революцию переходя с процедурной парадигмы программирования на функциональную, но на том же C++ многие уже давно используют или ООП, или обобщённое (шаблоны C++).
rfq>Если кто захочет написать, что у меня ничего не выйдет — пусть пишет, будем учиться переубеждать скептиков.
Здравствуйте, rfq, Вы писали:
rfq>Итак, начинаем марафон по замене процедурного программирования функциональным в области программирование-в-большом. Собираем уже работающие ростки и проблемы процедурного программирования, от которых можно будет избавится.
Про Docker пан уже слышал? Тот самый функциональный подход применительно к развертыванию приложений.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, rfq, Вы писали:
rfq>>Итак, начинаем марафон по замене процедурного программирования функциональным в области программирование-в-большом. Собираем уже работающие ростки и проблемы процедурного программирования, от которых можно будет избавится.
M>Про Docker пан уже слышал? Тот самый функциональный подход применительно к развертыванию приложений.
Слышал, но не вникал. Действительно это "Тот самый функциональный подход"?
Здравствуйте, Sinix, Вы писали:
M>>Про Docker пан уже слышал? Тот самый функциональный подход применительно к развертыванию приложений. S>+1. Даже аргументация та же.
Как-то бредово написано, и почему бы просто не использовать аппаратную виртуализацию c KVM.
— Нет, смотри в сторону микросервисов. Это будущее. Это то, как мы все вокруг теперь работаем. Ты берешь свое супер-пупер приложение и разделяешь на 12 сервисов. По одному для каждой задачи.
А вот с этим не согласен, деление ресурсов компьютера делает дешевле один контейнер, но объединение потом всего этого вместе лишает этого преимущества, зато создаёт ненужные проблемы.
— Что ж, ты же собираешься поднять 12 сервисов, и конечно же тебе понадобиться пара лишних копий для каждого, пара балансировщиков, etcd, твоя база данных и Kubernetes cluster. Так что, это может быть около 50-ти одновременно работающих контейнеров.
И ничего у них с балансировщиками толком не получится, каналы связи плюс ко всему ещё и станут узким местом рапределённого приложения. С другой стороны можно над этим ещё раз подумать. Плохо, что в данном случае всё предлагается сделать пользователю этих систем. Хотя в принципе наводит на кое какие мысли.
Здравствуйте, velkin, Вы писали:
V>Как-то бредово написано, и почему бы просто не использовать аппаратную виртуализацию c KVM.
Проблема в том, что оригинал поста был сделан как вирусная реклама CircleCI, ну, т.е. лёгкая шутка и "а вот как надо" в конце. Но автор слишком точно попал в яблочко и замысел немного не удался; пришлось писать отдельный пост про "вообще-то мы пошутили"
Вот и у топикстартера точь-в-точь та же проблема aka hype-driven development. ФП наше всё? Ок, значит и CI-системы, и базы данных и даже git теперь будет ФП. Кто не согласен — тем хуже для них.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, velkin, Вы писали:
V>>Как-то бредово написано, и почему бы просто не использовать аппаратную виртуализацию c KVM. S>Проблема в том, что оригинал поста был сделан как вирусная реклама CircleCI, ну, т.е. лёгкая шутка и "а вот как надо" в конце. Но автор слишком точно попал в яблочко и замысел немного не удался; пришлось писать отдельный пост про "вообще-то мы пошутили"
S>Вот и у топикстартера точь-в-точь та же проблема aka hype-driven development. ФП наше всё? Ок, значит и CI-системы, и базы данных и даже git теперь будет ФП. Кто не согласен — тем хуже для них.
Ну уж нет, я довольно критически отношусь к фанатам ФП. Например, написание простых параллельных процессов нет смысла писать на ФЯ (я так думаю). И уж тем более не стоит писать на ФЯ операционную систем. Но у функциональщины есть одно очевидное преимущество — она ближе к математике и легче доказывать корректность программ. И даже не столько математически строго доказывать, сколько убедительно демонстрировать.
Мысль о функциональном программировании-в-большом внедрилась ко мне можно сказать, насильно. Я ей неосознанно сопротивлялся десятки лет. Если бы у меня хватило ума закончить приличный университет в положеном возрасте, эта мысль пришла бы раньше и мир вокруг был бы совсем другим (да, это троллинг).
Здравствуйте, Sinix, Вы писали:
S>Вот и у топикстартера точь-в-точь та же проблема aka hype-driven development. ФП наше всё? Ок, значит и CI-системы, и базы данных и даже git теперь будет ФП. Кто не согласен — тем хуже для них.
Плачу 3 евро за контейнер OpenVZ уже лет пять, причём сейчас в связи с очередным падением рубля это дороже, но всё равно копейки. У меня там Jenkins (система непрерывной интеграции), а так же ChiliProject (форк Redmine), Gitolite и так далее. И никаких лимитов на количество разработчиков кроме аппаратных.
В целом суть такая: от $14 в месяц за каждого разработчика (читай – аккаунт на Github) за самый простой план без параллельных тестов и с суппортом по емейлу. Более дорогие планы отличаются количеством параллельных тестов и уровнем суппорта (забавно, видимо я успел еще отхватить план за $14, а потом он стал стоить $18, результат чего вы можете наблюдать на скриншоте).
Так то отличный план по зарабатыванию денег, брать с каждого пользователя по несколько десятков долларов, а не с нескольких сотен по несколько долларов. Разница в заработке в 3 порядка, то есть более чем 1000 раз. Между прочим:
rfq>Я могу привести лишь один пример — системы контроля версий (SVN, CVS, Git и т.п.).
Как-то уж очень легко приравняли:
1. CVS — первое поколение систем контроля версий
2. SVN — второе поколение систем контроля версий
и
3. Git — третье поколение систем контроля версий
Получается радикальные различия разных поколений для автора топика не играют никакой роли.
CVS был создан для того, чтобы иметь возможность работы с двумя моими студентами над C компилятором ACK (Amsterdam Compiler Kit). У нас троих был почти несовместимый по времени график (один студент имел постоянное место работы, второй появлялся нерегулярно, а я мог работать над проектом только по вечерам). Их проект длился с июля 1984 по август 1985. CVS изначально назывался cmt, по причине того, что он позволил нам фиксировать версии независимо (от английского commit — фиксировать, совершать).
Здравствуйте, velkin, Вы писали:
rfq>>Я могу привести лишь один пример — системы контроля версий (SVN, CVS, Git и т.п.).
V>Как-то уж очень легко приравняли: V>1. CVS — первое поколение систем контроля версий V>2. SVN — второе поколение систем контроля версий V>и V>3. Git — третье поколение систем контроля версий
V>Получается радикальные различия разных поколений для автора топика не играют никакой роли.
Именно так, для меня различия не радикальные, а чисто технические. Если взять самый современный калькулятор и сравнивать с компьютером, то 50-летняя БЭСМ-4 будет также превосходить калькулятор идейно, как современейший Мак.
Я призываю пересесть с калькуляторов на компьютеры, образно говоря.
Здравствуйте, rfq, Вы писали:
rfq>Именно так, для меня различия не радикальные, а чисто технические. Если взять самый современный калькулятор и сравнивать с компьютером, то 50-летняя БЭСМ-4 будет также превосходить калькулятор идейно, как современейший Мак.
а ты с этими бэсм работал? это были именно большие калькуляторы — никакой защиты паимяти, многозхадачности, просто пульт с лампочками и всё такое
