Ответ на »сообщение 1988« (Илья Ермаков)
___________________________

p>> Если предположить, что человек всегда писал на обероне и не слышал что такое "конструктор", то пройдет очень много времени, прежде чем он сам придет к этому понятию и будет "эмулировать" его на обероне.

ИЕ>> Ну, конструкторы-то к чему помянуты... Никто их не эмулирует, кому они нужны... Объект не может инициализаировать сам себя, объект всегда кем-то порождается, конкретным истоичником-фабрикой - просто и логично.

В принципе это всё одни и те же яйца, только смотрите вы на них с разных боков...

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

ЗЫ. Рассуждения о понижении уровня абстракции и повышения эффективности программ логично приводят нас к идее программирования в машинных кодах или ассемблере. Вот только эффективность программистов при этом сильно страдает... Так же сильно, как и при переходе от высокоуровневых ФЯ к низкоуровневому Оберону...

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

Согласен. Вместо Map там нужно sequence:

Сказывается Ваша привычка к Лиспу с его гетерогенными списками...

readFile "/tmp/x" и writeFile "/tmp/y" возвращают значения совершенно разных типов, а значит их нельзя поместить в один список в Хаскелле... :о(

ERROR file:test.lhs:72 - Type error in list
*** Expression    : [readFile "/tmp/x",writeFile "/tmp/y"]
*** Term          : writeFile "/tmp/y"
*** Type          : String -> IO ()
*** Does not match : IO String

Ответ на »сообщение 1988« (Илья Ермаков)
___________________________
Объект не может инициализаировать сам себя, объект всегда кем-то порождается, конкретным истоичником-фабрикой - просто и логично.
Илья, вы опять выдаете желаемое за действительное :))
В обероне можно ЗАПРОСТО создать обьект в обход всяких фабрик. Вы уповаете на "грамотное обучение", а заявляете о каком то механизме (которого на самом деле не существует) который де НЕ ДАСТ программистам этого делать. Нет такого механизма в обероне.
Вот в хаскеле есть механизм запрещающий присваивания. И тут никто на "грамотное обучение" не уповает.
А в обероне - нет.
Оберон без ваших лекций о том "как надо" - это самый обычный vb, паскаль, java только в крапинку. :))

Ответ на »сообщение 1986« (Geniepro)
___________________________
Согласен. Вместо Map там нужно sequence:

sequence_ $ reverse [readFile "/tmp/x", writeFile "/tmp/y"]

Ответ на »сообщение 1983« (pepper)
___________________________

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

Ну, конструкторы-то к чему помянуты... Никто их не эмулирует, кому они нужны... Объект не может инициализаировать сам себя, объект всегда кем-то порождается, конкретным истоичником-фабрикой - просто и логично. Так же, как ток в цепи не может самозародиться из ниоткуда, так же противоестественны конструкторы.
Если начинать учить с Оберона, то все просто и ясно у студентов в голове укладывается. Начинать учить с "вывертов" мейнстрима - это гнать бедняг из Москвы в Питер через южный полюс...
Вот тогда действительно - чтобы понять, как можно жить без конструкторов, придется сначала понюхать очень много других языков, покушать кактусов, вытащить колючки из языка, отбросить все нажитые привычки, вернуться на уровень сознания новичка - и с tabula rasa начать все по новой.

Ответ на »сообщение 1984« (Илья Ермаков)
___________________________
Абстрагирование - это хорошо. Но в каждом конкретном случае надо знать меру.
Какую меру Илья ? Меру знает тот кто пробовал.
Меру знают практически все функциональщики, поскольку нет на сегодняшний день чистых функциональщиков, все проходили императивную школу, и у всех за плечами большой опыт работы с ИЯ.
Вот они знают меру, они видели обе стороны медали, да не только видели а и на зуб пробовали.
Как вы можете знать меру ? Как вы можете мерить ФП и делать какие то странные утверждения о типах в хаскеле (на ветке оберона) если вы этот хаскель в глаза не видели ?

Хотите знать меру - изучите хаскель, напишите на нем ну хотя бы одну программу, ну хотя бы в пару сотен строчек.
А то пока вы только гадате как оно там будет.


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


Ага, а для того чтобы ваш чертежник мог чертить, лесоруб дерево срубил, и столяр чертежный стол сделал.
Будем делать выводы что чертежник это на самом деле скрытый лесоруб ?
Нет конечно. Не будем делать никаких выводов. Пусть те кому надо рантаймы писать работают хош на сях хош на ассемблере, хош на обероне. А мы будем работать на эрлангах, лиспах и хаскелях :))

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

mapM_ [readFile "/tmp/x", writeFile "/tmp/y"]

