Здравствуйте, AVC, Вы писали:

AVC>Насчет классического Паскаля Вы, несомненно, правы. Для демонстрации ООП он не годится.
AVC>Но за что "досталось" бедному Оберону?

Попробуй нарисовать простейшую иерархию классов и пример их взаимодействия на Обероне и сравни с той же джавой (которая типа копия). Посчитаем синтаксический оверхед Насчет компонентного паскаля не знаю, может там все лучше.

P.S. Понятно, что писать в ОО-стиле можно и на С (без плюсов) и на асме. Все упирается в "шашечки", которых Вирт лишил свой язык сознательно.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Дарней, Вы писали:

AVC>>>Когда-то (давно уже) я предложил на одном из форумов рассмотреть язык Оберон в качестве языка для обучения студентов.

Д>>еще один изувер
Д>>за что вы так бедных студентов не любите?

E>Зря ты так. Паскаль в качестве первого языка при программировании очень хорош. Почему бы его место сейчас не отдать Oberon-у. Язык, как мне представляется, простой, лаконичный, модульный, надежный. Для первого года обучения, имхо, то, что нужно. А затем уже можно на C++/Java/C# переходить.

Оберон и другие языки из семейства паскалеподобных по моему мнению очень мешают пониманию некоторых концепций программирования. За тот год который я провёл программируя на паскале я так и не смог понять, что такое указатель. Только поймите меня правильно. Использовать указатели в паскале я умел, но мне почему-то всегда нужно было обращаться к справочнику. Абстракция указателя, его синтаксис, а так же управление памятью в паскале и в ему подобных языках совсем неинтуитивны. Я помню, как только я перешёл на С, все проблемы с пониманием ушли сами собой. Тут я мог себе чётко представить память как последовательность ячеек, а указатель как адрес в памяти. Malloc был гораздо естественнее паскалевского new(p); сразу понятно откуда берётся память. Да и преобразования массивов к указателям немало этому процессу понимания способствовали. Причём типы указателей в С совершенно этому не препятствуют. Тогда как в паскале они заставляют видеть указатели разных типов по разному. Я помню, как месяца через три, после того, как я перешёл с паскаля на С, я попробовал написать какую-то несложную программу на паскале и больше часа потратил на то, чтобы преобразовать какие-то одни простые типы к другим. Это определило моё отношение к паскалеподобным языкам. С тех пор за более чем 10 лет я не написал на них вообще ничего.

Вот так. Не стоит учить Оберону. Мне подобный язык не пригодился. Да и у 95% остальных, я думаю, был сходный опыт.

Здравствуйте, alexeiz, Вы писали:

E>>Паскаль в качестве первого языка при программировании очень хорош. Почему бы его место сейчас не отдать Oberon-у. Язык, как мне представляется, простой, лаконичный, модульный, надежный. Для первого года обучения, имхо, то, что нужно. А затем уже можно на C++/Java/C# переходить.

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

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

Здравствуйте, AVC, Вы писали:

AVC>Вот другой пример. Наш новый сотрудник для реализации достаточно сложной отдельной программы (отладчика) выбрал (самостоятельно! я никакого отношения к этому не имею) Компонентный Паскаль, с которым был знаком только с моих слов и по описанию языка.
AVC>Я усомнился (именно так — я (поклонник Оберона) усомнился ) в рациональности такого шага — язык для него новый.
AVC>Говорю ему через несколько дней: таких-то вот компонентов у тебя, вероятно, нет; можешь приспособить мои, написанные на Си. А он отвечает: да я их уже на Компонентном Паскале реализовал — все работает.
AVC>Это я к тому, что простота имеет все же значение.

интересно, это только мне ТВ-рекламу напомнило? Типа, купите наш журнал и ваши волосы станут мягкими и шелковистыми

AVC wrote:

> • Не нова также идея строгой типизации с поддержкой динамических типов
> и системы "сборки
> мусора", причем роль первооткрывателя здесь тоже сыграл цюрихский ETH.

Эээээ? Поддержка динамических типов и сборки мусора появилась ТОЧНО не в
ETH.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Поэтому проще всего взять язык где "неправильно" просто нельзя писать
C>Кстати, так и делают в MITе — там используют Scheme.

Нельзя писать, говорите? А я все-таки попробую

(define  d 0) 
(define  m (make-matrix 4 4)) 
(define  n (make-matrix 4 4)) 

(define (PoschitatDeterminant )
  ;Тут считают детерминант матрицы m
  ...
  (set! d (+ d ...))
  ...)

