Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 5266 27-09-2007 04:27 | |
Ответ на »сообщение 5263« (Lisp Hobbyist)
___________________________
Насколько мне известно, ОС для K machine, их последней разработки, была почти полностью написана на Лиспе, включая сборщик мусора. На ассемблере пришлось писать лишь небольшие фрагменты типа входа/выхода в прерывание и начальной инициализации железа.
Подумалось ещё вот о чём: нередко для самоутверждения языка (точнее, его авторов, его сторонников) пытаются весь мир вокруг переделать на один лад -- в терминах этого языка (речь не только и не столько о Лиспе). Написать транслятор с него обязательно на нём же самом, и систему программирования, и ОС. Если сделана какая-то прикладная система, то обязательно хочется подчеркнуть, что именно на этом языке, не на каком-то там ещё...
Думается, это вопрос зрелости. Комплекс неполноценности постепенно должен проходить. Нет надобности доказывать осуществимость практически. Она видна и теоретически. Из одного лишь описания языка.
Мне представляется, что такое стремление к самодостаточности, к автономному плаванию в бушующем море современного программного мира, вызвано "прыжками и ужимками" рынка. Люди хотят не только добиться самоутверждения любимого языка, но и защититься от чихов ведущих компаний, от тлетворного влияния власть предержащих в мировой ИТ-империи. Цель которых -- контроль завоёванных долей рынка и их расширение, а не попытки найти истину или достичь технологического совершенства.
Стоит иногда подумать и о целесообразности применения того или иного языка для тех или иных задач. И не ограничиваться рамками одного самого любимого или самого навороченного.
№ 5265 27-09-2007 04:09 | |
Ответ на »сообщение 5263« (Lisp Hobbyist)
___________________________
То-то удивились бы бывшие работники Lisp Machines, Inc., если бы прочли это заявление... Насколько мне известно, ОС для K machine, их последней разработки, была почти полностью написана на Лиспе, включая сборщик мусора. На ассемблере пришлось писать лишь небольшие фрагменты типа входа/выхода в прерывание и начальной инициализации железа. Точный объем этих фрагментов не назову, но думаю, что там было в сумме не более пары сотен команд.
Сколько людей -- столько и мнений. Тем более, в такой нечёткой сфере, как программирование.
Если стоит, скажем, задача разделить яблоко на две половинки, можно попробовать его просто с силой разломить. Правда, будут, скорее всего, неровные части. Можно воспользоваться садовыми ножницами и даже электропилой. Но думаю, перочинный нож подойдет для такой задачи лучше. А вот сажать яблони с помощью перочинного ножа, наверное, не стоит.
№ 5264 27-09-2007 03:42 | |
Ответ на »сообщение 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
Приведенный пример из дельфи конечно. Если кто то покажет как это коротко, просто и изящно делается на обероне, буду премного благодарен :))
№ 5263 27-09-2007 03:32 | |
Ответ на »сообщение 5231« (Руслан Богатырев)
___________________________
Думаю, речь должна идти не о минимализме, а о сбалансированности, гармоничности языка, построенного на принципах концептуальной экономии. Лисп, например, построен на этих принципах, но он не позволяет получать прозрачный доступ к традиционной архитектуре Эккерта-Неймана. Тыкать в битики пальцем.
То-то удивились бы бывшие работники Lisp Machines, Inc., если бы прочли это заявление... Насколько мне известно, ОС для K machine, их последней разработки, была почти полностью написана на Лиспе, включая сборщик мусора. На ассемблере пришлось писать лишь небольшие фрагменты типа входа/выхода в прерывание и начальной инициализации железа. Точный объем этих фрагментов не назову, но думаю, что там было в сумме не более пары сотен команд.
№ 5262 27-09-2007 03:23 | |
Ответ на »сообщение 5252« (Jack Of Shadows)
___________________________
Ответ на »сообщение 5250« (Руслан Богатырев)
Нет не перестанет. И именно поэтому у вас ни черта не получится с асинхронным ООП :)) Гарантий то нет.
Если только вы не запретите присваивание конечно. Однако в этом случае вы получите... Erlang :))
Дались Вам присваивания :-) Суть не в них, а в модели память, которая лежит под языком.
Если исключить глобальную память (в частности, кучу в том виде, как она есть, задействовав вместо неё другие модели) - то никаких препятсвий к распараллеливанию (даже автоматическому) просто нет. Для того же Оберона изменений может быть минимум.
Вы никак не хотите признать, что импператив и функционал - это две дуальные формы для одного и того же. И никакой связи с возможностью распараллеливания непосредственно не имеют. Просто ФП, честь ему и хвала, раньше вышло на избавление от глобальной памяти (между прочим, это не синоним глобального состояния - состояния для распараллеливания могут и присутствовать, только в высокоуровнево управляемом виде. В любом случае, для системы, взаимодействующей с реальным миром, дискретные состояния есть неотъемлемая данность).
Вы же всех призываете вывёртывать мозги, пытаясь выражась конкретным (и весьма навороченным) мат. аппаратом, который лежит в основе того же Хаскелла, те явления, которые могут быть им плохо выражаемы.
№ 5261 27-09-2007 01:11 | |
Ответ на »сообщение 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)
№ 5260 26-09-2007 19:06 | |
Ответ на »сообщение 5256« (Руслан Богатырев)
___________________________
Идеи есть, и лежат они в сфере асинхрона.
Понятно. Удачи, и скорейшего осознания конечной точки... то есть Ерланга :)))
А если серьезно, Руслан, то как только вы вполную засядете за решение проблемы, то вы придете к тем же самым выводам, к которым пришли инженеры Эрланга. Пока не запретить присваиваний, гарантировать надежную асинхронную работу невозможно.
Ну а пока вы к этому выводу не пришли. Обьясните мне в чем заключается ваша идея "асинхроннго ООП"
№ 5259 26-09-2007 19:02 | |
Ответ на »сообщение 5257« (Руслан Богатырев)
___________________________
ФП так и будет буксовать... :)
Wow, wow, wow, hold your horses. :))
Даже короткое знакомство с положением дел в хаскеле и обероне дает однозначный ответ кто вдижется вперед и кто буксует :))
№ 5258 26-09-2007 19:00 | |
Ответ на »сообщение 5255« (Руслан Богатырев)
___________________________
Руслан, все очень просто на самом деле :))
Императивность это изменение состояния. ВЕЗДЕ! в паскале, в хаскеле, в SQL
Изменение состояния ТРЕБУЕТ заданной и жестко следуемой последовательности. ВЕЗДЕ! в паскале, в хаскеле, в SQL.
И тем не менее императивные островки, то есть места в которых 1. состояние изменяется; 2. последовательность важна, не делают sql или хаскель имепративными языками. Почему ? Потому что эта часть является всего лишь интерфейсной к внешнему миру, а не определяющей как в императвных языках. Потому что в этой части в паскале и в SQL не совершается ВООБЩЕ никакая работа. Вся работа в хаскеле и в sql совершается в ее декларативной/функциональной части. То есть у SQL это описание (декларация) то ЧТО надо сделать, какие данные, какая выборка. В хаскеле это цепочки функций, преобразовывающие данные.
Вот тут и совершается основная работа. Вот тут и не важна последовательность. А вот после того как работа соврешена, запись результата - да, эта часть императивна, эта часть требует следования последовательности.
Это в отличии от императивных языков в которых требование определенной последовательности истинно на всем протяжении программы. а не только в местах ввода\вывода.
А это сильно усложняет работу программисту. Ведь каждое дополнительное требование - это усложнение задачи.
№ 5257 26-09-2007 18:52 | |
Ответ на »сообщение 5254« (Jack Of Shadows)
___________________________
Но вот опять ветку по оберону захватили функциональщики :))
Боюсь, пока в ФП не придут оберонщики с самыми серьезными намерениями, ФП так и будет буксовать... :)
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|