DRAKON-Erlang, гибрид ужа с ежом

The ideas behind functional programming are simple, powerful and practically useful. But the presentation layer is of a very low quality

Весело у них там, я смотрю. Где они траву берут?

ДГМ в терминальной стадии - это не забавно.

Где они траву берут?

У еванлилистов дракона.

А зачем не говорили?

Advanced Branching with Switch

Банальный переключатель уже характеризуется как «Advanced Branching», и это при том, что в Erlang'е есть сопоставление с образцом.

ДГМ в терминальной стадии - это не забавно

Департамент гражданства и миграции?

Дракон головного мозга, же.

Самая мякотка:

Tail recursion is a trick. Some recursive algorithms must be implemented with tail recursion. Otherwise they get too slow. But tail recursion is not intuitive. It requires very intensive thinking to do it right and adds complexity to the original algorithm. Tail recursion is an evil remnant of ancient compilers. Hopefully, developments in compiler technology will take care of that.

Это феерично! Гениально!

Гм, все на tcl.

Надо чтобы дело делалось. А для большинства императивщиков хвостовая рекурсия не только rocket science, но и junior-level быдлокод. Учитывая ограниченость компиляторов если оптимизация не произойдет, то это и ест быдлокод.

Но да, написано в стиле Visual Basic for Dummies

на выходе фигня - ни то ни сё

Рекурсия вообще быдлокод в 99.9999% случаев. Любая.

Лол, толстяк.

Вот и быдлокодеры подтянулись. Если программистишко не умеет избавляться от рекурсии, то ему надо переквалифицироваться в дворники.

Пруф в студию. Или сам так считаешь?

Ом-ном-ном.

Учитывая ограниченость компиляторов если оптимизация не произойдет

@tailrec же решает эту проблему в scala, вроде. Что, больше такого нигде нет?

Ну все же много где нет. В C/C++ вообще разброд и шатания, CLR есть поддержка, но нет гарантий, в JVM вообще нет. И если везде на этих платформах городить хвостовую рекурсию, то будет больно. Тем более сто списки в этих ЯП например тоже не совсем дружелюбно

Зачем так жить.

в JVM вообще нет

в scala хвостовая рекурсия преобразуется в цикл на уровне компилятора в байт-код, я правильно понимаю?

Да. Все делает компилятор. А в JVM поддержки нет.

В CLR есть гарантия вообще-то.

Далеко не всякий хвостовой вызов можно «преобразовать в цикл». Например, хвостовой вызов виртуального метода.

В CLR есть гарантия вообще-то

Гарантия чего? C# не умеет хвостовую рекурсию вообще.

Причем тут шарп? CLR гарантирует, что вызов с префиксом .tail будет хвостовым.

Что не так со списками в .Net?

Он про CLR вообще, в F# есть хвостовая рекурсия и она работает (правда в F# 2.0 не было атрибута для гарантированной хвостовой рекурсии, что в 3.0 я не знаю).

Извиняюсь если чтото пропустил. Они иммутабельны и состоят из головы и хвоста явно в интерфейсе?

В C# - нет, там мутабельные списки (но никто не мешает тебе сделать через расширение типов свой интерфейс работы со стандартными списками через Head + Tail). В F# иммутабельные списки работающие через head + tail + имеется доступ к элементам по индексу. Плюс свободный каст, как минимум System.Collection.Generic.List<T> в list<T> F#(на счёт обратно не знаю, но никто не запрещает и из C# дёргать F#'овый список, сборку только нужную подключи и всё).

P.S. а вообще иммутабельность, в явном виде, не особо нужна для списков в C#. Там задачи на такую обработку решаются через Linq и PLinq (параллельный Linq).

ну в F# да, я оговорился. Я имел ввиду C#

Иногда все таки нужно не через функции высшего порядка

Зачем этот Дракон вообще нужен? Любая более-менее сложная программа в виде диаграммы будет занимать неприлично много места, и ее совершенно невозможно будет понять.

Это не так. Ребята из National Instruments с тобой не согласны, а лично у меня был живой пример человека, который написал на LabView, в одиночку, приложение для встраиваемой системы по тестированию каких-то там двигателей (стендовая фиговина, которая должна снимать с колёсных пар вагонов показатели по датчикам и обрабатывать всё это дело). Он мне эту программу показывал, там всё довольно легко можно понять было, т.к. каждая подпрограмма реализовывается либо как комбинационный элемент, либо как КДА, а потом уже отображается квадратиком со входами и выходами на более высокоуровневом участке схемы.

Nightmarez, ты?

Безумненько.

Вообще доля правды есть. Релаится на то, что компилятор заоптимайзит - это какое-то ковбойство. Мне нравится как сделано в Clojure - там специальная форма для этого - loop/recur, не ошибешся.

Релаится на то, что компилятор заоптимайзит - это какое-то ковбойство.

В современных функциональных языках гарантируется TCO. С другой стороны, в соврменном С++ расчитывают на оптимизации шаблонного кода более сложные чем TCO.

В Scheme, кстати, есть named let, как loop/recur в Clojure.