Боюсь, этот код не может работать - в списке значения разных типов... :о(

А  собственно, что имелось в виду этим кодом? Если копирование одного файла в другой, то лучше так:

readFile "tmp\\x" >>= writeFile "tmp\\y"

А map над действиями - например вот эта простая функция, которая распечатывает список так, что каждый элемент печатается на новой строке. Часто бывает полезно:

printList :: Show a => [a] -> IO ()
printList = (foldr (>>) (return ())) . (map print)

Здесь (map print) как раз и применяет процедуры вывода на печать с переводом строки к элементам какого-то списка, получая список действий вывода на печать, которые затем собираются в единое действие функцией (foldr (>>) (return ()))
Вместо print можно подставить другую функцию печати, в том числе на разные устройства... Или вообще не печати, а вывода в порт или файл...

Ответ на »сообщение 1983« (pepper)
___________________________

Ответ на »сообщение 1981« (Илья Ермаков)
___________________________
Я не жалею. Я хотел сказать, что если сравнить полученные решения, то решение на ФП окажется проще. Особенно если пытаться решать эту задачу на обероне "размашисто функционально", а не родными для оберона средствами. И уж конечно только оберонщикам придет в голову дотачивать компилятор (псевдомуодули, AST и т.д.) под конкретную задачу.

Ээээ, какие еще псевдомодули и доточка компилятора?
Я имел в виду генерацию модуля и динамическую подгрузку в работающую систему.
Сейчас в ББ, правда, приходится генерировать текстовый исходник.
Хотелось бы доработать до уровня интерфейсов .NET, которые позовляют динамически генерировать сборки в памяти. Рантайм ББ позволяет уже сейчас, нужен хороший "нетекстовый вход" к компилятору.

Ответ на »сообщение 1982« (Jack Of Shadows)
___________________________
Вообще, всю картину споров ФП-ИП в этих ветках я сейчас вижу так...
Вот, к примеру... Есть математик, большой специалист по дифференциальным уравнениям, каким-нибудь краевым задачам и т.п. Разработал уйму методов, которые применяются для строительства, ну, самолетов, например...
Приезжает этот товарищ в КБ, где его результаты применяются, и в ужасе хватается за голову: "Вы чего делаете? Вы как работаете? Это же каменный век! Какие-то чертежи изобрели... Какие-то материалы... АБСТРАГИРОВАТЬСЯ надо, чукчи забайкальские! Вот, вместо чертежа запишем функциональное описание поверхности! Смотрите, как коротко! Несколько строчек вместо вашего формата A1. И от материала, из которого профили будут изготавливаться, тоже надо абстрагироваться! Кто кому служит - материал вам, или вы материалу?"
Вот так примерно и выглядят огульные нападки на ИП и большинство тезисов, которые ставили целью доказать, что "в ФП абсолютно всо всем лучше и современнее".

Уже приводился пример, что для того, чтобы великолепный и красивый Эрланг работал, под ним должно крутится N мегабайт исходного кода на императивном языке. Автоматическое распараллеливание? Превосходно. Но для этого внизу должен крутиться рантайм, в котором распарраллеливание проработано строго детерминированно, ручками. Абстрагирование - это хорошо. Но в каждом конкретном случае надо знать меру.
ФП, очевидно, будет развиваться - у него много ниш, которые можно занять с успехом. И все эти ниши можно заполнить, вытеснив другие парадигмы. Однако есть ниши, в которые попробуют-попробуют сунуться, да и окажется, что смысла нет...
А у паскалевских и околопаскалевских языков (Обероны, Ada, Zonnon, даже Eiffel я бы сюда отнес) будущее крепкое. Потому что по сравнению с сегодняшним мейнстримом, а уж недавным огульно-сишным тем более, абстракции в них превосходные. Но при этом в них, по-видимому, имеем предельный уровень абстракций, реализуемый на сегодняшних физических машинах в терминах самого себя. Т.е. допускающий раскрутку с нуля и полный отказ от ассемблеров и прочей низкоуровщины. "Раскрутить" с нуля рантайм и ОС на функциональном языке - гораздо, на порядок, более сложная задача - и эффективность того, что получится в итоге, ой как сомнительна....

Ответ на »сообщение 1981« (Илья Ермаков)
___________________________

Не жизнь - а малина, так что не надо нас, убогих оберонщиков, жалеть :-)


Я не жалею. Я хотел сказать, что если сравнить полученные решения, то решение на ФП окажется проще. Особенно если пытаться решать эту задачу на обероне "размашисто функционально", а не родными для оберона средствами. И уж конечно только оберонщикам придет в голову дотачивать компилятор (псевдомуодули, AST и т.д.) под конкретную задачу.


Есть хороший инструмент, хороший язык, стимулирующий хороший стиль мышления


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


Давайте жить дружно, ребята! :-)


Я не хотел ни на кого "наезжать". Признаюсь, повелся на провокацию товарища info21 с его "размашистым функциональным стилем" на обероне.