Ответ на »сообщение 5263« (Lisp Hobbyist)
___________________________

Насколько мне известно, ОС для K machine, их последней разработки, была почти полностью написана на Лиспе, включая сборщик мусора. На ассемблере пришлось писать лишь небольшие фрагменты типа входа/выхода в прерывание и начальной инициализации железа.

Подумалось ещё вот о чём: нередко для самоутверждения языка (точнее, его авторов, его сторонников) пытаются весь мир вокруг переделать на один лад -- в терминах этого языка (речь не только и не столько о Лиспе). Написать транслятор с него обязательно на нём же самом, и систему программирования, и ОС. Если сделана какая-то прикладная система, то обязательно хочется подчеркнуть, что именно на этом языке, не на каком-то там ещё...

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

Мне представляется, что такое стремление к самодостаточности, к автономному плаванию в бушующем море современного программного мира, вызвано "прыжками и ужимками" рынка. Люди хотят не только добиться самоутверждения любимого языка, но и защититься от чихов ведущих компаний, от тлетворного влияния власть предержащих в мировой ИТ-империи. Цель которых -- контроль завоёванных долей рынка и их расширение, а не попытки найти истину или достичь технологического совершенства.

Стоит иногда подумать и о целесообразности применения того или иного языка для тех или иных задач. И не ограничиваться рамками одного самого любимого или самого навороченного.

Ответ на »сообщение 5263« (Lisp Hobbyist)
___________________________

То-то удивились бы бывшие работники Lisp Machines, Inc., если бы прочли это заявление... Насколько мне известно, ОС для K machine, их последней разработки, была почти полностью написана на Лиспе, включая сборщик мусора. На ассемблере пришлось писать лишь небольшие фрагменты типа входа/выхода в прерывание и начальной инициализации железа. Точный объем этих фрагментов не назову, но думаю, что там было в сумме не более пары сотен команд.

Сколько людей -- столько и мнений. Тем более, в такой нечёткой сфере, как программирование.

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

Ответ на »сообщение 5261« (Trurl)
___________________________
Ну почему же передергиваю ? Поскольку основным (единственным ?) предназначением анонимных функций является декларация по месту использования, то ясно что при реализации упор будет делаться на краткую форму.
Ведь смысл анонимных функций именно в упрощении записи.
Чего о декларации обычных функций в языках алгол семесйтва сказать ну никак нельзя.
Стало быть никто не будет заморачиваться с begin end и return для анонимных функций, что кстати и подтверждается практикой. Смотрите лисп и хаскель.

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

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

Так что придется мне таки переписать приведенный мною пример:

// Сначала нам придется описать тип функции которую мы будем передвать как параметр. Без этого никак.
type MyFunc = Function( x:Integer, y:Integer):Integer;

// Сама передаваемая функция
Function MyFunc(x:Integer, y:Integer):Integer
begin
  return x + y
end

var
\\ Да да мы должны еще и описать переменную типа этой функции. А вы думали уже все ? :))
  mf : MyFunc;

\\ И вот наконец то долгожданная передача:
ProcessListOfPairs(myList, mf)

Ну и сравниваем с кодом из хаскеля:

ProcessListOfPairs myList \x y -> x + y

Приведенный пример из дельфи конечно. Если кто то покажет как это коротко, просто и изящно делается на обероне, буду премного благодарен :))

Ответ на »сообщение 5231« (Руслан Богатырев)
___________________________

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


То-то удивились бы бывшие работники Lisp Machines, Inc., если бы прочли это заявление... Насколько мне известно, ОС для K machine, их последней разработки, была почти полностью написана на Лиспе, включая сборщик мусора. На ассемблере пришлось писать лишь небольшие фрагменты типа входа/выхода в прерывание и начальной инициализации железа. Точный объем этих фрагментов не назову, но думаю, что там было в сумме не более пары сотен команд.

Ответ на »сообщение 5252« (Jack Of Shadows)
___________________________

Ответ на »сообщение 5250« (Руслан Богатырев)
Нет не перестанет. И именно поэтому у вас ни черта не получится с асинхронным ООП :)) Гарантий то нет.
Если только вы не запретите присваивание конечно. Однако в этом случае вы получите... Erlang :))