(define  (UmnozhitMatricy)
  ;Тут умножают матрицу m на n
  ...
    (matrix-set! m i j (* ...)
  ...)

Здравствуйте, AndreyFedotov, Вы писали:


AF>Полностью согласен! Особенно изуитски это выглядит у Вирта. Он единственный кто регулярно заявляет о том, что мол его языки позволяют писать только в правильном стиле.

Во-первых, Вирт такого не заявлял. Во-вторых, масса других авторов заявляла именно это.

AF> А то до сих пор вижу динозавров, которые утверждают, что мол алгоритм сортировки — это "суть программирования", а объекты — ерунда (и в общем с определённой точки зрения правы — но не для тех детей, кого они этому учат) а потом бедолаги обнаруживают, что вокруг них одна "едунда", а "суть программирования" используется лишь в готовом виде (а за попытки писать свои сортировки Тим лиды лупят по рукам)

Имхо, большинство преподавателей убеждены, что суть программирования — выбрать готовое решение и правильно подставить параметры.
А объекты и в самом деле ерунда. Это вам и Пол Грем подтвердит.

Здравствуйте, Трурль, Вы писали:

Т>Во-первых, Вирт такого не заявлял. Во-вторых, масса других авторов заявляла именно это.

интересно, зачем он тогда вообще затевал всю эту идею с примитивизацией синтаксиса?

Т>А объекты и в самом деле ерунда. Это вам и Пол Грем подтвердит.

Объекты — ерунда. А вот архитектура — нет. Но как раз этому не учат

Трурль wrote:

> C>Поэтому проще всего взять язык где "неправильно" просто нельзя писать
> C>Кстати, так и делают в MITе — там используют Scheme.
> Нельзя писать, говорите? А я все-таки попробую

Забыл сказать, set запрещают использовать.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Чтобы писать потом код хотя бы примерно так:
C>

program blah;

type
    Matrix4 = array[1..4][1..4] of real;

function Multiplicate4(m1,m2 : Matrix4) : Matrix4;

Функция возвращающая матрицу? Ну-ну, флаг Вам в руки. sizeof(Matrix4) = 4*4*sizeof(real) = 96 // точно не помню, вроде в Турбо Паскале real 6 байтов было.

А вот как надо правильно писать:

  TYPE
    Matrix = ARRAY OF ARRAY OF REAL;

  PROCEDURE Mul (IN a, b: Matrix; OUT c: Matrix);

Здравствуйте, Владик, Вы писали:

В>Попробуй нарисовать простейшую иерархию классов

А что Вы имеете в виду под "простейшей иерархией классов" и под "попробуй нарисовать" в особенности? Если не секрет.

Сергей Губанов wrote:

> Функция возвращающая матрицу? Ну-ну, флаг Вам в руки. sizeof(Matrix4)
> = 4*4*sizeof(real) = 96 // точно не помню, вроде в Турбо Паскале real
> 6 байтов было.

Нормальные компиляторы делают return value optimization для таких
случаев (то есть неявно переписывают функция в виде c out-параметром).

Невозможность создания удобных типов с эстафетным владением — это вообще
минус Оберона.

> А вот как надо правильно писать:
>
> TYPE
> Matrix = ARRAY OF ARRAY OF REAL;
>
> PROCEDURE Mul (IN a, b: Matrix; OUT c: Matrix);
>
Нет, так как не понятно, что c — это возвращаемый результат из просмотра
исходников вызывающего кода.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Забыл сказать, set запрещают использовать.

Настоящему индусу завсегда везде ништяк.

(define  m ...)
(define  n ...)

(define (PoschitatDeterminant)  
   ;детерминант матрицы m

(define  (UmnozhitMatricy)  
  ;произведеие матриц m и n
...
(define  d (PoschitatDeterminant)) 
...
(define  m (UmnozhitMatricy))

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Объем спецификации C# 2 не меньше, чем объем спецификации C++ даже,

+1

ПК> особенно при учете того, что спецификация C++ заметно подробнее.

-1

Здравствуйте, AVC, Вы писали:

AVC>1) Сочетание статической типизации, динамических типов и сборки мусора, с гарантией полной проверки типов (type safety).

Была в VB.

AVC>2) Раздельная компиляция с межмодульным контролем соответствия типов.

Была в VB.

AVC>3) Динамическая загрузка модулей "по требованию".

Была в VB.

AVC>4) Возможности метапрограммирования (в т.ч. рефлексия).

Была в VB (COM).

AVC>5) Гипертекстовый интерфейс (например, команда вызывалась щечком мышки по текстовой паре модуль.процедура).

Небыло в Ява.

AVC>6) Внедряемые в текстовые документы объекты, обладающие собственным поведением, — апплеты. (Они назывались по разному, но уже Франц называл их именно апплетами.)

Небыло в Ява.

AVC>7) Уникальная в то время переносимость. Разные Оберон-системы имели единый API и единый машинно-независимый формат данных.

Небыло в VB.

AVC>8) Наконец, машинно-независимый мобильный код.

Был в VB.

AVC>И что, перечисленного недостаточно?

Все достаточно. Вывовд однозначный Ява — клон VB.

Твоя аргументация — это PPC (как тут сказали, в простонародии пипец).

Здравствуйте, Сергей Губанов, Вы писали:

СГ>А что Вы имеете в виду под "простейшей иерархией классов" и под "попробуй нарисовать" в особенности? Если не секрет.

Что-нибудь классическое, на чем учат ООП. Иерархия геометрических фигур и т.п. "Нарисовать" — привести код декларации, имплементации и использования.

Здравствуйте, Владик, Вы писали:
В>Нынче модно ООП. Ни классический паскаль, ни Оберон для демонстрации ОО-подхода не подходят.
Вообще-то даже Турбо Паскаль 6.0 — вполне неплохой язык для преподавания. Он не настолько сложен, как С++, почти не содержит магически работающих конструкций за сценой (типа того же сборщика мусора), и вообще довольно-таки прост.
На практике — проблема в преподавателях. Девочка, которая преподавала информатику у нас в школе, никак не могла заучить разницу между 255 и 275 (для длины строки), и единственное, что знала — что "GOTO — это плохо".
Ее никак не напрягали декларации типов навроде

TPersonList = array[1..5] of record Name, LastName:string end;

Про отличия виртуальных методов от невиртуальных я вообще молчу.
При таком уровне преподавания можно дать какой угодно классный язык — все равно ученики вынесут только представление о том, что программирование — какая-то невнятная, темная магия, в которой скока ни учи — ниче не разберешь.

Здравствуйте, Владик, Вы писали:

СГ>>А что Вы имеете в виду под "простейшей иерархией классов" и под "попробуй нарисовать" в особенности? Если не секрет.

В>Что-нибудь классическое, на чем учат ООП. Иерархия геометрических фигур и т.п. "Нарисовать" — привести код декларации, имплементации и использования.

Спасибо за ответ, теперь буду знать.

Здравствуйте, Трурль, Вы писали:

Т>Здравствуйте, AndreyFedotov, Вы писали:


AF>>Полностью согласен! Особенно изуитски это выглядит у Вирта. Он единственный кто регулярно заявляет о том, что мол его языки позволяют писать только в правильном стиле.

Т>Во-первых, Вирт такого не заявлял. Во-вторых, масса других авторов заявляла именно это.

Например? Кто конкретно это заявлял кроме Вирта? Кроме того, я сам читал его книги и статьи по паскалю, где он утверждал именно это. Правда потом он стал более осторожен и стал высказываться в том духе, что мол большинство ошибок проистекают от плохого — сложного и запутанного синтаксиса и под этим соусом предлагал свой оберон — у которого синтаксис мол простой и однозначный. Но ведь смысл этого утверждения — хоть и не настолько прямой — но всё таки очевиден. Или Вам так не кажется?

AF>> А то до сих пор вижу динозавров, которые утверждают, что мол алгоритм сортировки — это "суть программирования", а объекты — ерунда (и в общем с определённой точки зрения правы — но не для тех детей, кого они этому учат) а потом бедолаги обнаруживают, что вокруг них одна "едунда", а "суть программирования" используется лишь в готовом виде (а за попытки писать свои сортировки Тим лиды лупят по рукам)

Т>Имхо, большинство преподавателей убеждены, что суть программирования — выбрать готовое решение и правильно подставить параметры.

Видимо мы видели разных преподавателей

Т>А объекты и в самом деле ерунда. Это вам и Пол Грем подтвердит.

Объекты сами по себе — да. А вот умение понять что нужно сделать, построить правильно архитектуру и спроектировать систему с помощью объектов — вот это и есть суть программирования. И ей, увы, не учат

Здравствуйте, Sinclair, Вы писали:

В>>Нынче модно ООП. Ни классический паскаль, ни Оберон для демонстрации ОО-подхода не подходят.
S>Вообще-то даже Турбо Паскаль 6.0 — вполне неплохой язык для преподавания. Он не настолько сложен, как С++, почти не содержит магически работающих конструкций за сценой (типа того же сборщика мусора),

Я считаю, что наличие GC — только плюс для обучения. Не надо вводить понятия времени жизни объекта и объяснять все связанные с этим грабли прочию "магию".