Observations

Some blanket statement about all "non-functional programming"? I thought using global variables is a matter of style.

From:

It's a matter of helplessness.

From:

Right, but what forces programmer to use global variables? Non-functional programming? Yet I admit there are native singletons in the system, no matter how hard we try.

From:

Lack of understanding the essence of things, I believe.

From:

I would appreciate it if you could come up with your own opinions regarding why it is happening. You are in c world, so I'm just curious.

From:

The worst example of global and static variable type of objects abuse was a small hardware start-up in *some northern country*. At the beginning, I thought how bad that was until realized - their DSP "computer" and Real Time OS architecture had neither sufficient stack nor dynamic memory allocation. So their proprietary C compiler lacked many standard language features, like malloc/free. But they did have some random access memory anyway. And the same people were making relatively good C++ code for their own debug tools for the normal PC that watches DSP connected to it, with the guideline to avoid both stateful global and static variables if possible.

After I left that company I heard they abandoned their DSP started using normal ARM processor (closed to the one in modern gadgets). Their capital is the intellectual property, the code developed for DSP which is now the base for the product with normal computing architecture. I lately asked the man who still works there if they refactored the code so it is not as ridden with stateful variables. The guy stared at me ad asked "Why? It works well".

So, I guess, global variables are just a historical burden in the code, mostly. And nothing prevents not to use them now in C/C++ though, if we know that that program code operates with precisely ONE instance in the system, it gives a chance to implement the singleton with all precautions for concurrent use. Otherwise... m... you need to somehow maintain the logic state correctly?

Edited Date: 2014-05-05 02:18 am (UTC)

From:

практически в любом бытовом раутере стоит чип похожий на интеловский ixp, а то и сам ixp - там функциональное программирование реализовано на уровне железа, network cores кидают друг другу кусочки данных и что с ними нужно сделать, когда всё сделано, данные летят в data link. грубо говоря. без всяких "функциональных" языков. переменные там вообще завести нельзя, памяти в привычном программистам "языком Си" нет, только параметры и названия функций по шине летают из кора в кор.

From:

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

From:

А вот State Machine на Scala?

From:

в принципе можно, но зачем? вся грязь типа mutable state в функциональных языках делегирована "платформе", в которой все нужные стейт машины реализованы под ключ. в языках основанных на ML, вроде скалы, главная стейт машина в платформе - матчер паттернов, заменяющий очень кудрявый branching в более обычных языках одной-двумя дивно выглядящими строчками прокидывающими сматченное в простые функции.

From:

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

From:

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

From:

и тут меня осенило - когда c++ peoples говорит про "стейт машину" он имеет в виду что угодно кроме собственно "конченого автомата" как средства решения той или иной проблемы, а думает исключительно про хренову жменю классов, интерфейсов, енамов и прочей параферналии которая потенциально реализует переходы между значениями хранящейся в замудрённом классе переменной означающей "state". функциональные языки обычно во всей этой _._бени не нуждаются, прямо в грамматике языка есть всё что нужно для состряпывания беготни по состояниям с вызовами функций в промежутках. плюс, из-за традиционного отсутствия непредсказуемой переменчивости данных, достижимость конечного состояния доказать проще чем для перемешанных как попало в "объектно-ориентированных" языках кода и данных. например, при помощи темпоральной логики.

From:

Собственно конечный автомат имелся в виду. Вот робот, который потенциально может выполнить много разных инструкций (таки заранее известных), но переход к следующей инструкции зависим от контекста, в который робот был заведён предыдущими инструкциями. То есть, нужно как-то иметь persistent state.

From:

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

From:

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

From:

Можно начать с вопроса, является ли лямбда-исчисление полным по Тьюрингу.

From:

Я это не очень понимаю. Вопрос был ремесленнический.

From:

Так я не вижу проблемы - чисто формально state machine - это функция Input -> State -> State; ты хочешь поднять эту функцию на List[Input] -> State -> State, и, может быть, поменять порядок параметров и получить State -> List[Input] -> State - и? Где проблемы? В имплементации? В книге Beautiful Code первая глава как раз посвящена тому, как, зная, что у нас речь о морфизме двух моноидов (там этих слов нет) иы можем лихо сократить вычисления, в редакторе ли, в контроле ли версий, все равно.

From:

Ну дык, нет глобальных и статических переменных по определению? FP - это же просто высокоуровневые навороты, а под ними всё та же OS, всё те же потоки, банальная JVM. Или хранят стейт где-то не только в локальном контексте потока-функции, или нигде нет стейт, доступного другим блокам программы.

From:

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

From:

I wish I was... nope generalist. Поискал, вот http://doc.akka.io/docs/akka/snapshot/scala/fsm.html

Не очень внимательно пока читал, но показалось, что банальный цикл, и вуаля, имеем висящий в памяти синглтончик на Scala. :) Он отвечает на запросы. Всё как у людей.

From:

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

From:

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

From:

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

From:

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

From:

ну функциональное программирование ведь не вчера родилось, хасеклю вон четверть века уже, а лисп вообще всегда был. слово в литературе встречается лет тридцать. что одна школа озорной мысли называет "монадами", другая по-простому называет чем они есть - functional expression'ами. откольники ml'а кто в один лагерь попал, кто в другой более-менее поровну.

From:

Трахтман это впаривал году где-то в 86-м. На весь Питер про категорные монады слышали, наверное, двое - он да я.

From:

yatur.livejournal.com

I recently had to deal with the code where the same 9-10 string parameters were passed around, from function to function and from layer to layer. I created a simple Request data object out of them and voila: no more five miles long parameter lists!

If your function has too many parameters, you probably forgot to add some (c)

From: