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

Как было сказано в "Алисе в Стране Чудес": Что бы удержаться на месте, нужно бежать вперёд изо всех сил! А иначе неизбежно отстанешь!

Уж коли затронули RSDN, вот товарищи, наиболее продвинутые мэйнстрим-языками, начинают чесать репу относительно проблем скрещивания типов и классов (и зачем это автор Python Гвидо ван Россум решил пойти на разделение понятия типа и класса?):

На самом деле действительно интересная тема. Она показывает, что правильных идей мало и люди разными путям но все же выходят на них. Питоновцы, Хаскелевцы, Явщики, Дотнетчики, Немерлисы и Скалолазы все по тихоничку движутся в одном в одном направлении, но с разных сторон. И потихоничку они приходят к очень похожим решениям. Каждый со своим колоритом, но все же к очень похожим. Интерфейсы, классы типов, вывод типов, статическая типизация... все это правильные решение и все ползут в этом направлении. Питон снизу на пузе. Дотнет сбоку на мешке с баксами. Немеле и Хаскель сверху на научном багаже. Но все движутся в одном направлении. http://www.rsdn.ru/forum/?mid=2308475

Как образно выразились, пока что "мэйнстримастые" языки куда-то ползут... (а понимают, вообще куда?)

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


Вряд ли я это внятно обосную, но роль "чистой" математики несколько преувеличена (ИМХО, ИМХО, ИМХО...).

Не знаю, есть ли здесь связь, но вот у одного парня на RSDN, похоже, тоже что-то наболело.
Гаусса цитирует... (почему-то по книжке Вирта "Систематичное программирование" :) ).
http://www.rsdn.ru/Forum/Message.aspx?mid=2310941#2310941

Ответ на »сообщение 2052« (Владимир Лось)
___________________________

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

>>"Можно" это еще не значит "нужно".

А мне, Илья, больше понравилась фраза одного американского инженера из фильма (по каналу Дискавери), посвящённого разработки высотного гиперзвукового самолёта:

Сначала мы должны понять, можем ли мы это, а потом уже решим хтим ли мы этого и нужно ли оно нам.

Выглядит как еще одна формулировка англосаксонского принципа: значение имеют возможности, а не желания.


>>Выражать логику состояний и архитектурные решения на языке математических "чистых" функций для моего мышления неприемлемо.

А кому-то - совсем наоборот... :о)

Красиво, но сомнительно.
Здесь, конечно, скорее мировоззренческий вопрос.
Вряд ли я это внятно обосную, но роль "чистой" математики несколько преувеличена (ИМХО, ИМХО, ИМХО...).

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

Что бы удержаться на месте, нужно бежать вперёд изо всех сил! А иначе неизбежно отстанешь!

Для начала надо бы понять, куда бежать-то:

.. Ошеломленные турецкие пастухи в местечке Джевас в провинции Ван в восточной Турции были вынуждены наблюдать, как вслед за одной овцой, которая прыгнула с обрыва и разбилась, все их стадо в количестве 1500 животных последовало ее примеру и бросилось с того же самого обрыва. В конце концов, на дне обрыва образовалась груда из 450 мертвых животных, передает АР со ссылкой на турецкую газету Aksam. Те овцы, которые спрыгнули позже, выжили, поскольку растущая гора трупов смягчила падение. ..

2005-07-11

Ответ на »сообщение 1994« (Илья Ермаков)
___________________________
Не знаю, не знаю, системное программирование на ФЯ как-то противоестественно.
http://coyotos.org

"Можно" это еще не значит "нужно".
А мне, Илья, больше понравилась фраза одного американского инженера из фильма (по каналу Дискавери), посвящённого разработки высотного гиперзвукового самолёта:

Сначала мы должны понять, можем ли мы это, а потом уже решим хтим ли мы этого и нужно ли оно нам.

И я этого инженера понимаю. Задронов хихикает по поводу того, что американцы истратили на изобретение пишушего механизьма для космонавтов 2млн долларов, а наши пишут простым карандашом... Оно то может и весело, да только в процессе своей разработки, американцы столько всего попутно узнали, наизобретали и открыли...

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

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

Вон в соседней ветке Jack Of Shadows утверждал, что "надо учить школьников ФЯ". Не надо.
НАДО!!! может и не всех, но - НАДО!
Это просто как невод - вылавливаем способных "на чём-то другом".
Притом, вы не забывайте, что САМ Дейкстра писал (по памяти): "... хотя некоторые и считают программирование на функциональных языках (или лиспе - не помню), самым лёгким способом впустую использовать вычислительную мощь компьютера, необходимо признать, что с появлением этих языков, некоторые наши учёные смогли решить задачи, к которым до этого они не могли даже подступиться..."

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

По поводу ссылки на garbage collector в описаниях оберонов.

В описании языка Oberon (точнее, Revised Oberon образца 1990 г.) упоминания о сборке мусора нет. Как нет и DISPOSE в SYSTEM. Но описание не являлось стандартом (там, например, не оговорено, что SYSTEM - предмет для изменений со стороны разработчиков компиляторов, хотя это Виртом везде и всюду упоминалось еще со времен Modula-2).

Как известно, первые активно цитируемые публикации по Оберону - "Type Extensions" (April 1988), "From Modula to Oberon" (June 1988) и "The Programming Language Oberon" (June 1988). Последняя обычно выпадает из поля зрения, поскольку язык в 1990 г. был несколько изменен.

На самом деле, еще в июне 1987 г. вышла статья Вирта "Extensions of Record Type" (SIGSCE Bulletin, June 1987). Это была предварительная версия статьи "Type Extensions". Но и там, и там про обязательность автоматической сборки мусора ничего не сказано. А вот в "From Modula to Oberon" сказано явно, но не применительно к языку Oberon: The concept of the planned operating system also called for a highly dynamic, centralized storage management relying on the technique of garbage collection.

Язык Oberon создавался как язык реализации системы Oberon, так что больших сомнений относительно намерений Вирта "нагрузить" язык Oberon автоматической сборкой мусора нет. Все известные мне реализации системы Oberon (и самые ранние) сборку мусора имели.

В описании языка Oberon-2 (1993) о сборке мусора сказано недвусмысленно. Ну а о КП говорить даже излишне.

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


ANYPTR и ANYREC, конечно, в КП.
В ETH Oberon, кажется, есть PTR (без префикса SYSTEM).
А там, где нет, это тоже не так уж страшно.
Заведем модуль (например, Generic) и определим в нем типы:
ANYREC = RECORD END;
ANYPTR = POINTER TO ANYREC;

Ну, это то понятно. Получается эдакий нано-TObject с одной стороны, и (void*) с другой.


По поводу ссылки на garbage collector в описаниях оберонов.
Oberon-1 не предназначался в качестве руководства по программированию на Обероне (так заявлено в его тексте).

Там явно сказано следующее:

This report is not intended as a programmer's tutorial. It is intentionally kept concise. Its function
is  to  serve  as  a  reference  for  programmers,  implementors,  and  manual  writers.

То есть, это не пособие по программированию, не учебник, но описание языка для тех кто пишет руководства по программированию (те самые учебники), тех кто пишет реализации языка (в т.ч. компиляторы, ран-тайм среды и проч.), и программистов. А ведь для этой всей братии таки следует знать что тут подразумевается сборщик мусора. Нет, они конечно догадаются, но факт есть факт - описание Oberon'a не совсем полно.

В описании Oberon-2 сказано вполне определенно:

Которое также не является тем самым учебником. Никаких отличий в этом плане от описания Оберона.

Ответ на »сообщение 2048« (Alexey Veselovsky)
___________________________

Возможно я таки страшный зануда, но в Обероне типов ANYREC и ANYPTR нет. В Обероне-2 по моему тоже. Возможно есть в Компонентном Паскале.

ANYPTR и ANYREC, конечно, в КП.
В ETH Oberon, кажется, есть PTR (без префикса SYSTEM).
А там, где нет, это тоже не так уж страшно.
Заведем модуль (например, Generic) и определим в нем типы:

ANYREC = RECORD END;
ANYPTR = POINTER TO ANYREC;

По поводу ссылки на garbage collector в описаниях оберонов.
Oberon-1 не предназначался в качестве руководства по программированию на Обероне (так заявлено в его тексте).
В описании Oberon-2 сказано вполне определенно:
In Oberon?2, the predeclared procedure NEW is used to allocate data blocks in free memory. There is, however, no
way to explicitly dispose an allocated block. Rather, the Oberon environment uses a garbage collector to find the
blocks that are not used any more and to make them available for allocation again.
А уж в описании КП заявлено совсем однозначно: без garbage collector это уже не КП.

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


В Обероне есть метапрограммирование, на уровне рантайма. Правда, библиотеки не стандартизированы.
Есть базовый тип для всех записей ANYREC и ANYPTR, можно выяснить реальный тип, поднять имена и значения всех полей и т.п.


Возможно я таки страшный зануда, но в Обероне типов ANYREC и ANYPTR нет. В Обероне-2 по моему тоже. Возможно есть в Компонентном Паскале.

Кстати, забавно, что в описании Оберона нет упоминания про сборщик мусора, несмотря на то что оператор NEW есть, а вот оператора DISPOSE (или DELETE) нет. Т.о. (по описанию языка) получается что возможено только неуменьшение объема выделенной памяти для программы.

Кстати, сборщик мусора и на практике не является непременным атрибтом языков Оберон-семейства. В том же XDS, на сколько я помню, сборщик мусора во-первых может быть отключен, во-вторых, там есть таки Dispose, и в-третьих там он не особенно хорош. В частности там был пример какой-то программы (использующей сборщик мусора) которая периодически падала (при слишком больших параметрах вводимых пользователем, кстати, эти параметры не были особенно большими). В Pow! - также есть Dispose (о котором нет ни слова в описании Oberon'a).

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

Бедный паскаль. Одни хотят удалить из него слово класс. Другие - засунуть в него сбощик мусора :))

"Удалял" слово class и засовывал сборщик мусора один и тот же человек - Никлаус Вирт. Хотя было бы что удалять: в классическом Паскале Вирта слова class (да и этого понятие) в помине не было.

Если ничего не путаю, то слово object (а не class) в паскалях появилось сначала в Object Pascal, но не в том, что от Borland, а в Паскале от Apple (1985), разработанном командой Ларри Теслера. http://www.mactech.com/articles/mactech/Vol.02/02.12/ObjectPascal/

В мае 1989 г. Borland выпустил Turbo Pascal 5.5 c ООП-расширениями (но там было слово object, а не class, если это для кого-то существенно), скрестив ужа с ежом: Object Pascal от Apple с C++.
Turbo Pascal 5.5, the world-standard Pascal compiler, adds Object-Oriented Programming. Combining the simplicity of Apple's Object Pascal language with the power and efficiency of C++ to create Turbo Pascal 5.5, the object-oriented programming language for the rest of us. Turbo Pascal 5.5 came in two versions: Turbo Pascal (the base product), and Turbo Pascal Professional (included Turbo Assembler and Turbo Debugger). http://thecoadletter.com/article/0,1410,20803,00.html

А Borland "переобозвал" свой Паскаль тем же названием Object Pascal, что привнесло сильную путаницу. В 1994 г. Apple закрыл свой проект, а в феврале 1995 г. Borland выпустил среду Delphi, внутри которой язык (где было уже слово class) назывался сначала Object Pascal, а потом был переименован просто в Delphi.

Опять-таки, если это для кого-то важно: Object Pascal от Apple имел отношение к Вирту (с ним, по крайней мере, консультировались), а Object Pascal от Borland делался без "авторского контроля".