Дались Вам присваивания :-) Суть не в них, а в модели память, которая лежит под языком.
Если исключить глобальную память (в частности, кучу в том виде, как она есть, задействовав вместо неё другие модели) - то никаких препятсвий к распараллеливанию (даже автоматическому) просто нет. Для того же Оберона изменений может быть минимум.
Вы никак не хотите признать, что импператив и функционал - это две дуальные формы для одного и того же. И никакой связи с возможностью распараллеливания непосредственно не имеют. Просто ФП, честь ему и хвала, раньше вышло на избавление от глобальной памяти (между прочим, это не синоним глобального состояния - состояния для распараллеливания могут и присутствовать, только в высокоуровнево управляемом виде. В любом случае, для системы, взаимодействующей с реальным миром, дискретные состояния есть неотъемлемая данность).
Вы же всех призываете вывёртывать мозги, пытаясь выражась конкретным (и весьма навороченным) мат. аппаратом, который лежит в основе того же Хаскелла, те явления, которые могут быть им плохо выражаемы.

Ответ на »сообщение 5232« (Jack Of Shadows)
___________________________

Сравните:

function MyFunc(x, y)
begin
  return x + y
end

ProcessListOfPairs(myList, MyFunc)

и

ProcessListOfPairs(myList, (x,y) -> x + y)


Передергиваем ;-). Сравните:

function MyFunc(x, y)= x + y;
ProcessListOfPairs(myList, MyFunc)

и

ProcessListOfPairs(myList, (function (x, y) = begin return x + y end)

Ответ на »сообщение 5256« (Руслан Богатырев)
___________________________
Идеи есть, и лежат они в сфере асинхрона.
Понятно. Удачи, и скорейшего осознания конечной точки... то есть Ерланга :)))
А если серьезно, Руслан, то как только вы вполную засядете за решение проблемы, то вы придете к тем же самым выводам, к которым пришли инженеры Эрланга. Пока не запретить присваиваний, гарантировать надежную асинхронную работу невозможно.
Ну а пока вы к этому выводу не пришли. Обьясните мне в чем заключается ваша идея "асинхроннго ООП"

Ответ на »сообщение 5257« (Руслан Богатырев)
___________________________
ФП так и будет буксовать... :)
Wow, wow, wow, hold your horses. :))
Даже короткое знакомство с положением дел в хаскеле и обероне дает однозначный ответ кто вдижется вперед и кто буксует :))

Ответ на »сообщение 5255« (Руслан Богатырев)
___________________________
Руслан, все очень просто на самом деле :))
Императивность это изменение состояния. ВЕЗДЕ! в паскале, в хаскеле, в SQL
Изменение состояния ТРЕБУЕТ заданной и жестко следуемой последовательности. ВЕЗДЕ! в паскале, в хаскеле, в SQL.
И тем не менее императивные островки, то есть места в которых 1. состояние изменяется; 2. последовательность важна, не делают sql или хаскель имепративными языками. Почему ? Потому что эта часть является всего лишь интерфейсной к внешнему миру, а не определяющей как в императвных языках. Потому что в этой части в паскале и в SQL не совершается ВООБЩЕ никакая работа. Вся работа в хаскеле и в sql совершается в ее декларативной/функциональной части. То есть у SQL это описание (декларация) то ЧТО надо сделать, какие данные, какая выборка. В хаскеле это цепочки функций, преобразовывающие данные.
Вот тут и совершается основная работа. Вот тут и не важна последовательность. А вот после того как работа соврешена, запись результата - да, эта часть императивна, эта часть требует следования последовательности.

Это в отличии от императивных языков в которых требование определенной последовательности истинно на всем протяжении программы. а не только в местах ввода\вывода.

А это сильно усложняет работу программисту. Ведь каждое дополнительное требование - это усложнение задачи.

Ответ на »сообщение 5254« (Jack Of Shadows)
___________________________

Но вот опять ветку по оберону захватили функциональщики :))

Боюсь, пока в ФП не придут оберонщики с самыми серьезными намерениями, ФП так и будет буксовать... :)