Полярная лиса...
От: Зверёк Харьковский  
Дата: 31.10.04 07:33
Оценка: +6 :))) :)
Здравствуйте, Сергей Губанов, Вы писали:

К>>Значит, ты мало трахался с системами контроля версий.


СГ>Я неоднократно указывал на то что обероны, еще со времен Модулы, являются модульными языками. Но тут, видимо, никто не понимает что это такое. Вот и Вы тоже туда же. Не понимаете в чем состоит преимущество модульности... С модулями не возникает проблем контроля версий. Новому модулю дается новое имя (так же как с COM-интерфейсами). В конце концов, модуль — маленький. 1-модуль : 1-программист. Несколько программистов в один и тот же модуль код никогда не пишут.


Не, ну я так больше не могу!
Отладчик — порочно; контроль версий — порочно; подсветку синтаксиса — сделай сам...

И эти люди...
Я фигею, дорогая редакция...
сам слушаю и вам рекомендую: Разные Люди — Она не вышла замуж
FAQ — це мiй ай-кью!
Re: Oberon???????????????????????????????????
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.04 15:06
Оценка: 4 (2) +5 -2
Здравствуйте, LaptevVV, Вы писали:

Оберон — это мертвях. Учить ему будущих программистов все равно что учить латыни будущих переводчиков. Неужели нехватает живых языков? Чем та же Ява или Шарп хуже?
... << RSDN@Home 1.1.4 beta 3 rev. 206>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Oberon???????????????????????????????????
От: ON  
Дата: 21.10.04 21:06
Оценка: :))) :))) :)))
From: WolfHound rsdn ICQ_315059559
LVV>Хочется альтернативный синтаксис показать.
>Зачем?

программист должен уметь языком овладеть задачей, но чтобы та не подхватила синтаксис
Posted via RSDN NNTP Server 1.9 gamma
Re[21]: Мэйнстрим vs. Самосовершенствование :)))
От: Павел Кузнецов  
Дата: 30.10.04 05:17
Оценка: 24 (6) +1 -1
VladD2:

> ПК> Прикол в том, что алгоритмы из Arrays нельзя применить к List или Deque,


> Да уж. Сортированная очередь — это прикол.


Может это, конечно, (для некоторых) и прикол, но сортированные очереди проходят в курсе изучения Computer Science, а некоторым — о ужас! — даже рассказывают о priority sorted queue

> ПК> Одним из фундаментальных принципов которого является Open-Closed Principle. А запихивание всех подряд функций в тот или иной "класс", у которого нет никаких основных атрибутов (поведение, состояние, инварианты), к ООП никакого отношения не имеет.


> Ну, а теперь представь, что кое-то на ООЯ пытается писать в ОО-стиле. Может они конечно и не удовлетворяют твоей концепции, но пользоваться плодами их трудов чертовски удобно.


Это не "мои" концепции, это один из классических критериев качества объектно-ориентированного дизайна.

> По теории ООП все методы объекта желательно помещать в его класс.


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

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

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

Например, представим, что у нас есть скелет простенькой иерархии "библиотечных" контейнеров (псевдокод):
interface Sequence<T>
{
   class Pos;

   uint size();
   bool is_empty();

   Pos begin();
   Pos end();
   Pos next(Pos);

   Pos insert(Pos, T);
   void remove(Pos);
   void clear();
};

interface RandomAccessibleSequence<T> : Sequence<T>
{
   T operator[](int index);
   Pos pos_by_index(int index);
};

class List<T> : Sequence<T>
{
};

class Array<T> : RandomAccessibleSequence<T>
{
};


Итак, мы хотим иметь возможность эти контейнеры сортировать. Допустим, мы решили добавить метод sort() в интерфейс Sequence<>.

Некоторое время мы живем счастливо, но оказывается, что для некоторых задач принципиальным оказывается вопрос: сохраняет ли используемый алгоритм порядок "одинаковых" с точки зрения упорядочивания элементов. Ну, что ж, следуя заведенному порядку, нам будет нужно добавить метод stable_sort().

Но как только мы подобным образом изменим интерфейс Sequence<>, все его наследники "сломаются", т.к. у них-то реализации stable_sort() не будет. Кроме того, есть ли уверенность, что для всех "последовательностей" существуют эффективные методы их сортировки с сохранением порядка "одинаковых" с точки зрения упорядочивания элементов? Ведь у пользователя могут быть свои наследники интерфейса Sequence<T>, о реализации которых мы ничего не знаем... Соответственно, этого делать нельзя, и придется поступать как-нибудь по-другому.

Хорошо, скажем, мы, понимая эту проблему, интерфейс Sequence<> менять не будем, а вместо этого добавим stable_sort(), скажем, в Array<>, где он более всего нужен, и будет иметь реализацию по-умолчанию, на случай, если кто-то от Array<> унаследовался.

Однако на этом наши приключения не заканчиваются: ведь у пользователя, в его наследнике Array<>, уже могла быть своя stable_sort(), обладающая несколько иной семантикой, и эта функция "перекроет" определенную в Array<>. В таком случае новые функции, принимающие Array<>, и предполагающие соответствие семантики stable_sort() той, что заявлена в Array<>, правильно работать не будут.

Далее, если представить себе развитие этой иерархии и возможную потребность добавления в будущем утилит типа find(), find_if(), binary_search() и т.п., то становится очевидно, что в классы этой иерархии эти функции также добавлять будет нельзя.

Есть и еще одна сторона этой проблемы: очевидно, что разработчики библиотеки не могут учесть всех нужд пользователей, и снабдить их всеми нужными им "утилитами". Что же делать пользователям? Следуя "попыткам писать в ОО-стиле", им надо будет унаследоваться от класса, который они захотят "расширить", и добавлять в своего наследника нужные им "утилиты". Но на этом пути их ждет масса трудностей.

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

Во-вторых, даже проделав всю эту работу, они будут становиться в тупик, получая готовые объекты наследников Sequence<> "извне": ведь эти объекты экземплярами их "расширенных" классов не будут. Их придется копировать, или работать с ними по-другому, чем с "последовательностями", созданными в коде приложения.

Какой же выход?

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

Соответственно, по этому поводу разработчики библиотек Java поступили абсолютно правильно, вынеся sort и остальные утилиты для работы с массивами в совершенно отдельный "класс" java.util.Arrays. Единственное нарекание, что был использован именно класс, а не namespace, т.к. основных атрибутов "настоящих" классов у java.util.Arrays нет, но это уже претензии не к разработчикам библиотек, а к языку, т.к. там такой функциональности просто-напросто нет.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[11]: Обновление
От: Mamut Швеция http://dmitriid.com
Дата: 28.10.04 11:36
Оценка: 41 (5) +2
Коряво программировать в пределах одного модуля — возможно не получится.

Но умение правильно программировать не упирается только в типобезопасность, или в легкость синтаксиса, или удобство подмножества каких-либо операций (арифметических или иных). Такие "фишки" — та самая "слегка" помощь программисту, которая никак не поможет ему в создании сложной системы, например.

Умение правильно программировать — это прежде всего умение понять поставленную задачу, умение планировать, умение разделять задачу на более мелкие задачи, умение отслеживать зависимости и много еще чего.

При этом:

— типобезопасность? Если изначально были неправильно выбраны типы, то горе-программер никуда не уйдет от рефакторинга всего кода, где эти типы использованы (ну или будет использовать какой-нибудь reinterpret_cast в С++).

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

При чем все это справедливо и для других языков программирования, не только для Оберона.

Язык не может быть панацеей для программиста. Вне зависимости от языка можно создать монструозные неэффективные программы. И Оберон никак не поможет человеку, нежелающему научится думать и планировать. А для обучения этому С# или Питон ничем не хуже Оберона (или даже лучше — ввиду того, что они широко распространены и активно развиваются)
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


dmitriid.comGitHubLinkedIn
Re[25]: Мэйнстрим vs. Самосовершенствование :)))
От: Павел Кузнецов  
Дата: 01.11.04 19:29
Оценка: 33 (4) +3
VladD2:

> ПК> Я правильно понял, что ты утверждаешь, что Open-Closed Principle не имеет отношения к ОО дизайну? Если ты о чем-то другом, пожалуйста, сформулируй свою мысль яснее.


> Он не имеет отношения к базовым концепциям ООП и приплетается тобой не к месту. Андестенд?


Чего же здесь непонятного? Понятно, что ты даже в www.google.com посмотреть не сходил, прежде чем утверждать подобные вещи.

>>> Более того. В твоем видение она даже становится вредной, так как отрицает базовые концепции вроде инкапсуляции.


> ПК>Это каким же образом? Как именно вынесение sort() за пределы Array нарушает инкапсуляцию?


> Я тебе это уже объяснял. Сортировка — это метод. Имея возможность применять его к более широкому ряду объектов мы нарушаем принцип инкапсуляции.


Как ты себе представляешь нарушение инкапсуляции в данном случае? Если интерфейс класса позволяет передать его в sort(), инкапсуляция не будет нарушена, т.к. и без sort() пользователь может сам проделать эквивалентные действия. Если же предполагается, что эти действия нарушат инварианты класса, то это просто означает, что у данного класса интерфейс составлен неверно, т.к. он не должен позволять нарушать инварианты. В любом случае наличие "внешней" функции sort() инкапсуляцию класса не нарушает.

> ПК>Давай-ка ты подтвердишь это утверждение хоть какими-то ссылками на классику ООП.


> Давай-ка ты пойдеш лесом. А? Я тебе не нанимался искать ссылки по всему Интернету.


Ок. Так и запишем: свое утверждение о нарушении базовых положений ООП в результате вынесения sort() за пределы класса Array Влад доказывать отказался.

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


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

> ПК> Нет, этого "требования инкапсуляции" не говорят. Впрочем, подозреваю, что ты просто можешь очень неточно выражать свои мысли. Чтобы была хоть какая-то ясность, насколько применимы "требования инкапсуляции" в твоей трактовке к классическим образцам дизайна, прокомментируй свое высказывание, процитированное выше, на некоторых из наиболее характерных в этом отношении design patterns: Command, State, Strategy, Visitor, Builder.


> Не, ну, нужно вообще потерять чувство реальности, чтобы просить в качестве коментария написать небольшую книгу (ну, страниц так на 400).


Причем здесь книга? Для того, чтобы указать, что то или иное изменение интерфейса нарушает инкапсуляцию, достаточно продемонстрировать один пример, как пользуясь данным методом можно будет нарушить инварианты класса.

А так... Ты привел свое правило размещения методов в классе:

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

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

> ПК> Как же так получается, что (потенциальная) модификация объекта специально выносится за его пределы? Неужели все эти паттерны тоже нарушают инкапсуляцию?

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

Я вполне могу, и уже это делал: инкапсуляция нарушается, если интерфейс класса позволяет нарушать его инварианты. Вопреки твоим утверждениям положение функции сортировки вовне класса к таким последствиям не приводит.

> ПК> так как в данном примере отсутствие определенного интерфейса приводит к нарушению инвариантов воображаемого класса (он даже не выделен здесь явно). Вот это, действительно, нарушение инкапсуляции.

>
> Если убрать общие слова, то единственной проблемой этого примера является отсуствие инкапсуляции. О чем и шла речь.

Пока что ты так и не показал, как же именно нарушается инкапсуляция в случае вынесения функции sort() за пределы класса Array. От того, что ты утверждаешь, что это так, истинным это утверждение не становится.

>>> Внешние функции той же сортировки — это как раз такое нарушение.

>
> ПК> В случае сортировки никакие инварианты класса Array не нарушаются.
>
> Агащасблин. Сортировка очередей и потоков — это нормально? Не нужно пытаться уйти от обсуждения вопросвов инкапсуляции к черте чему.

Все зависит от определений. В любом случае, если очереди нельзя сортировать, то они не будут предоставлять интерфейс, нужный функции sort(). Если они уже предоставляют такой интерфейс, то наличие "внешней" функции sort() никак на ситуацию не влияет, т.к. пользователь уже волен это делать своими действиями.

> Согласен. Только к делу это не относится. Бывают случаи когда класс в силу не зависимых причин обладает интерфейсом пригодным для применения того или иного метода. Так что случяйное применение можно избежать только строгим подходом к инкапсуляции.


Строгий подход к инкапсуляции как раз и означает, что класс не может обладать интерфейсом, позволяющим нарушить его инварианты. Если это условие не выполняется, рассуждения о положении функции sort() никак степень инкапсулированности не изменят.

> Стремление к супер универсальности и выносе всего в глобальные методы как раз и приводит к подобным причинам.


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

> А уж напичкивание классов типа вектора несвойственными ему методами вроде pop и т.е. просто провацирует к применению классов не по назначению.


Каким образом метод pop() нарушает инкапсуляцию класса vector? И чем, с твоей точки зрения данный метод отличается от Add() или аналогичного?

> ПК>Раздувание интерфейсов классов без необходимости противоречит грамотному проектированию.


> Словоблудие.


Очень странно, что с такого словоблудия начинаются большая часть более-менее объемных книжек по ООП

> Ты можешь хоть на ушах ходить, но пользоваться дотнетными коллекциями проще, удобнее и безопаснее.


Удобнее пользоваться чем какими коллекциями? Напоминаю, что речь шла о массивах в Java.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[12]: Обновление
От: Кодт Россия  
Дата: 29.10.04 11:23
Оценка: +7
Здравствуйте, Сергей Губанов, Вы писали:

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


Если это шпиля в мой адрес, то это попросту не так.
Уж на чём я по-настоящему воспитан, так это именно на Паскале. Более того, 6 лет это был основной язык разработки.
Хотя руки дотягивались до тучи языков, включая экзотические.

И мой кругозор позволяет без особых усилий писать код любого качества (от стройного до обфусканного) и с любой ведущей парадигмой на любом языке. (Самый мрачный экзерсис, который я когда-то делал — это ООП поверх БД на древнем Клиппере. В качестве курсовика. Эта хреновина даже работала).

Дейкстра не зря говорил про детей, искалеченных бейсиком. Искалечить можно любым языком! Особенно, если догматически впихивать.
http://files.rsdn.org/4783/catsmiley.gif Перекуём баги на фичи!
Re[27]: Мэйнстрим vs. Самосовершенствование :)))
От: Павел Кузнецов  
Дата: 02.11.04 15:46
Оценка: 50 (5) -1
AndrewVK:

> <...> чем такой вариант:

>
> public interface ISortable
> {
>     void Sort();
> }
>
> public class SomeList : IList, ISortable
> {
>     ...
>     public void Sort() {...}
> }
>
> ...
> someListInstance.Sort();
>

>
> хуже такого:

По-моему, ниже опечатка, и ISupportSort от IList унаследован быть не должен.

>
> public interface ISupportSort : IList
> {
>     int CompareElements(int index1, int index2);
>     void Exchange(int index1, int index2);
> }
>
> public class SomeList : IList, ISupportSort
> {
>     ...
>     int ISupportSort.CompareElements(int index1, int index2) {}
>     void ISupportSort.Exchange(int index1, int index2) {}
> }
>
> ...
> SomeSortFunction(someListInstance);
>


Имхо, в последнем варианте функция сравнения элементов в ISupportSort быть не должна по нескольким причинам, но это уже вопрос отдельный, хотя и похожий на обсуждаемый.

Первый вариант хуже по нескольким причинам:

Сортировка не является основной функциональностью SomeList

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

В частности:
  • Сохраняется ли в результате сортировки порядок элементов, для которых CompareElements возвращает 0 (т.е. они "равны" с точки зрения функции сравнения). Для некоторых использований это является критичным моментом.
  • Какова алгоритмическая сложность используемого алгоритма. Не секрет, что разные алгоритмы сортировки работают принципиально по-разному на разных входных данных. Например, классическая "быстрая сортировка" очень плохо подходит для "почти упорядоченных" последовательностей, в том смысле, что она работает намного хуже других алгоритмов, если не на месте стоят всего несколько элементов. И во многих случаях только пользователь может знать характер "входных" данных.
  • Каковы требования к памяти используемого алгоритма. Для большинства использований, особенно если используются "простые" алгоритмы, типа той же "быстрой сортировки", это не суть важно, но там, где это имеет значение, обойти эту проблему весьма непросто.
    И т.д., и т.п.

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

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

    Есть множество аналогичных алгоритмов, которые нужны пользователю

    И если пытаться тем или иным образом включить все эти алгоритмы в SomeList, возникает множество проблем, аналогичных описанным для сортировки, плюс еще некоторые.
  • Часть из этих алгоритмов нуждается в том же интерфейсе, что и сортировка. Например, в ряде приложений необходимым является использование так называемой "частичной сортировки", т.е. алгоритма, приводящего последовательность к такому виду, что все элементы "меньшие" заданного, находятся "слева" от него, а все "большие" — "справа". По сути этот алгоритм является одним из шагов "быстрой сортировки".
  • Другие алгоритмы могут отличаться по назначению. Например, поиск. К поиску необходимость возможности "настройки" пользователем применима в неменьшей степени, чем к сортировке. И в неменьшей степени очевидно, что предоставить в классе SomeList, для которого поиск является "вспомогательной" функциональностью, все нужные пользователю, но вполне аналогичные алгоритмы не реально.
  • В любом случае, разработчики "библиотеки" предусмотреть все нужные пользователю алгоритмы не могут принципиально.

    Повторное использование алгоритмов

    Сортировка, поиск и множество других алгоритмов может быть повторно использовано, как для других "библиотечных" контейнеров, так и для контейнеров, создаваемых пользователем.
  • Во втором случае все предоставляемые библиотекой алгоритмы доступны пользователю сразу, "с конвейера", без дополнительных усилий со стороны разработчиков библиотеки.
  • В первом случае у разработчиков библиотеки никакой объективной потребности предоставлять алгоритмы в "отдельном" виде нет, а если они и пошли на этот шаг "доброй воли", то алгоритмы пользователя, аналогичные "библиотечным", к "библиотечным" классам применяться не смогут.

    Расширяемость множества алгоритмов

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

    Если предполагается, что добавление подобных алгоритмов непосредственно в интерфейс класса — желаемый образ действий, то расширять используемый набор алгоритмов для пользователя становится достаточно тяжело, т.к. все обертки/переходники, предназначенные для расширения функциональности, требуют усилий по сопровождению, и не всегда покрывают все необходимые сценарии использования.

    Никаких из этих проблем не возникает, если "вспомогательные" алгоритмы (то есть не основные для самого класса, в данном случае SomeList) будут вынесены за пределы класса.
    Posted via RSDN NNTP Server 1.9 gamma
  • Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[5]: Oberon???????????????????????????????????
    От: bkat  
    Дата: 21.10.04 08:34
    Оценка: 1 (1) +5
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, bkat, Вы писали:


    B>>этот язык не очень-то популярен


    СГ>Именно об этом Вирт и рассказывает в своем докладе:

    СГ>

    СГ>Преподавание информатики: потерянная дорога
    СГ>Приветствие на открытии Международной конференции по преподаванию информатики ITiCSE
    СГ>г. Аархус (Дания), 24 июня 2002 г.

    СГ>http://www.inr.ac.ru/~info21/greetings/wirth_doklad_rus.htm

    Да, я это читал. Что это меняет?
    Повторюсь, студентам об Обероне (и не только) стоит рассказать.
    Но будет жестоко по отношению к ним делать упор именно на Оберон.
    В самом EHT, как я понял, Оберон позиционируется как исследовательский язык.
    И это нормально. Но это не язык индустриального программирования.
    Я конечно понимаю желание изменить мировые тенеденции.
    Но студенты то тут причем?
    Прагматичные швейцарцы вот учат Java, С++, C# и еще многое по мелочам...

    В конце концов мы же все прекрасно понимаем, что язык — это дело десятое.
    Реальные проблемы лежат в совсем иной плоскости...
    Re[15]: Обновление
    От: Зверёк Харьковский  
    Дата: 29.10.04 08:08
    Оценка: 1 (1) +5
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Представьте себе таку вещь:

    СГ>
    СГ>PROCEDURE Pr1();
    СГ>BEGIN
    СГ> (* ... *)
    СГ>END Pr1;
    СГ>    +-------------+
    СГ>    | Нажми меня  |
    СГ>    +-------------+
    СГ>

    СГ>где под прямоугольником с надписью "Нажми меня" я попытался изобразить обыную виндозную кнопку. То есть прямо в текст проги можно запихнуть кнопку, и, например, ассоциировать ее с процедурой Pr1(). Нажимаешь на кнопку — процедура выполняется!

    Круто!!! А зачем?
    Это мы, Зверьки! << Metallica — The Memory Remains >>
    FAQ — це мiй ай-кью!
    Re[15]: Обновление
    От: WFrag США  
    Дата: 29.10.04 08:15
    Оценка: 1 (1) +5
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Но! Обращаю Ваше внимание, что для того чтобы смотреть исходники скачать и установить BlackBox Вам все равно придется, так как формат в котором хранятся исходные тексты программ не plain-text, а бинарный формат *.odc (Oberon Document). odc-файл это файл в котором в бинарном виде сохранен конгломерат взаимоссылающихся друг на друга объектов (сериализованные объекты). Благодаря этому, oberon document представляет собой среду напоминающую MS Word, то есть текст можно форматировать (шрифт, цвет, размер, стиль — каждой буквы). Можно вставлять картинки, управляющие кнопки, едиты и прочие контролы, а в принципе, даже работающие программы.


    Боюсь, не по вкусу это придется всяким любителям Unix-way и plain-текст форматов

    Что мы теряем: системы контроля версий придется затачивать под этот формат, всяческие поиски/find/grep/e.t.c идут лесом, и.т.д. По сути, нужно выкидывать все наработанные средства работы с plain-текстом и нарабатывать новые. А разработывать средства под каждый формат — никакого здоровья не хватит.

    Нафиг это нужно? Так что с моей точки зрения — это однозначно зло. Плюсов, честно говоря, не вижу. Шрифт, стиль, текст — это свойства представления текста программы, и соответственно должны быть отделены от нее (отделяем сущность от ее представления), с чем в какой-то мере справляются различные раскрашиватели кода. Контролы — это уже интереснее, но все равно особых плюсов не вижу.

    Это все будет более-менее работать, пока не потребуется сделать что-нибудь сверх возможностей редактора. Например, поиск регулярного выражения, diff, замены по регулярному выражению. Да хоть бы даже число слов в программе подсчитать.
    Re[6]: Мэйнстрим vs. Самосовершенствование :)))
    От: Зверёк Харьковский  
    Дата: 25.10.04 16:21
    Оценка: +3 :)))
    Здравствуйте, VladD2, Вы писали:

    [флейм о борландо-филах я выгрыз. старо.]

    VD>...почему бы не учить на том, что может с большой вероятностью быть востребовано, а не на мертвяке?

    VD>...Вот и не нужно объяснять это на "выдуманных" язвках. Объясняйте это на вымученных языках...
    Подумал я... и вот чего надумал.
    С одной стороны — человеку, который вообще не представляет, как и что делает программист, концепцию цикла бывает проще объяснить на примере

    For I=1 To 10
    Next

    (с) VB

    или

    for i:=1 to 10 do
    begin
    end;

    (c) Pascal

    нежели
    for(int i = 0; i < 10; ++i)
    {
    }

    (c) а то сам не видишь...

    равно как и с некоторыми другими концепциями, где Паскаль жертвует гибкостью ради очевидности.
    (Ахтунг! Контр-примеры на Шарпе не приводить! Я просто иллюстрировал точку зрения)

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

    ЗХ>>Go! — язык, заточенный под программирование агентов.

    VD>Киборги?
    Нееее. Матрица.

    [смолток выгрызен. Вроде договорились.]

    VD>..Но перед тем же Шарпом... Шарп спроектирован как миниуму не хуже (а по сути значительно лучше)... После Шарпа...легко изучить и другие языки... можно даже демонстрировать функциональный стиль...

    Влад, вообще нравственный посыл первого моего поста был таков: нефиг.
    Честно говоря, в свете развязавшейся тут войны, плавно перетекшей в Шарп против Оберона, Шарп против Питона, Шарп против СмолТока твой фанатизм немногим лучше фанатизма Губанова (только тем, что он защищает мертвый язык, а ты — живой. Ну и общаешься ты существенно корректнее)
    В каждом языке есть свои кайфы, и холиваром ничего не докажешь.

    Хотя круче С++ языка нет, не было, и не надо, а C# — конъюнктурная поделка Мелкософта
    FAQ — це мiй ай-кью!
    Re[16]: Oberon???????????????????????????????????
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 27.10.04 07:56
    Оценка: :))) :)))
    Здравствуйте, Sinclair, Вы писали:

    S>Не факт, что это достоинство. Фактически, это означает необходимость везде использовать Fully Qualified Names. В среде с развитыми библиотеками это привело бы к идентификаторам кошмарной длины. Как вам имя класса System.Data.SqlClient.SqlConnection?


    Фигня. Бывает и покруче. Например:
    System.Runtime.Remoting.Channels.Tcp.TcpServerChannel
    System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
    System.Runtime.InteropServices.CustomMarshalers.EnumeratorToEnumVariantMarshaler
    System.EnterpriseServices.CompensatingResourceManager.ApplicationCrmEnabledAttribute

    И, наконец, рекордсмен в 1.1
    System.Windows.Forms.ComponentModel.Com2Interop.GetTypeConverterAndTypeEditorEventHandler

    2.0 в этом плане естественно более продвинут
    Microsoft.Internal.Deployment.Isolation.Manifest.CMS_ASSEMBLY_REFERENCE_DEPENDENT_ASSEMBLY_FLAG
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    AVK Blog
    Re[17]: Oberon???????????????????????????????????
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 27.10.04 12:04
    Оценка: +6
    Здравствуйте, Kh_Oleg, Вы писали:

    K_O>Насчет ключевого слова MODULE было сказано так: в программе ДОЛЖНЫ обязательно присутствовать MODULE ProgramName, BEGIN и END ProgramName. До BEGIN объявляем переменные, после BEGIN — пишем код.


    Ну то есть чисто на заучивание. Ну так никто не мешает точно так же объяснить и про классы в шарпе. Надо писать и все .
    ... << RSDN@Home 1.1.4 beta 3 rev. 209>>
    AVK Blog
    Re[22]: Oberon???????????????????????????????????
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.10.04 13:18
    Оценка: +5 :)
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>И что с Вами таким делать? Либо аргументированно это объясните, либо я опять скажу (со ссылкой на info21), что компетентные в этом вопросе люди утверждают прямо противоположное.


    В вашей компетенции тут уже никто не сомневается.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[18]: Обновление
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 01.11.04 12:16
    Оценка: -5 :)
    Здравствуйте, VladD2, Вы писали:

    VD> Так проблема в том, что она не нужна, или в том что делать некому?


    Я когда первый раз увидел БлэкБокс, то тоже подумал какого черта нет подсветки синтаксиса. Даже хотел сам написать, благо сделать это не сложно — доступ к вьюхе документа свободный. Потом, по здравому размышлению, согласился с мнением изложенным у info21. Дело в том, что в оберонах служебные слова набираются заглавными буквами, и выделять их цветом уже не надо — и так все видно. Зато цвет можно использовать совершенно для других целей. Например, если нужно, по той или иной причине акцентировать внимание на каком-то участке кода, то просто берешь и красишь его в красный цвет (весь, вместе со служебными словами) или каким-то другим способом изменяешь шрифт на необычный.
    Re[32]: Мэйнстрим vs. Самосовершенствование :)))
    От: Павел Кузнецов  
    Дата: 03.11.04 04:47
    Оценка: 40 (5)
    Undying,

    > ПК> В "Дизайн и эволюция C++" Страуструп описывал, что в ранних редакциях C++ такая возможность была, но ввиду того, что пользователи очень много ошибались, ее используя (подробности, по-моему, не приведены), ее решили убрать.


    > Как я понимаю, концепции интерфейсов тогда еще не было или уже была?


    Была. Кстати, оказалось, что я помнил неверно, и некоторые трудности, с которыми столкнулись пользователи, Страуструп привел:

    Делегирование

    В первоначальном проекте множественного наследования, который был представлен на Европейской конференции группы пользователей UNIX, состоявшейся в Хельсинки в мае 1987 г. [Stroustrup, 1987], фигурировало понятие делегирования [Agha, 1986].

    Пользователю разрешалось задать указатель на некоторый класс вместе с именами базовых классов в объявлении класса. Описанный таким образом объект использовался точно так же, как если бы это был объект, представляющий базовый класс. Например:

    class B { int b; void f(); };
    class C : *p { B* p; int c; };

    Нотация : *p означает, что объект, на который указывает p, будет использоваться так, будто он представляет базовый класс для C.
    void f(C* q)
    {
       a->f(); // означает q->p->f()
    }

    <...>

    Концепция выглядела многообещающей для представления структур, требующих большей гибкости, чем может дать обычное наследование. В частности, присваивание делегирующему указателю могло бы использоваться для изменения конфигурации объекта во время исполнения. Реализация была бы тривиальной, затраты — минимальными. Поэтому данную идею испытали несколько пользователей. Много времени и сил здесь пололжил Билл Хопкинс (Bill Hopkins). К сожалению, все пользователи, применившие механизм делегирования, пострадали от серьезных ошибок и путаницы. Из-за этого возможность была исключена как из проекта, так и из Cfront версии 2.0.

    Причины ошибок:
  • функции в делегирующем классе не замещают функции в классе, которому операция делегируется;
  • функция, которой передается управление, не может воспольозваться функциями из делегирующего класса или каким-то иным способом "вернуться" в делегирующий объект.

    Ясно, что две эти проблемы взаимосвязаны. Разумеется, пользователи были предупреждены. Предостережения не помогли. Более того, я сам забыл собственные правила, и попался в ловушку. Таким образом, проблему нельзя было назвать мелким огрехом, который исправляется с помощью обучения и предупреждений компилятора. В то время она казалась непреодолимой.

    Сегодня мне кажется, что указанные проблемы имеют фундаментальный характер. Для решения первой потребовалось бы изменять таблицу виртуальных функций объекта, которому делегируется управление, если он связан с делегирующим объектом. Это плохо согласуется с языком в целом и с большим трудом поддается разумному определению. Кроме того, обнаружились примеры, когда мы хотели, чтобы два разных объекта делегировали управление одному и тому же "разделяемому" объекту. Нашлись и такие задачи, в которых нужно было делегировать управление через B* объекту производного класса D.


  • > ПК> Сейчас вновь поднимается вопрос добавления автоматического делегирования в язык, но чем это закончится, еще никто не знает...


    > На плюсы все-равно не перейду, могу только восхищаться людьми, которые столько всяких мелочей помнят.


    Да уж... Что есть, то есть: язык монстриком получился. И со временем упрощаться не собирается...
    Posted via RSDN NNTP Server 1.9 gamma
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[19]: Обновление (73 KB)
    От: Mamut Швеция http://dmitriid.com
    Дата: 29.10.04 10:15
    Оценка: 19 (3) +2
    Здравствуйте, Сергей Губанов, Вы писали:

    Извините, но вы в этом собираетесь обучать детей????? Умоляю, возьмите в руки Турбо Паскаль/Турбо С и пропагандируйте, чтобы они еще лет десять оставались главным средством обучения. Или учите людей пользоваться коммандной строкой. Прошу и умоляю. НО НЕ ЭТО:

    http://gzip.rsdn.org/File/9088/blackbox.JPG

    Это УБОЖЕСТВО, с которым невозможно работать.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>


    dmitriid.comGitHubLinkedIn
    Re[2]: Мэйнстрим vs. Самосовершенствование :)))
    От: Зверёк Харьковский  
    Дата: 24.10.04 11:51
    Оценка: 12 (1) +4
    Здравствуйте, VladD2, Вы писали:

    VD>Оберон — это мертвях. Учить ему будущих программистов все равно что учить латыни будущих переводчиков. Неужели нехватает живых языков? Чем та же Ява или Шарп хуже?


    Дорогой Влад!

    "Я тебе один умный вещь скажу, только ты не обижайся" (с) мой папа.

    Наблюдаю я уже который день за этой дискуссией вокруг Оберона-СмолТолка-Питона-и др. и возникло у меня такое впечатление.
    Имхо, ты везде приводишь более-менее верные и логичные аргументы, но не прав в главной своей мысли: "Все пишут на Яве и Шарпе, поэтому учить больше ничего не надо".
    Я считаю, что изучение других языков программирования идет не в минус (забиваем голову ненужной информацией), а в плюс. И не потому, что СмолТолк кому-то может пригодиться (ой, сумлеваюсь), а по очень простой причине: расширение кругозора. Просто понять, что "и такое бывает". Подцепить полезный метод или идею. В конце концов (в парадигме начального вопроса Валерия Викторовича) — просто осознать, "что не в любом языке программирования есть фигурные скобки".

    Возьмем, например, меня .
    В контексте давнего спора про то, какой язык кому нравится, могу слегка скорректировать свое тогдашнее мнение: "я люблю С++ и пока это возможно, буду писать только на нем", но сейчас собираюсь покупать Рихтера про Шарп. Не потому, что хочу на него перейти — интересно, что нового, чем он отличается; как нужно "думать на Шарпе". А и кроме того, книжки, которые валяются на винте, и которые я уже изучил или собираюсь в ближайшем будушем, посвящены языкам: Ada, Assembler, Awk, C--, C++, C#, Delphi, Eiffel, Euphoria, Forth, Go!, Haskell, Java, Lisp, OCaml, Oz, Perl, PHP, Prolog, Python, Refal, Small, Smalltalk, Tcl, VB.

    А еще кто-то умный говорил, что программисту полезно знать основы генетики. Сильно развивает восприятие.
    Думаю, про многие другие науки/дисциплины можно сказать то же самое (что их полезно знать программисту).

    Во. Типа dixi.
    FAQ — це мiй ай-кью!
    Re[9]: Обновление
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.10.04 13:01
    Оценка: 8 (1) +4
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Но он действительно по-дилетантски спроектирован.


    Автор этих строк спроектировал хотя бы один язык? Я уже не говорю о том, что на С++ работает половина программистов.

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

    Ну, а подобные заявления выдают в авторе крикливого дилетанта. В общем, на вашем месте я спягчил бы формулировку. А то как-то совсем не серьезно.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[29]: Мэйнстрим vs. Самосовершенствование :)))
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 02.11.04 14:32
    Оценка: 7 (3) +1 :)
    Здравствуйте, VladD2, Вы писали:

    VD>Специльно не поскипал твою тираду. Так где из всех этих метс я перешел к навазыванию "такого расположения функции sort"? Зачем столько слов? Может быть просто признать тот факт, что это ты пыташся выдать свое мнение за единстванно верное и тем самым навязать его, а я все го лишь говорю, что считаю иначе?


    В словах ПК как раз особой вкусовщины и апелляции к "дуракам, нажимающим на точку" нет. То, что они написаны ПК, ещё не является поводом к упрёкам в том, что он выставляет "своё личное мнение". Почти под всем, что он тут говорил я, к примеру, тоже готов подписаться.

    В самом деле, цитировать довольно объёмные бумажки по OCP, LSP и т.п. в форуме довольно затруднительно, поскольку цитирование неизбежно будет в той или иной степени вырванным из контекста и вызовет ещё более бурное флеймогонство и "ниспровержение авторитетов".
    ... << RSDN@Home 1.1.3 stable >>
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[12]: Мэйнстрим vs. Самосовершенствование :)))
    От: Павел Кузнецов  
    Дата: 28.10.04 03:46
    Оценка: +4 :)
    Sinclair:

    > INT> То же, что и в Яве, то, что в нем объектом приходится делать даже то, что объектом не является.


    > Во как интересно. Например, что?


    Например, я не вполне понимаю, зачем обобщенные алгоритмы типа сортировки делать методами классов Вот пример такого, с позволения сказать, класса: http://java.sun.com/j2se/1.4.2/docs/api/java/util/Arrays.html — ни состояния, ни поведения, ни инвариантов
    Posted via RSDN NNTP Server 1.9 gamma
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[18]: Обновление
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 31.10.04 07:22
    Оценка: :))) :))
    Здравствуйте, Кодт, Вы писали:

    К>Значит, ты мало трахался с системами контроля версий.


    Я неоднократно указывал на то что обероны, еще со времен Модулы, являются модульными языками. Но тут, видимо, никто не понимает что это такое. Вот и Вы тоже туда же. Не понимаете в чем состоит преимущество модульности... С модулями не возникает проблем контроля версий. Новому модулю дается новое имя (так же как с COM-интерфейсами). В конце концов, модуль — маленький. 1-модуль : 1-программист. Несколько программистов в один и тот же модуль код никогда не пишут.
    Re[13]: Обновление
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 31.10.04 13:04
    Оценка: +2 :)))
    Здравствуйте, VladD2, Вы писали:

    VD>Совсем согласен. Но все же когда язык или среда подталкивают все же лучше. Не все же программисты супер-ассы. Да и ассы в запарке лажу гонят.


    Влад, сколько можно говорить — асс это задница.
    ... << RSDN@Home 1.1.4 beta 3 rev. 216>>
    AVK Blog
    Re[19]: Обновление
    От: Sergey J. A. Беларусь  
    Дата: 01.11.04 07:48
    Оценка: +1 :))) :)
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Я неоднократно указывал на то что обероны, еще со времен Модулы, являются модульными языками. Но тут, видимо, никто не понимает что это такое. Вот и Вы тоже туда же. Не понимаете в чем состоит преимущество модульности... С модулями не возникает проблем контроля версий. Новому модулю дается новое имя (так же как с COM-интерфейсами). В конце концов, модуль — маленький. 1-модуль : 1-программист. Несколько программистов в один и тот же модуль код никогда не пишут.


    Круто.... Меня эти откровения так втыкают
    Я — свихнувшееся сознание Джо.
    Re[22]: Обновление
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 01.11.04 17:03
    Оценка: :))) :))
    Здравствуйте, Mamut, Вы писали:

    M>Опять же, повторюсь: Почему среды разработки Турбо Паскаль/Турбо С лучше Блэкбокса
    Автор: Mamut
    Дата: 01.11.04

    Не, ты не понял. Основной принцип Вирта — "Тяжело в учении, легко в бою". Например, его стремление изничтожить дебаггер за то, что он видишь ли поощряет ленивых программистов, говорит именно об этом. Он хочет, чтобы программер всегда проигрывал логику метода в уме, а где надо — строил ассерты. С его логикой довольно трудно спорить — она сродни логике армейского сержанта. Это прикладных товарищей из коммерческого мира интересуют исключительно вопросы снижения входной планки в индустрию, поэтому они продвигают "рюшечки для инвалидов" типа визуального проектирования, код комплишна, подсветки синтаксиса и прочие пошаговые отладчики. Армейский сержант наборот — будет класть всех мордой в грязь и будить посреди ночи. Зато те, кто выживут — вот те будут кодить правильно просто на уровне рефлексов. Угу. Я, кстати, не понимаю, почему это он не поставил ограничение на частоту компиляции. Нефиг! Ведь это стимулирует написание кода кое-как — фигня, компилятор поправит. Потом тупо берем и бездумно подавляем каждое сообщение компилера. Не хватает скобки — на тебе скобку. Не определен Irerator — доопределим ирератор. Очень это подозрительно. Должно быть так: запускаешь проект на компиляцию — и тебе компилер выкидывает типа удалось/не удалось. А чтобы понять, где не удалось — фтыкаешь через нужный интервал прагму, которая коммент емиттит в аутпут. А потом читаешь листинг компилера — и догадываешься, что типа докуда докомпилялось. Угу.

    В общем, я зверств-то не хуже Вирта могу попридумывать.
    Вот только некоторые вещи в нашей индустрии совершенно неочевидны. И глупо думать, что один человек, даже самый гениальный, придумает решения всех проблем. Не существует пророков, на которых надо молиться. Как и серебряных пуль. Вирт — просто пожилой человек, со своими (местами оригинальными) взглядами на программирование вообще, и на его преподавание в частности. Надо понимать, что темпы развития технологий таковы, что разработки десятилетней давности могут скорее повредить, чем помочь. Знаете, как смешно читать рассуждения спецов по UI образца 1991 года? Интернет совершенно перевернул многие концепции. То, что прошло проверку временем — остается. Но экспериментальные разработки тем и экспериментальные, что могут оказаться тупиками.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[27]: Мэйнстрим vs. Самосовершенствование :)))
    От: Павел Кузнецов  
    Дата: 01.11.04 18:55
    Оценка: 43 (3) +1
    VladD2:

    > ПК> Ерунда. Разговор был о наличии конкретной функции sort() в интерфейсе конкретного класса Array.


    > И что в этом есть проблемы?


    Да, конечно. Они уже были перечислены. Кратко: размещение вспомогательных функций в виде членов класса требует последующих модификаций класса при добавлении очередных вспомогательных функций.

    > ПК> Напротив, это ты перешел к навязыванию такого расположения функции sort(),

    >
    > Примеры, пожалуйста. А без них будем считать твои слова ... ну, корече ты понял.

    INTP_mihoshi сказал
    Автор: INTP_mihoshi
    Дата: 27.10.04
    :

    VD>И кстати, что тебе не нравится в Шарпе с точки зрения ООП?

    То же, что и в Яве, то, что в нем объектом приходится делать даже то, что объектом не является.

    (как мы уже выяснили
    Автор: INTP_mihoshi
    Дата: 28.10.04
    , он немного неточно выразился, и имел в виду не объекты, а классы)

    Sinclair (http://rsdn.ru/forum/?mid=870335):
    Автор: Sinclair
    Дата: 27.10.04

    Во как интересно. Например, что?


    Т.к. я испытываю тот же дискомфорт, что и INTP_mihoshi, я привел
    Автор: Павел Кузнецов
    Дата: 28.10.04
    конкретный пример такого "класса", который классом быть не должен, а должен был быть namespace:

    Например, я не вполне понимаю, зачем обобщенные алгоритмы типа сортировки делать методами классов Вот пример такого, с позволения сказать, класса: http://java.sun.com/j2se/1.4.2/docs/api/java/util/Arrays.html — ни состояния, ни поведения, ни инвариантов


    На что ты бросился в бой
    Автор: VladD2
    Дата: 29.10.04
    , причем, споря совершенно о другом:

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


    Как видишь, это замечание совершенно не в тему, т.к. в примере, который я привел (java.util.Arrays) ничего при нажатии на точку не выскочит. Единственная претензия, которая была у меня к приведенному примеру — использование "класса" не по делу, там где по всему видно, что должен был быть namespace, о чем я и написал
    Автор: Павел Кузнецов
    Дата: 29.10.04
    . О помещении sort() в класс Array, как ты это подразумевал в своем сообщении, я только сказал, что это вопрос спорный, и привел основание против таких действий: нарушение некоторых из принципов ООП.

    Далее ты начал начал говорить о том, что вынесение sort() за пределы класса Array нарушает инкапсуляцию и т.п. И хотя это уже просто чистой воды ерунда, я все-таки продолжил с тобой разговор. Сейчас вижу, что совершенно зря, т.к. мы говорим на разных языках. Буду рад обнаружить, что я не прав, и ты способен продолжать дискуссию в нормальном тоне.
    Posted via RSDN NNTP Server 1.9 gamma
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[13]: Мэйнстрим vs. Самосовершенствование :)))
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 02.11.04 06:06
    Оценка: 43 (2) +2
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Например, я не вполне понимаю, зачем обобщенные алгоритмы типа сортировки делать методами классов Вот пример такого, с позволения сказать, класса: http://java.sun.com/j2se/1.4.2/docs/api/java/util/Arrays.html — ни состояния, ни поведения, ни инвариантов

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


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

    По поводу свободных процедур у меня возникают некоторые сомнения. Дело в том, что с точки зрения ООП все должно быть объектом. Я бы выделил методы типа Sort в специальные объекты, реализующие некоторые алгоритмы. Примерно так:
    public interface ISort {
      public ISequentiallyAccessibleCollection Sort(IArbitraryAccessCollection source);
    }

    Таким образом, мы изолировали требования к алгоритму от его реализации. Теперь мы можем предоставлять пользователю классы алгоритмов, которые возможно требуют дополнительной инициализации:
    public class HeapSort: ISort {
      public HeapSort(); // инициализация не нужна
      public ISequentiallyAccessibleCollection Sort(IArbitraryAccessCollection source);
    }
    public class QuickSort: ISort  {
      public QuickSort(); // инициализация не нужна
      public ISequentiallyAccessibleCollection Sort(IArbitraryAccessCollection source);
    }

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

    Теперь по поводу размещения утилитных методов. Владу не понравится ни решение с объектами алгоритмов, ни со статик методами утилитных классов. Потому как он хочет объектно-ориентированного интерфейса разработчика, т.е. "тыкая" в объект мы сразу поняли, что с ним можно делать. Либо через броузер, либо code completion... В некоторых случаях это может быть даже оправдано. Ну, вот к примеру наш гипотетический ISort всегда пользуется IArbitraryAccessCollection. Было бы здорово, если бы мы могли как-то найти все эти алгоритмы, глядя на какой-нибудь int a[4000]. Увы, пока что это не представляется возможным. Я вижу два варианта:
    1. Изменить язык и дать возможность вносить фиксированные реализации методов в интерфейсы. Хотя бы статиков. Тогда мы могли бы записать все, что нам нужно, в интерфейс для source, и жить себе не тужить.
    2. Оставить язык в покое и сделать более продвинутый редактор. Например, при помощи атрибутов расширять CodeCompletion. Примерно так:
      public class Algorithms{
      [ExtendCodeCompletionFor(typeof(IArbitraryAccessCollection))]
      public static ISequentiallyAccessibleCollection HeapSort(IArbitraryAccessCollection source);
      [ExtendCodeCompletionFor(typeof(IArbitraryAccessCollection))]
      public static ISequentiallyAccessibleCollection QuickSort(IArbitraryAccessCollection source);
      }
    И когда мы нажимаем Ctrl-Space на b = a, редактор помимо родных методов для int[] высвечивет также и Algorithms.QuickSort и Algorithms.HeapSort. При их выборе в код вставляется соответствующий вызов. В данном случае предложено как раз джаваподобное решение, которое конечно же косяк, но я привел его только для полноты ощущений. Подумав, можно научить редактор жить и с кодом из первой части — когда функциональность реализуют именно объекты.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Интерактивный режим питона
    От: eugals Россия  
    Дата: 24.10.04 10:55
    Оценка: 27 (3) :)
    Здравствуйте, VladD2, Вы писали:

    VD>Еще раз. Нет проблем сделать снипит-компилятор скроющий все детали.

    Питоновский интерактивный режим простым снипит-компилятором не взять.
    Он вот что умеет:
    >>> a = 1
    >>> b = "строка"
    >>> # - вот ребята, сейчас мы с вами объявили свои первые переменные
    >>> # давайте посмотрим, добавились ли они в глобальную область имен:
    >>> dir()
    ['__builtins__', '__doc__', '__name__', 'a', 'b']
    >>> # - Видите! Добавились!
    >>> # Обратите внимание, что кроме наших переменных в ней уже присутствовали 
    >>> # несколько встроенных системных имен.
    >>> # Ну, что такое __name__ и __doc__ я вам рассказывал на предыдущм занятии,
    >>> # а сейчас давайте посмотрим на __builtins__ - это модуль содержащий все 
    >>> # встроенные функции и переменные.
    >>> # Давайте посмотрим, что он содержит:
    >>> dir(__builtins__)
    ['ArithmeticError', 'AssertionError', 'AttributeError', 'DeprecationWarning', 'E
    OFError', 'Ellipsis', 'EnvironmentError', 'Exception', 'False', 'FloatingPointEr
    ror', 'FutureWarning', 'IOError', 'ImportError', 'IndentationError', 'IndexError
    ', 'KeyError', 'KeyboardInterrupt', 'LookupError', 'MemoryError', 'NameError', '
    None', 'NotImplemented', 'NotImplementedError', 'OSError', 'OverflowError', 'Ove
    rflowWarning', 'PendingDeprecationWarning', 'ReferenceError', 'RuntimeError', 'R
    untimeWarning', 'StandardError', 'StopIteration', 'SyntaxError', 'SyntaxWarning'
    , 'SystemError', 'SystemExit', 'TabError', 'True', 'TypeError', 'UnboundLocalErr
    or', 'UnicodeDecodeError', 'UnicodeEncodeError', 'UnicodeError', 'UnicodeTransla
    teError', 'UserWarning', 'ValueError', 'Warning', 'WindowsError', 'ZeroDivisionE
    rror', '_', '__debug__', '__doc__', '__import__', '__name__', 'abs', 'apply', 'b
    asestring', 'bool', 'buffer', 'callable', 'chr', 'classmethod', 'cmp', 'coerce',
     'compile', 'complex', 'copyright', 'credits', 'delattr', 'dict', 'dir', 'divmod
    ', 'enumerate', 'eval', 'execfile', 'exit', 'file', 'filter', 'float', 'getattr'
    , 'globals', 'hasattr', 'hash', 'help', 'hex', 'id', 'input', 'int', 'intern', '
    isinstance', 'issubclass', 'iter', 'len', 'license', 'list', 'locals', 'long', '
    map', 'max', 'min', 'object', 'oct', 'open', 'ord', 'pow', 'property', 'quit', '
    range', 'raw_input', 'reduce', 'reload', 'repr', 'round', 'setattr', 'slice', 's
    taticmethod', 'str', 'sum', 'super', 'tuple', 'type', 'unichr', 'unicode', 'vars
    ', 'xrange', 'zip']
    >>> # - Воо-о-от. Постепенно мы с вами изучим, что все они означают.
    >>> # Начнем, пожалуй, с функции dir(), которую я только что использовал.
    >>> # Давайте помотрим, что нам скажет про неё другая встроенная функция (help)
    >>> help(dir)
    Help on built-in function dir:
    
    dir(...)
        dir([object]) -> list of strings
    
        Return an alphabetized list of names comprising (some of) the attributes
        of the given object, and of attributes reachable from it:
    
        No argument:  the names in the current scope.
        Module object:  the module attributes.
        Type or class object:  its attributes, and recursively the attributes of
            its bases.
        Otherwise:  its attributes, its class's attributes, and recursively the
            attributes of its class's base classes.
                    
    >>> # ну и т.д.
    ... << RSDN@Home 1.1.4 @@subversion >>
    Почему бинарные исходники - плохо
    От: Mamut Швеция http://dmitriid.com
    Дата: 29.10.04 13:35
    Оценка: 5 (3) +1
    По-моему, это очевидно, но все же...

    1. Как бы мы не крутили, а исходники все равно читает и редактирует человек. Если исходник — текстовый файл, то неважно, чем он пользуется. Для Винды — это Блокнот (Notepad), Word, MS Word, или например Dreamweaver. У меня был случай, когда редактировал код на PHP в Delphi, потому что под рукой не было другого редактора, сохраняющего отступы при переводе строки.

    Что отсюда следует? Легкость в использовании. Пример: Как бы ни были хороши были документы в формате PDF или doc, а для их чтения и редактирования нужен специальзированный вьюер/редактор. С другой стороны, несмотря на то что мне выпала возможность работать с библиотекой Qt, я иногда просматриваю ее исходники в блокноте — и ничего.

    2. Текстовый формат = доступность средств для разработки. Любому компилятору, разрабатываему даже энтузиастами-студентами не надо будет дополнительно разбираться в неком проприетарном формате. Вдобавок, не надо будет дополнительно отделять зерна от плевел (код от ресурсов от контролей и форм).

    3. Текстовый формат как защита от дурака. Предположим, вы напортачили что-либо в коде. Или нафиг выбило пробки из-за сварщиков на третьем этаже.

    В случае текстового формата попорченный файл открывается любым из перечисленных выше средств, находятся ошибки и неправильные символы, все работает. В случае бинарного формата все полетит нафиг. Редактор в жизни не откроет файл, в котором в ключевом месте стоит 1 вместо 0.

    История из жизни. Опять Qt, компиляция. Компьютер вылетает нафиг, при перезагрузке файл WinNT.h оказывается попорчен, часть символов заменена контрольными символами < 32 ASCII. Как назло, поблизости не было SDK и пришлось эти самые символы вправлять ручками. 5-10 минут и компиляция пошла дальше. А если бы тот файл был бинарным?

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

    Опять же, из жизни. Надо было в проекте в Builder'e заменить все компоненты TButton на TCoolButton. Find&Replace в заголовочных файлах и Find&Replace в *.dfm. Вуаля! С бинарниками такое не прокатит.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>


    dmitriid.comGitHubLinkedIn
    Re[30]: Мэйнстрим vs. Самосовершенствование :)))
    От: prVovik Россия  
    Дата: 01.11.04 17:10
    Оценка: 4 (3) +1
    Здравствуйте, prVovik, Вы писали:

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


    AVK>>О! Осталось только понять что многие алгоритмы сортировки требуют доступа к внутренним структурам

    V>Вот для контейнеров, сортировка которых действительно требует доступа к внутренней структуре ее, конечно, надо делать внутренним методом.
    V>Для всего остального подойдет внешний обобщенный алгоритм сортировки типа std::sort()

    Добавлю также, что если интерфейс контейнера позволяет реализовать алгоритм без обращений к внутренней структуре и без значимых потерь в производительности, то этот алгоритм надо делать внешним, а не добавлять его в интерфейс.
    ... << RSDN@Home 1.1.4 @@subversion >>
    лэт ми спик фром май харт
    Re[5]: арифметические, логические, бинарные
    От: eugals Россия  
    Дата: 21.10.04 07:28
    Оценка: 3 (1) :)))
    Здравствуйте, Сергей Губанов, Вы писали:


    СГ>Ну, чтобы уж совсем не отрываться от действительности
    Оговорка по Фрейду
    ... << RSDN@Home 1.1.4 beta 2 >>
    Re[12]: Oberon???????????????????????????????????
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 26.10.04 11:16
    Оценка: 2 (2) +1 :)
    Здравствуйте, Sinclair, Вы писали:

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

    MODULE MyModule;
    
    IMPORT StdLog;
    
    BEGIN
      StdLog.String("Здравствуй мир!");
    
    END MyModule;


    S>И чем же этот хрен слаще вот такой редьки:

    using System;
    class Class1
    {
        static void Main()
        {
            Console.WriteLine("Hello World");
        }
    }



    Лучше тем что использовано меньше понятий, судите сами:

    Оберон:

    1) Существуют модули
    2) Один модуль может импортировать другой модуль
    3) В модулях есть подпрограммы, которые можно вызывать из других модулей

    C#:

    1) Существуют пространства имен (уже непонятность — а что, собственно, еще за пространство да еще и имен? Где они расположены? А как они выглядят эти пространства?)
    2) Существуют классы (еще одна непонятность — что еще за классы? Классы чего? Мы в седьмом классе учимся и что с того?)
    3) У классов есть статические методы (опять ребенку непонятно что такое статические и что такое методы, в чем разница между подпрограммами и методами?). Что такое void? Почему именно Main?
    4) Как понять что Console как-то связана с приведенной выше using System;
    Re[2]: Oberon???????????????????????????????????
    От: Kluev  
    Дата: 20.10.04 12:33
    Оценка: +4
    V>Здравствуйте, LaptevVV, Вы писали:

    На питоне надо новичков учить. Прост как три копейки и в командном режиме может работать как калькулятор.
    Более того в джаве только классы, а в питоне можно и с функций начать.
    Re[9]: Обновление
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.10.04 13:01
    Оценка: +3 :)
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Частная инициатива пытающаяся влиять на государство с целью того, чтобы в средней школе информатику преподавали на основе языка Component Pascal в среде BlackBox.


    Ясно. Будем надеяться оно не поддастся.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[12]: Обновление
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 29.10.04 08:03
    Оценка: -3 :)
    Здравствуйте, VladD2, Вы писали:

    VD>Существенный недостаток есть. Язык не применим на практике. Он мертв. И учить на нем детей — значит обрекать их на дополнительное самообучение с переламыванием себя.


    Я уже не раз указывал Вам на Вашу некомпетентность в этом вопросе. Но Вы продолжаете повторяться вновь и вновь.
    Re[16]: Обновление
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 31.10.04 07:25
    Оценка: :))) :)
    Здравствуйте, VladD2, Вы писали:

    VD>Ага. Вместо того чтобы сделать подсветку синтаксиса.



    Нужна — сделай сам. Все в твоих руках. Система открытая.
    Re[13]: Oberon???????????????????????????????????
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 24.10.04 10:39
    Оценка: 13 (2) +1
    Здравствуйте, VladD2, Вы писали:
    VD>Не дай бог.
    Поздняк метаться. C# 2.0 already came.

    VD>Где бы нарыть смайлик плюющий через плече и рестящийся?


    VD>В общем, за такое нужно
    Помяни мои слова, Влад, через год ты сам будешь приводить подобные тексты в битвах с апологетами конкурирующих платформ
    Конечно же, данный конкретный пример плох. По крайней мере нам с тобой легче читать именно
    foreach(int each in Range(1, 10))
    {
      Transcript.Show(each);
    }

    Но вот развитие идей разделения генерации последовательностей и их обработки неизбежно приводит к чему-то типа:

    public void PrintNonDividable(Range r, int divisor)
    {
       Print(r.Filter(delegate(int item){return (item % divisor) != 0;}));
    }

    Что, имхо, гораздо лучше чем
    public void PrintNonDividable(Range r, int divisor)
    {
      Range r2 = new Range();
      foreach(int item in r)
        {
          if ((item % divisor) != 0)
              r2.Append(item);
        }
      Print(r2);
    }

    И лучше по двум основным причинам:
    1. Меньше строчек — меньше ошибок.
    2. Можно оперировать бесконечными (или очень длинными) последовательностями значительно оптимальнее. Этот Range запросто может быть генератором, а не коллекцией. Наложение Filter на него совершенно не обязательно вынуждает немедленно получить другую коллекцию. Собственно, yield-инг результатов (возможно) начнется только на месте употребления. И все это мы имеем совершенно забесплатно.
    Цена этому — обучение программистов новой конструкции — анонимным методам.
    Получив в руки такой могучий инструмент, сразу хочется выкинуть все "лишнее". Ведь теперь нам собственно никакие управляющие конструкции не нужны — мы можем их эмулировать при помощи обычных методов
    Что такое If как не метод, принимающий булевый делегат и два воид-делегата?
    Цикл превращается в метод Apply у IEnumerable. Ну и так далее. Страшно, да?
    Вот к чему приводит стремление к "нормализации"! Сахар в языке — вещь полезная .
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[4]: арифметические, логические, бинарные
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 21.10.04 07:12
    Оценка: 8 (2) :)
    Здравствуйте, VladD2, Вы писали:

    VD>...Только логических операций лучше на нем не давать. Они в нем такие же кривые как в Паскле (бен разделения на бинарные илогические).


    Ну Вы опять говорите о Паскале имея в виду тот древний, который прямой потомок Алгола. В современном (от 1994 года) Component Pascal (тот который есть модифицированный Oberon-2) бинарных операций с числами нет вообще. Число — это математическая абстракция, программист не должен знать как она реализована на конкретной машине. Это делает язык переносимым между любыми архитектурами компьютеров. Для бинарных операций существует специальный тип данных — SET (множество). Множество — тоже математическая абстракция, и тут снова программист не должен знать как она реализована на конкретной машине. Для SET-ов реализованы все характерные для множеств операции (объединение, разность, пересечение, симметричная разность).

    Для логических операций, само-собой, предусмотрен тип BOOLEAN... думаю, излишне о нем что-либо рассказывать...

    И так, в современном Паскале (1) арифметические, (2) логические и (3) бинарные операции можно осуществлять только над соответствующими типами данных: (1) числовыми, (2) буллевым, (3) множествами. То есть, все безупречно purify! Для школьников и студентов — то что доктор прописал!


    P. S.
    Ну, чтобы уж совсем не отрываться от действительности, и иметь возможность использовать обероны в системном программировании, так уж и быть (хотя с точки зрения математики это и бессмысленно), предусмотрены инструкции конвертации чисел во множества, и множеств в числа:
    set     := BITS(integer);
    integer := ORD(set);

    при этом, разумеется, учитываются архитектурные особенности представления чисел на используемом компьютере, так что программа остается переносимой.
    Re[2]: Oberon???????????????????????????????????
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 21.10.04 07:33
    Оценка: 5 (1) +1 :)
    Здравствуйте, VladD2, Вы писали:

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


    VD>Оберон — это мертвях. Учить ему будущих программистов все равно что учить латыни будущих переводчиков. Неужели нехватает живых языков? Чем та же Ява или Шарп хуже?


    Оберон не мертвяк, то что Вы о нем ничего не знаете говорит о Вас и только о Вас.

    Ява и Шарп хуже Оберона тем, что Оберон проще, чище и меньше и в то же время он полный, в смысле, достаточный современный объектно ориентированный модульный императивный язык общего назначения со строгой статической типизацией и встроенными механизмами безопасности (проверка индексов, правильное приведение типов, сборка мусора).

    О превосходстве оберонов над Явой на ее родном поле боя — в интернете, можно почитать там:
    http://www.uni-vologda.ac.ru/oberon/

    Juice-технология

    Летом 1996 года профессором Калифорнийского университета в Ирвине, учеником Н.Вирта Михаэлем Францем и его аспирантом Томасом Кистлером была представлена технология распространения исполнимого кода в Интернет, названная авторами Juice (по-русски — сок). Juice основан на использовании Оберона и влючает с одной стороны инструментальную компоненту для Оберон-системы Oberon System 3, обеспечивающую компиляцию написанных на Обероне модулей в платформно-независимое представление. Второй частью Juice является дополнение (plug-in) к Интернет-браузерам, обеспечивающее компиляцию получаемого Juice-кода "на лету" в родной код, его загрузку и исполнение.

    Juice превосходит Java-технологию во всем кроме величины затрат на рекламу:

    1) Основан на более простом и совершенном языке
    2) Обеспечивает существенно большую скорость исполнения аплетов
    3) Код Juice-аплета компактнее байт-кода Java

    Re[5]: Oberon???????????????????????????????????
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 22.10.04 20:44
    Оценка: 1 (1) +2
    Здравствуйте, Serginio1, Вы писали:

    S> Ну зачем же. Я бы добавил еще и 1С!!!


    Точно 1Эс и всех в клинику. А еще лучше сразу молотком по голове чтобы не мучались.
    ... << RSDN@Home 1.1.4 beta 3 rev. 206>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[15]: Oberon???????????????????????????????????
    От: Kluev  
    Дата: 26.10.04 13:42
    Оценка: 1 (1) +1 :)
    Здравствуйте, Сергей Губанов, Вы писали:

    <поскипано>

    S>>Итак, пока что у нас Оберон — C# идут один-в-один, за исключением void. Во всем остальном паритет.

    СГ>А еще за исключением class, Main, static,...

    Зачем так жарко спорить когда питон уже всех "порвал" своей простотой
    Re[19]: Мэйнстрим vs. Самосовершенствование :)))
    От: Павел Кузнецов  
    Дата: 29.10.04 22:51
    Оценка: 1 (1) +2
    Здравствуйте, VladD2, Вы писали:

    ПК>> В том, что для добавления нового алгоритма (например, partial_sort, binary_search и т.п.), руководствуясь таким дизайном, будет нужно модифицировать определение класса.


    VD>Ужас какой? Хорошо хоть все эти алгоритмы уже лет дать как описаны.


    Прикол в том, что алгоритмы из Arrays нельзя применить к List или Deque, соответственно, при разработке последних придется создать Lists и Deques с тем же содержимым, что в Arrays. Плюс, когда окажется, что авторы Arrays не прописали давно изученный и описанный алгоритм в Arrays, надо будет этот "класс" модифицировать. А вслед за ним и Lists, и Deques.

    VD> Да и спасибо ООП.


    Одним из фундаментальных принципов которого является Open-Closed Principle. А запихивание всех подряд функций в тот или иной "класс", у которого нет никаких основных атрибутов (поведение, состояние, инварианты), к ООП никакого отношения не имеет.
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[22]: Мэйнстрим vs. Самосовершенствование :)))
    От: Павел Кузнецов  
    Дата: 30.10.04 05:29
    Оценка: 1 (1) +1 :)
    Павел Кузнецов:

    > Выход простой: тем или иным образом вынести эти "утилиты" за пределы самих классов.


    Кстати, забыл привести один яркий пример очень неудачного напихивания класса "утилитами", иллюстрирующий проблему еще с одной стороны: это шаблон класса стандартной библиотеки C++, std::basic_string<> (aka std::string, std::wstring).

    Куча "утилит", находящихся в этом шаблоне (find_first, find_last_of и т.п.), которые, очевидно, могли быть вынесены как "свободные" функции, плоха по, как минимум двум соображениям:
  • когда по тем или иным причинам приходится делать свой класс для замены std::basic_string, также приходится заново реализовывать в своем классе все эти "утилиты";
  • эти "утилиты" невозможно использовать для "строк" char*, а копировать полученную char* в std::string не всегда хорошо.
    Будь они "свободными" функциями, оперирующими с диапазонами итераторов, жизнь была бы намного легче.
    Posted via RSDN NNTP Server 1.9 gamma
  • Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[16]: Обновление
    От: KDelpher Россия  
    Дата: 02.11.04 09:16
    Оценка: 1 (1) +2
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, VladD2, Вы писали:


    VD>> Забавно. Работаешь на одном, а рекламирушь другое... Не находиш — это странным?


    СГ>Нахожу. А что делать? Не работать или не рекламировать? Тут и так не особо врубаются почему я на Дельфи пишу, а не на С++. А уж если я на БлэкБоксе на работе начну писать, то мне сразу скажут: "А что если ты когда-нибудь уволишься, то где мы найдем еще одного оберонщика чтобы сопровождать уже написанные программы?". А научиться — ни вкакую.


    Попробуйте сами обосновать точку зрения начальства. Это не подколка. Это и в самом деле ценный прием. Вы представляете себя на месте начальника и объясняете кому-то, почему предпочтительнее не переучиваться. Возможно, после этого позиция начальства станет понятнее. А так же, возможно, найдутся новые аргументы против позиции начальства. А когда этот внутренний диалог закончится, итог его можно уже выложить сюда. Что-то вроде игры в шахматы сам с собой. Когда твой противник — ты сам, то с одной стороны приходится отыскивать у себя самого наиболее слабые доводы и бить именно по ним. А со второй — эти слабые доводы приходится укреплять, а то и осознавать свои ошибки. Взгляните на проблему с обоих сторон.
    Re[5]: Oberon???????????????????????????????????
    От: Kluev  
    Дата: 21.10.04 07:35
    Оценка: +3
    Здравствуйте, VladD2, Вы писали:

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


    FR>>Я тоже думаю что питон очень хороший вариант для обучения.

    FR>>Тем более позволяет продемонстрировать все наиболее распрастраненые подходы к программированию и процедурное и функциональное и ООП и обобщенное программирование.
    FR>>У него только один недостаток динамическая типизация.

    VD>Я вот тут скачал книжку по Питону. Поглядел. Есть конечно в Питоне интересные решения. Но рельных приемуществ пред тем же шарпом нет. А вот недостатки вроде отсуствия типизации есть. Нормальный программист должен понимать что такое типы и статическая типизация.


    Я сам упертый Cpp-шник начинавший с паскаля (потом джава был, потом плюсы). Если бы я начал с нуля то начал бы именно с питона. Отсутсвие типизации на началном этапе это не минус а плюс. А чтобы оценить кайф скачай не книгу а среду. Учится можено прямо в интеракивном режиме плавно переходя от калькулятора к программированиюю Иеальный вариант чтобы обяснить все быстро и на пальцах. Вот пример

    # начали с калкулятора
    >>> 2+2
    4
    
    # перешли к функции
    >>> def sum(a,b) : return a+b
    
    # заюзали функцию
    >>> sum(2,2)
    4
    
    # теперь к классу:
    >>> class Summator:
        a = 0
        b = 0
        def sum(self):
            return self.a + self.b
    
    # сразу заюзали класс:    
    >>> s = Summator()
    >>> s.a = 1
    >>> s.b = 2
    >>> s.sum()
    3
    >>>
    Re[3]: Oberon???????????????????????????????????
    От: Obel  
    Дата: 21.10.04 11:24
    Оценка: -3
    СГ>1) Основан на более простом и совершенном языке
    Который сокращает время разработки? Васик еще проще и совершеннее.
    СГ>2) Обеспечивает существенно большую скорость исполнения аплетов
    Это не является приоритетной задаче для апплетов.
    СГ>3) Код Juice-аплета компактнее байт-кода Java
    Это не так важно в современном интернете.

    СГ>компиляцию получаемого Juice-кода "на лету" в родной код


    А вот одним из приоритетных направлений является безопасность. Скомпилировать и запустить в браузере
    что-то из инета? В родной код???
    Re[4]: Oberon???????????????????????????????????
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 21.10.04 13:25
    Оценка: -3
    Здравствуйте, Obel, Вы писали:

    СГ>>1) Основан на более простом и совершенном языке

    O>Который сокращает время разработки? Васик еще проще и совершеннее.

    Ну, вот, еще один "спец" нашелся. Утверждает что Васик проще и совершеннее Оберона.

    СГ>>2) Обеспечивает существенно большую скорость исполнения аплетов

    O>Это не является приоритетной задаче для апплетов.

    СГ>>3) Код Juice-аплета компактнее байт-кода Java

    O>Это не так важно в современном интернете.

    А Вы случаем не на компанию по производству компьютеров и коммуникаций работаете? Они очень заинтересованы в том чтобы людям надо было как можно более мощное и быстрое оборудование.


    СГ>>компиляцию получаемого Juice-кода "на лету" в родной код


    O>А вот одним из приоритетных направлений является безопасность. Скомпилировать и запустить в браузере

    O>что-то из инета? В родной код???

    Именно в родной код. Безопасность встроена в сам язык. В оберонистой программе никогда не бывает переполнения буфера (range index check). И Вам никогда не удасться что-то читать или писать по неправильному адресу, просто потому что в языке нет такого понятия как адрес, адресная арифметика, и самого адресного пространства как такового.
    Re[8]: Oberon???????????????????????????????????
    От: FR  
    Дата: 23.10.04 09:21
    Оценка: +2 -1
    Здравствуйте, serg_mo, Вы писали:


    FR>>по моему как тут уже сказали птичий язык

    _>Смолток действительно не похож на С-подобные языки. Тем не менее, анатомия языка чрезвычайно проста и подчиняется очень небольшому количеству правил, которые, так сказать, являются универсальными законами во вселенной Смолтока

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

    _>Вот, например, статья, в которой на 11 странцах, с щутками и прибаутками, с массой примеров, дано практически всеобъемлющее описание синтаксиса Смолтока. Используя информацию из этой статьи, пользователь сможет прочитать _любой_ код на Смолтоке, даже если не понимает, что этот код делает.


    А какой смысл читать код не понимая что он делает? Это примерно как выучить латинский алфавит и кричать что хорошо знаешь латынь?

    _>Возьмем для иллюстрации приведенный выше пример:

    _>
    _>1 to: 10 do: [:each | Transcript show: each]
    _>

    _>Что можно сказать, используя наши знания о синтаксисе:
    _>а) Имеет место посылка сообщения (или, по-другому, вызов метода) обьекта, стоящего крайним слева: 1.
    _>б) Вызывается метод to:do:, принимающий 2 параметра.
    _>в) Первый параметр, очевидно, число 10. Второй параметр сложнее. Допустим, я не знаю, что это, но я могу быть уверен, что это один из немногих специализированных конструкторов какого-то объекта. Почему я уверен? Да потому, что синтаксически альтернативы нет.

    _>И действительно, конструкция [] — это "синтаксически подслащенный" конструктор класа BlockClosure — блока. Блоки имеют фундаментальное значение в Смолтоке, поэтому, наряду с немногими другими (например, строками и массивами), для создания объектов этого класса есть специальная синтаксическая конструкция. В частности, с помощью блоков реализуются все управляющие конструкции (как в этом примере — цикл со счетчиком).


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

    _>Недостатком С-подобных языков, на мой взгляд, является то, что при их изучении приходится зазубривать огромное количество синтаксических конструкций и правил. Условные операторы — бац: кучка конструкций, циклы — еще одна кучка, арифметические операции — их приоритеты... Смолтокер, в свою очередь, может быть уверен, что синтаксические правила, данные в первой лекции (одной лекции будет вполне достаточно), универсальны, и сюрпризов его не ждет..


    Вот только мне кажется что ближе к человеческому мышлению как раз большое количество синтаксических конструкций как и в естественных языках.
    ... << RSDN@Home 1.1.3 stable >>
    Re[6]: Vlad2
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 26.10.04 08:28
    Оценка: -3
    Здравствуйте, VladD2, Вы писали:

    VD>Я вообще не пойму зачем вы пришли сюда? Посоветоваться? Дык вам дали совет не морочте демять голову Обероном в начале их пути. Но вы услышав почти однозначное осуждение своего мнения все равно проталкиваете свою идею.


    А Вы посмотрите вокруг, Вы один тут делаете нападки на Оберон, только Вы один вынесли "однозначное осуждение", остальные находятся либо в нейтралитете, либо не ведут себя так же агрессивно как Вы, либо перестали утверждать что либо по этому поводу так как не считают себя компетентными в этой области. Уважаемый LaptevVV даже заинтересовался вопросом преподавания Оберона первокурсникам, Kluev заинтересовался оператором WITH. А вот Вы VladD2 неоднократно были уличены в незнании вопроса о котором ведете речь, то есть именно своей некомпетентности в этом вопросе. Ваш последний пёрл на счет RETURN-на чего только стоит. Я мол на нем даже программировал давно, ля-ля, а как Вы на нем программировали, а из процедур RETURN ни разу значит не делали, упс... А теперь, значит, Вы спрашиваете зачем я пришел сюда. Это как понимать: форум RSDN и некий VladD2 это близнецы-братья? Чего я пришел на RSDN означает чего это я пришел к VladD2? Так чтоли? Раз я несколько раз ткнул Вас носом, то мне теперь и на RSDN ходить нельзя? RSDN — это форум, а Вы тут участник. Я пришел на форум, а не лично к Вам.

    VD>Точно такое же осуждение вы получили на королевстве дельфи.


    Да осуждение я там получил, вот такое:

    Почитал несколько веток с Вашим участием...
    У каждой такой "тусовки" есть своя специфика, со своим контИнгентом участников... RSDN в этом отношении — ярчайший и показательный пример. Волею судеб, я оказался вовлечён в работу харьковского семинара по QNX ( http://qnxclub.net ). Наиболее активный наш участник, Olej, захаживал как-то на RSDN, в ветки, посвящённые Юникс-системам и ОСРВ. То, с чем он там столкнулся (уровень знаний, информированность в "сопредельных с виндой областях", а главное — просто-таки параноидальная вера в собственную "правильность" и непогрешимость практически во всех поднимаемых на форуме вопросах), заставило Olej высказать несколько замечаний "по делу". С момента, когда RSDNовские ребята поняли, что их макают носиком в собственные примеры некомпетентности, нас забанили...

    В Вашем случае от них "аж прэ" не то, что не понимание поднимаемых вопросов, а нет даже желания вынырнуть из собственного мирка...
    Вот на это Вы и должны делать "поправку"...
    Вам разве не ясно, что они уже всё в этой жизни поняли? :о)

    Просто делайте своё дело. Всё остальное оно само сделает (и скажет) за Вас.

    http://www.delphikingdom.com/asp/talktopic.asp?ID=285
    Re[4]: Обновление
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 26.10.04 18:24
    Оценка: +1 -2
    Здравствуйте, VladD2, Вы писали:

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


    СГ>>Сегодня сайт проекта Информатика 21 был серьезно обновлен. Заходите смотрите.


    VD>А что у вас со стилем? Неужели нет людей со вкусом? Ну, такой ужасный попугай. Просто в глазах рябит.


    Так ведь, опять же, у Вас-то не спросили. Вот кабы спросили, то не рябило бы, а так вот что есть...
    Re[16]: Oberon???????????????????????????????????
    От: LaptevVV Россия  
    Дата: 27.10.04 06:34
    Оценка: +2 :)
    Здравствуйте, VladD2, Вы писали:

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


    LVV>>

    главный язык программирования — т.наз. C# — смоделирован во многом, в том числе и в отношении безопасности программирования, по образцу Оберона.

    LVV>>

    VD>Да тут ничего смешного то нет. И слова эти чистая правда. Шарп и Оберон действительно языки в которых типобезопасноать выведена на первое место. Разница межу ними только в том, что Шарп жив, а Оберон остался научным эксперементом. Как результат этого научного эксперемента тот же Шарп получил прекрасную систему типов и принцыпы работы с ними. Заслуга ребят из МС в том, что они сумели совместить удобство и типобезопасность.


    Не, заслуга ребят из MS только в том, что они из MS — был бы Вирт в MS, еще неизвестно, какой язык был бы живым, а какого даже в проекте не было б.
    С# жив только потому, что его не в академических кругах написали, а самая мощная корпорация — так с любым языком будет. Возьмется MS Oberon продвигать, и куда остальные с подводной лодки денуться?

    Потому и смешно.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[16]: Oberon???????????????????????????????????
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 27.10.04 08:50
    Оценка: :)))
    Здравствуйте, Sinclair, Вы писали:

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

    СГ>>Ну вот, правильно, типичный принцип сокрытия "сокровенных знаний"....

    СГ>>А разница между прочим на столько громадна, что даже не смешно. Перво-наперво надо объяснить КУДА писать исходный код программы. Модуль — это и есть то самое место куда надо писать исходный код программы, в том числе код классов надо писать внутрь модуля. Но Вы, будучи воспитанными на немодульных языках программирования, этого не знаете и код программы Вы пишите просто в текстовый файл.

    S>Гм. А можно критерии отличия текстовых файлов от модулей? А то я может, по незнанию, совсем не туда код-то пишу...

    Модуль — это самая большая структурная единица программы, содержащая внутри себя все остальные.
    Re[6]: Oberon???????????????????????????????????
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 28.10.04 14:47
    Оценка: :)))
    Здравствуйте, VladD2, Вы писали:

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


    S>> Ну зачем же. Я бы добавил еще и 1С!!!


    VD>Точно 1Эс и всех в клинику. А еще лучше сразу молотком по голове чтобы не мучались.

    Экий ты оказывается Враг Родины. Без 1С эконмика страны работать перестанет!!!!!
    Да и Больше НАС. И молотков столько не наберете
    и солнце б утром не вставало, когда бы не было меня
    Re[14]: Мэйнстрим vs. Самосовершенствование :)))
    От: Павел Кузнецов  
    Дата: 28.10.04 23:51
    Оценка: +2 :)
    VladD2:

    > ПК> Например, я не вполне понимаю, зачем обобщенные алгоритмы типа сортировки делать методами классов


    > Логично! Надо было воткнуть в массив метод нахождения косинуса. А в Мачь залить обобщенный поиск. Было бы по СТЛ-ному, и вообще по сишному.


    Нет, просто ни в какие классы эти функции не пихать, т.к. множество алгоритмов открыто, и, соответственно, помещение их в класс нарушает Open-Closed Principle.
    Posted via RSDN NNTP Server 1.9 gamma
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[17]: Обновление
    От: Кодт Россия  
    Дата: 29.10.04 11:29
    Оценка: +3
    Здравствуйте, Сергей Губанов, Вы писали:

    WF>> Что мы теряем


    СГ>А зато что приобретаем: *.odc — это хранилище сериализованных объектов в (бинарном виде) — так загрузите эти объекты и работайте с самими объектами, а не с текстом как таковым — уровень абстракции резко повышается.


    Значит, ты мало трахался с системами контроля версий.
    Там даже XML доставляет головную боль (а казалось бы, текстовый...)
    А тут — какой-то проприетарный бинарный формат.

    В редакторах явки, шарпа, да чего уж там — quick basic 4.5! — есть возможность структурированной работы с исходным кодом, как с совокупностью объектов языка: процедур, классов, метаинформации.
    http://files.rsdn.org/4783/catsmiley.gif Перекуём баги на фичи!
    Re[23]: Мэйнстрим vs. Самосовершенствование :)))
    От: Павел Кузнецов  
    Дата: 01.11.04 03:07
    Оценка: +2 -1
    VladD2:

    >>> Ну, а теперь представь, что кое-то на ООЯ пытается писать в ОО-стиле. Может они конечно и не удовлетворяют твоей концепции, но пользоваться плодами их трудов чертовски удобно.

    >
    > ПК>Это не "мои" концепции, это один из классических критериев качества объектно-ориентированного дизайна.
    >
    > Ты ее навязываешь, значит она твоя. К ОО-дизайну она в общем-то отношения не имеет.

    Я правильно понял, что ты утверждаешь, что Open-Closed Principle не имеет отношения к ОО дизайну? Если ты о чем-то другом, пожалуйста, сформулируй свою мысль яснее.

    > Более того. В твоем видение она даже становится вредной, так как отрицает базовые концепции вроде инкапсуляции.


    Это каким же образом? Как именно вынесение sort() за пределы Array нарушает инкапсуляцию?

    > ПК> Вопрос как раз в том, в какой степени та или иная функция принадлежит интерфейсу класса.

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

    Давай-ка ты подтвердишь это утверждение хоть какими-то ссылками на классику ООП. А то как-то не очень понятно, кому же эта функция должна...

    > Это не теории ООП. Это теория, которую ты пытаешься неверно применить. Включить все действия над объектом в его класс просто физически тяжело. К тому же некоторые действия могут затрагивать и другие объекты. Однако, требования инкапсуляции говорят о том, что желательно включать методы внутрь объекта.


    Нет, этого "требования инкапсуляции" не говорят. Впрочем, подозреваю, что ты просто можешь очень неточно выражать свои мысли. Чтобы была хоть какая-то ясность, насколько применимы "требования инкапсуляции" в твоей трактовке к классическим образцам дизайна, прокомментируй свое высказывание, процитированное выше, на некоторых из наиболее характерных в этом отношении design patterns: Command, State, Strategy, Visitor, Builder.

    Как же так получается, что (потенциальная) модификация объекта специально выносится за его пределы? Неужели все эти паттерны тоже нарушают инкапсуляцию?

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

    >
    > int AddMinutes(int time, int minutes)
    > {
    >     return time + minutes * 60;
    > }
    >


    Этот примерчик совсем в другую сторону, так как в данном примере отсутствие определенного интерфейса приводит к нарушению инвариантов воображаемого класса (он даже не выделен здесь явно). Вот это, действительно, нарушение инкапсуляции.

    > Внешние функции той же сортировки — это как раз такое нарушение.


    В случае сортировки никакие инварианты класса Array не нарушаются.

    > Ведь я потенциально могу применить функцию сортировки к объекту, который не должен поддерживать данного действия (метода). Так моя очередь или стэк может хранить данные в определенном порядке (смешно было бы, если это было бы не так!). Интерфейс этих классов походит для применения внешнего метода сортировки.


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

    > ПК> Плюс, разработчики готовы платить за поддержание всех наследников этих классов, что в больших проектах может обходиться достаточно дорого.

    >
    > "Может" — вряд ли должно являться критерием доказательства. С тем же успехом и безапелляционностью могу заявить, что грамотное проектирование иерархии наследования может существенно сократить затраты на поддержку больших проектов.

    Раздувание интерфейсов классов без необходимости противоречит грамотному проектированию.

    > Собственно в отличии от твоего заявления мое подтверждается теорией и практикой ООП.


    И теория, и практика ООП отлично подтверждают вред раздувания интерфейсов. Более того, даже название этому явлению придумали: "жирные" интерфейсы, interface bloat. Плюс сформулировали определенные критерии качества ОО дизайна, направленные на минимизацию обязанностей, и, как следствие, интерфейсов классов: Open Closed Principle (косвенно), Single Responsibility Principle, Interface Segregation Principle и т.д.

    > Опять таки заменим ярлык "утилиты", но подобающее название методы — и станет очевидно, что твои слова не более чем профанация идей ООП.


    Лозунги, лозунги...

    > ПК>Например, представим, что у нас есть скелет простенькой иерархии "библиотечных" контейнеров (псевдокод):

    > ПК>
    > ПК>interface Sequence<T>
    > ПК>{
    > ПК>   class Pos;
    >
    > ПК>   uint size();
    > ПК>   bool is_empty();
    >
    > ПК>   Pos begin();
    > ПК>   Pos end();
    > ПК>   Pos next(Pos);
    >
    > ПК>   Pos insert(Pos, T);
    > ПК>   void remove(Pos);
    > ПК>   void clear();
    > ПК>};
    >
    > ПК>interface RandomAccessibleSequence<T> : Sequence<T>
    > ПК>{
    > ПК>   T operator[](int index);
    > ПК>   Pos pos_by_index(int index);
    > ПК>};
    >
    > ПК>class List<T> : Sequence<T>
    > ПК>{
    > ПК>};
    >
    > ПК>class Array<T> : RandomAccessibleSequence<T>
    > ПК>{
    > ПК>};
    > ПК>

    >
    > ПК>Итак, мы хотим иметь возможность эти контейнеры сортировать. Допустим, мы решили добавить метод sort() в интерфейс Sequence<>.
    >
    > Не ожидал от тебя столько детский ошибок в таком простом варианте.

    Зато я ожидал различных эпитетов меня и моих действий

    > В описанной выше иерархии имеется класс RandomAccessibleSequence — это подразумевает, что ее предок не должен иметь средств прямого доступа к последовательности, а значит методы:

    >
    > Pos next(Pos);
    > Pos insert(Pos, T);
    > void remove(Pos);
    >

    > не имеют права находиться в этом классе.

    Все зависит от определения "последовательности". При этом наличие последовательности с произвольным доступом здесь совершенно ни при чем, т.к., скажем, даже односвязный список, не являясь последовательностью с произвольным доступом, отлично допускает итерацию начиная с произвольной позиции, равно как и удаление и добавление элементов в любую позицию, полученную путем итерации.

    > Более того. Под большим вопросом находится целесообразность размещения в последовательности методов:

    >
    > uint size();
    > bool is_empty();
    > Pos begin();
    > Pos end();
    >

    > так как они, например, не дают работать с последовательностями читаемыми по сети.

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

    > В общем, реализуют идиому последовательности с последовательным чтением грязно. Стало быть, довольно странно будет и применение к ней сортировки. <...> для классической последовательности с последовательным чтением метод сортировки вообще является нонсенсом.


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

    > Правильным дизайном <...>


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

    > Однако даже в таком виде это шедевр ОО-дизайна по сравнению с СТЛ которую ты тут защищаешь.


    Повторю: речь шла о библиотеке языка Java, и о том, где в ней находится функция сортировки массивов. Никакого отношения к STL это не имеет.

    > ПК>Некоторое время мы живем счастливо, но оказывается, что для некоторых задач принципиальным оказывается вопрос: сохраняет ли используемый алгоритм порядок "одинаковых" с точки зрения упорядочивания элементов. Ну, что ж, следуя заведенному порядку, нам будет нужно добавить метод stable_sort().

    >
    > ПК>Но как только мы подобным образом изменим интерфейс Sequence<>, все его наследники "сломаются", т.к. у них-то реализации stable_sort() не будет.
    >
    > Гы. Видимо это от безграмотного проектирования. Собственно об этом сказано выше.

    То же самое произойдет и если изменить изначальную иерархию на предложенную тобой. Просто попробуй добавить в нее функцию stable_sort(). Куда бы ты ее не добавлял, будут все те же проблемы, что описаны на оригинальном примере.

    > ПК> Кроме того, есть ли уверенность, что для всех "последовательностей" существуют эффективные методы их сортировки с сохранением порядка "одинаковых" с точки зрения упорядочивания элементов?

    >
    > [i]Паша, наделав таких детских ошибок в проектировании иерархии классов, ты задаешься столь не детскими вопросами. Может они не спроста сделаны? [/q]

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

    > Более того еще большой вопрос нужно ли вводить метод сортировки в последовательность не обеспечивающую прямой доступ.


    Такие классические абстрактые типы данных как списки не имеют прямого доступа по индексу, и, тем не менее, для них существует давно проработанные алгоритмы сортировки.

    > ПК> Однако на этом наши приключения не заканчиваются: ведь у пользователя, в его наследнике Array<>, уже могла быть своя stable_sort(), обладающая несколько иной семантикой, и эта функция "перекроет" определенную в Array<>. В таком случае новые функции, принимающие Array<>, и предполагающие соответствие семантики stable_sort() той, что заявлена в Array<>, правильно работать не будут.

    >
    > Хочу тебя расстроить. Этот случай никакого отношения к "утилитам", как ты изволил выразиться, не имеет. Введение любого нового метода чревато подобными проблемами.

    Поэтому существует такая вещь, как Design by contract, подобные трюки запрещающая, а также давным давно сформулирован Open-Closed Principle, который уже упоминался. Судя по всему ты так и не удосужился с ним ознакомиться. А гласит он, что в частности классы по возможности следует проектировать так, чтобы в дальнейшем их не модифицировать, а только расширять поведение, пользуясь их интерфейсом, наследованием и добавлением новых сущностей, с данными классами взаимодействующими.

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

    > максимум что мы получим — это варнинг (в Шарпе и ничего в C++), который успешно уберем за пару минут.


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

    > Реализовав подобные методы как статические ты так же можешь нарваться на перекрытие.


    Интересно, как это ты нарвешься на "перекрытие", если stable_sort() была реализована "внешней" функцией, определенной в namespace или классе пользователя, а ты добавил новую внешнюю функцию, в своем, "библиотечном", namespace? Приведи пример, а то, похоже, я тебя уже окончательно перестал понимать...

    > ПК>Выход простой: тем или иным образом вынести эти "утилиты" за пределы самих классов. <...>


    > Вывод неверный. Думаю, мои комментарии это хорошо продемонстрировали.


    Твои комментарии если что и продемонстрировали, то совсем не это.

    > При создании методов нужно соблюдать принципы: инкапсуляции, полиморфизма


    "Без базара, сахар белый". Жаль только, что никакого отношения к обсуждаемому вопросу это не имеет.
    Posted via RSDN NNTP Server 1.9 gamma
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[36]: Component Pascal
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 01.11.04 12:23
    Оценка: :)))
    Здравствуйте, WolfHound, Вы писали:

    СГ>>АКТИВНЫЕ ОБЪЕКТЫ,

    WH>А чем оно лучше потоков?

    Потоки — это чуждая (внешняя) для ОО сущность.
    Re[23]: Oberon???????????????????????????????????
    От: faulx  
    Дата: 17.11.04 06:58
    Оценка: +3
    F>> Всплывающая подсказка — не свойство языка.

    VD>От части свойство. Где ты видел подсказки на встроенные операторы? К тому же тут рассматриваются два конкретных случая. Так есть по факту. И думать, что там гипотетически возможно просто бессмысленно.


    Еще раз, медленно. Исходное сообщение звучало так:

    VD> Все эти х[3:5] долеко не очевидны. Они требуют объяснения на пальцах. А вот x.substring(3, 5) как раз можно понять и без объяснения.


    Факт заключается в следующем. Я увидел эту фразу, в которой приводились два примера синтаксиса. На для первого, ни для второго примера мой веб-браузер не выдал мне никакой всплывающей подсказки. Далее, в фразе приводилось общее утверждение, что синтаксис х[3:5] не очевиден, а x.substring(3, 5) — очевиден. Это утверждение вступило в противоречие с моим первым интуитивным представлением (совершенно объективным, поскольку меня не интересуют судьбы Питона, и этого синтаксиса Питона я тогда не знал). Этот факт показался мне, во-первых, достаточно забавным, чтобы обнародовать его, а во-вторых, опровергающим общность утверждения исходной фразы (поскольку имеется, по крайней мере, одно исключение).

    VD>Очень разумно. Только это убдет частный случай. А вот высказывание "Шарп более прост в освоении нежели Оберон так как по Шарпу есть огромное комьюнити." как раз очень даже верно.




    F>> Давай поставим языки в равные условия: пусть тексты программ на них напечатаны на бумаге без всяких подсказок, раскраски синтаксиса и т.п.


    VD>Да. Давай доведем все до состояния сферического коня в вакуме и начнем утверждать все что захотим. Вот только зачем? Есть реальная сисуация. От абстрактных размышления она не изменится. По факту для методов Шарпа, Явы, ВБ подсказки есть. А для Питона нет. И вряд ли когда появятся подсказки для встроенных операторов. Так что понимать их совершенно невозможно. Их можно только заучивать.


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

    F>>Я не говорил про написание (тем более в "средах"), а только про чтение с листа.


    VD>И где же ты читаешь код с листа?


    В данном конкретном случае — в веб-браузере. Еще я читаю код с листа в



    F>> Следовательно, существуют люди, которым это понятнее. Следовательно, нельзя говорить, что запись x[3:5] менее интуитивно понятна для всех. Следовательно, интуитивная понятность — субъективное понятие. Что и требовалось доказать.


    VD>Я вообще не понимаю как можнов ести речь о интуитивной понятности частного синтаксиса.


    А "интуитивная понятность" — это то же самое, что "очевидность" и "понятность без объяснения"? Тогда этот вопрос лучше задать самому себе, поскольку, повторяю, было сказано:

    VD> Все эти х[3:5] долеко не очевидны. Они требуют объяснения на пальцах. А вот x.substring(3, 5) как раз можно понять и без объяснения.
    Re[28]: Мэйнстрим vs. Самосовершенствование :)))
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 03.11.04 11:01
    Оценка: 57 (2)
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Сортировка не является основной функциональностью SomeList


    Вопрос спорный. Не стоит кидаться в крайности. Затаскивание всего в класс глупо и сложно поддерживаемо. Но ровно так же глупо следование принципам до конца — многие вещи неразрывно связаны с контейнерами, выносить их наружу неудобно, поскольку усложняет структуру библиотеки. Осюда оптимальным является некоторое среднее решение, когда часто используемые и семантически (прошу обратить внимание, семантически, а не формально) неразрывно связанные вещи вносятся в класс, а более отдаленные выносятся наружу.
    Пример из дотнета — подсистема, о которой уже неоднократно здесь упоминалось, но исключительно по ее кусочкам, без знания картины в целом. Подсистема преобразования типов.
    Преобразования большинства примитивных типов из строки присутствуют ввиде статических методов в интерфейсах самих типов, преобразование объекта в строку вобще является методом общего корня всех объектов. Это первый, самый жесткий уровень, поскольку преобразования из строки/в строку используются очень часто. Заметь, признак неформальный, формально строка среди всех прочих типов ничем не выделяется. При том всем прекрасно понятно что фактически строка является важнейшим способом представления данных для человека, и некий оверхед по наличию преобразований вполне оправдан.
    Следующий уровень, менее жесткий — преобразования некоего набора типов между собой. Набор этот выведен исходя опять же из фактического набора неких базовых типов, применяющихся очень часто.
    bool
    byte
    char
    DateTime
    decimal
    double
    short
    int
    long
    sbyte
    single
    string
    Type
    ushort
    uint
    ulong

    Типы эти между собой конертируюся классом Convert и преобразуются при помощи интерфейса IConvertible. Набор этот частично можно расширить, реализовав IConvertible в собственном классе.
    Наконец самый гибкий, но притом и самый сложный способ преобразования — механика, предоставляемая TypeDescriptor — специализированные классы, наследники TypeConverter. Эта механика предоставляет возможность преобразования произвольных тппов между собой.
    Итого мы имеем трехуровневую систему преобразований, гибкую и удобную одновременно, свободную от недостатков обоих крайностей. Для обучения(вспоминая исходную тему обсуждения) это конечно не зашибись, зато обалденно удобно.

    ПК>Есть множество аналогичных алгоритмов, которые нужны пользователю


    См. выше.

    ПК>Повторное использование алгоритмов


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

    ПК>Расширяемость множества алгоритмов


    ПК>Это важный момент, и хотя он связан с предыдущими пунктами, он стоит отдельного упоминания.


    ПК>Если предполагается, что добавление подобных алгоритмов непосредственно в интерфейс класса — желаемый образ действий, то расширять используемый набор алгоритмов для пользователя становится достаточно тяжело, т.к. все обертки/переходники, предназначенные для расширения функциональности, требуют усилий по сопровождению, и не всегда покрывают все необходимые сценарии использования.


    ПК>Никаких из этих проблем не возникает, если "вспомогательные" алгоритмы (то есть не основные для самого класса, в данном случае SomeList) будут вынесены за пределы класса.


    Опять то же самое — ты подменяешь проблемы интерфейсов проблемами реализации.
    ... << RSDN@Home 1.1.4 beta 3 rev. 219>>
    AVK Blog
    Re[11]: Oberon???????????????????????????????????
    От: eugals Россия  
    Дата: 25.10.04 06:40
    Оценка: 30 (2)
    Здравствуйте, VladD2, Вы писали:

    VD>Сам шарп почити без гаглядывания. Описание классов и методов конечно приходилось смотреть. Ну, разные редко используемые аспекты вроде синтаксиса операторов пришлось подсмотреть. Но со Смолтоком не сравнить. В гем я несколько часов к ряду смотрел на среду как баран на новые ворота, так ничего и не понял.

    Это да . К счастью, у _vovin-а на сайте есть пара интересных howto по Dolphin-у: Dolphin Smalltalk, Part I и Dolphin Smalltalk, Part I.
    Очень помогают от барановоротного эффекта
    ... << RSDN@Home 1.1.4 beta 2 >>
    Re[9]: Oberon???????????????????????????????????
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 21.10.04 13:16
    Оценка: 25 (2)
    Здравствуйте, FR, Вы писали:

    FR>#$%^&*^*((*&&((?


    Тулзень есть такая, которая позволяет просто выполнять код на шарпе. http://www.sliver.com/dotnet/SnippetCompiler/
    ... << RSDN@Home 1.1.4 beta 3 rev. 206>>
    AVK Blog
    Re[18]: Мэйнстрим vs. Самосовершенствование :)))
    От: FR  
    Дата: 28.10.04 14:10
    Оценка: 17 (1) +1
    Здравствуйте, VladD2, Вы писали:


    VD>Руби — это один из самых интересных исследовательских языков программирования созданных за последнее время. Я сам его не видел, но часто слышал как его приводят в пример. Ктому же именно его так никто толком и не описан на русском (вроде).


    Тут http://devlink.crimea.ua/articles/article.php?article_id=20 краткое описание.
    Вообще Ruby в общем конкурент питона, но по моему синтаксис у него менее понятный, и он ближе к функциональным языкам.
    ... << RSDN@Home 1.1.3 stable >>
    Re[11]: Мэйнстрим vs. Самосовершенствование :)))
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 26.10.04 00:03
    Оценка: 9 (2)
    Здравствуйте, Зверёк Харьковский, Вы писали:

    ЗХ>ЗЫ: А вот Шарп — он расширяет сознание, как по-твоему?


    Шап — это конечно не вэй. Шарп — это ХАЙВЭЙ.

    Что-то я как-то про него сегодня скромно.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[31]: Мэйнстрим vs. Самосовершенствование :)))
    От: Павел Кузнецов  
    Дата: 02.11.04 05:00
    Оценка: 6 (1) +1
    VladD2:

    > Скорее всего тут проблемы в понимании приципов ООП.


    No comment.

    > Мыслить от "утилиты"/"сотелиты" вообще вредно. Сделай декомпозицию на уровне классов и скорее всего окажется, что функция является методом некоторого другого класса.


    Хорошо. Вот несколько примеров. Очень интересно, в соответствии с "правильным мышлением", методами какого класса являются указанные функции, и почему (если на все "правильно мысля" ответить трудно, то хотя бы на самый последний)... Очень интересно при этом также узнать, как принятые решения будут влиять на такую метрику качества ОО дизайна, как зависимости между классами

  • Есть два класса: Date и String. Методом какого класса является функции: 1) преобразования даты в строку; 2) преобразования строки в дату?

  • Методом какого класса является функции преобразования: 1) целого в строку; 2) строки в целое? Есть ли какое-либо отличие этого примера от предыдущего?

  • Есть два класса: Date и DateDifference. Методом какого класса являются функции: суммы/разницы двух дат, суммы/разницы двух DateDifference, суммы Date и DateDifference?

  • Есть классы: Matrix и Vector. Методами какого класса являются функции: 1) умножения матрицы на вектор (результат — матрица); 2) умножения двух векторов по схеме "строка на столбец" (результат — матрица); 3) скалярного умножения векторов (результат — число); 4) афинных трансформаций вектора в соответствии с заданной матрицей преобразования?

    И, наконец:

  • Есть классы, контролирующие размерность: Velocity (v, скорость), Acceleration (a, ускорение), Length (l, длина), Time (t, время). Методами каких классов являются функции, соответствующие следущим выражениям: 1) l = v * t; 2) v = l / t; 3) v2 = v * v; 4) a = v / t; 5) v = a * t; 6) t2 = t * t; 6) l = 1 / 2 * a * t * t
    Posted via RSDN NNTP Server 1.9 gamma
  • Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[27]: Мэйнстрим vs. Самосовершенствование :)))
    От: Павел Кузнецов  
    Дата: 02.11.04 05:07
    Оценка: 6 (1) +1
    VladD2:

    > ПК> Дык, я ж тебе привел названия классических критериев. Тебе достаточно просто погуглить по этим названиям.


    > Мне то зачем? Ты что-то хочешь доказать. Вот и гугли.


    Я? Кому? Тебе, что ли? Это абсолютно бесперспективное занятие без твоего желания что-то узнать. Ты задавал вопросы, я на них отвечал. Не надо — отлично, разговор окончен. В следующий раз здорово сэкономишь нам обоим время, если больше вопросов, на которые тебе не нужны ответы, задавать не будешь.
    Posted via RSDN NNTP Server 1.9 gamma
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[4]: Oberon???????????????????????????????????
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 22.10.04 08:01
    Оценка: 1 (1) -1
    Здравствуйте, VladD2, Вы писали:

    VD> Мертвяк. Причем чистейший воды. Ни одного комерческого проекта.


    Вы не компетенты в вопросах об оберонах. Я уже приводил ссылки, среди которых, например, упоминается коммерческий проект создания ПО для ЭЛЕКТРОСТАНЦИИ (не хило не так-ли?), в ссылках сайта info21 есть военный проект по управлению беспилотными летающими аппаратами (опять не хило?).

    VD> Развитие Оберона с 96 года нет.


    Мало того что Вы не компетентны в вопросах об оберонах, но Вы еще и просто не внимательны. Совсем недавно, на этом форуме обсуждались "активные объекты". Вы случаем не обратили внимание на фигурирующие в даваемых ссылках даты? Создание Aos ~ 2000 год, диссертация Мюллера 2002 год. Работа над Zonnon идет по сей день.

    Посмотрите даты проектов: http://www.cs.inf.ethz.ch/gutknecht/
    Re[11]: Oberon???????????????????????????????????
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 26.10.04 10:06
    Оценка: 1 (1) +1
    Здравствуйте, Сергей Губанов, Вы писали:

    И чем же этот хрен слаще вот такой редьки:
    using System;
    class Class1
    {
        static void Main()
        {
            Console.WriteLine("Hello World");
        }
    }

    ?
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[10]: Мэйнстрим vs. Самосовершенствование :)))
    От: Зверёк Харьковский  
    Дата: 26.10.04 17:52
    Оценка: 1 (1) :)
    Здравствуйте, VladD2, Вы писали:

    INT>>Я не уверен, что хочу начинать с объектного. И тем более не уверен, что я хочу останавливаться на объектах в том виде, в котором их представляет C#.


    VD>Ну, сам понимашь, что на Окамле точно никто начинать учить не будет.

    VD>И кстати, что тебе не нравится в Шарпе с точки зрения ООП?

    Окамл vs. Шарп еще не было!

    Кстати, если серьезно. Есть идея написать "сравнительную" статейку по куче языков. Причем сравнительную не в смысле "язык А лучше тем что ..., а язык Б вообще говно", а, скажем так, расширяющую сознание. Идея — ответить на вопрос "я уже знаю то, это и еще вот это вот, на что еще можно посмотреть?"
    Каково? Я бы взялся... если бы ее в бумажный журнал... "Очень я это богатство люблю и уважаю" (с) Падал прошлогодний снег

    [офтоп]
    во время первоапрельской звуковой шутки мой профайл озвучивался фразой "А хотя бы я и жадничаю! Зато — от чистого сердца!"
    Вот и докажите теперь, что это рандомом было сделано
    [/офтоп]
    FAQ — це мiй ай-кью!
    Re[33]: Component Pascal
    От: WFrag США  
    Дата: 29.10.04 08:53
    Оценка: 1 (1) +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, WFrag, Вы писали:


    WF>>И еще, объясни, чем эта концепция definition-implementation-object отличается от C++-ых классов?



    СГ>Только definition — является единицей наследования (Экземпляров definition создавать нельзя). definition можно подвергнуть refine (по русски говоря отнаследоваться от него, причем это наследование обычное, а не множественное). И в каждой из refin'ов можно дать новые реализации-по-умолчанию некоторых методов. Object может реализовывать несколько definition, но сам object НЕ ЯВЛЯЕТСЯ единицей наследования, зато экземпляры object-ов создавать можно.



    СГ>Каждая definition рефайнится по своему дереву (иерархии наследования). Объекты реализуют несколько definition, но сами не участвуют в механизме наследования (т.е. от объекта отнаследоваться нельзя). Таким образом, как я уже раза три повторил, мы получаем все положительные стороны множественного наследования, но в то же время не зарабатываем никаких побочных эффектов.



    Ну я где-то так и понял. Получается, концепция C++ по возможностям покрывает концепцию Zonnon-а — и тогда я решительно не вижу в ней чего либо концептуально нового.

    Всегда можно сказать:
    1. не создавай экземпляры этого класса, пусть там будут только абстрактные методы. Это будет definition.
    2. не создавай экземпляры этого класса, пусть он наследуется от definition и реализует некоторые методы. Это будет implementation.
    3. не наследуйся от этого класса, но создавай его экземпляры. Это будет object.

    Re[33]: Component Pascal
    От: Schade Россия  
    Дата: 29.10.04 10:09
    Оценка: 1 (1) +1
    Здравствуйте, Сергей Губанов, Вы писали:

    <тут была песнь о DEFINITION>
    А в итоге — все тот же самый interface. Только называется по-другому, зато это же кострукция совершенного языка из oberon-family . Тот же бред, что и возмущения по поводу = и ==.
    ... << RSDN@Home 1.1.4 @@subversion >>
    Re[25]: Мэйнстрим vs. Самосовершенствование :)))
    От: Павел Кузнецов  
    Дата: 01.11.04 01:38
    Оценка: 1 (1) +1
    VladD2:

    > ПК> по большей части я с тобой согласен. Я и не предлагал вынесение функций из класса в качестве универсального решения всех проблем,


    > Нет, Паша, именно это ты и предлагаешь.


    Ерунда. Разговор был о наличии конкретной функции sort() в интерфейсе конкретного класса Array. К тому же, если посмотреть на историю ветки, то можно увидеть, что я ничего не предлагал. Напротив, это ты перешел к навязыванию такого расположения функции sort(), в то время, как в примере, который я привел (по совершенно другому поводу), функция sort() находится не в классе Array, а в отдельном "классе", имитирующем namespace, java.util.Arrays.

    > И именно это звучит очень смешно. В попытках обосновать дизайн СТЛ ты готов весь ООП вверх ногами перевернуть.


    Где именно я "переворачиваю весь ООП вверх ногами"? То, что тебе оно знакомо в перевернутом виде, вовсе не означает, что это и есть правильная картина.

    > <... эмоции и переходы к обсуждению взглядов оппонента вместо аргументации обсуждаемого вопроса поскипаны ...>


    Так и запишем: по существу тебе сказать особенно нечего.
    Posted via RSDN NNTP Server 1.9 gamma
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[33]: Мэйнстрим vs. Самосовершенствование :)))
    От: Павел Кузнецов  
    Дата: 02.11.04 22:08
    Оценка: 1 (1) +1
    VladD2:

    >>> Скорее всего тут проблемы в понимании приципов ООП.


    > ПК> No comment.


    > А кстати, зря. Так как именно тут у нас основное разногласие.


    Дык, имхо, это уже давно понятно Но чего теперь попусту воздух сотрясать, если мы вряд ли сможем повлиять на мнение оппонента?

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


    Смотрел я когда-то на него. Как скриптовый язык хорош. Для написания больших систем — вряд ли. Можно ограничиться одним моментом:

    In Ruby, classes are never closed: you can always add methods to an existing class.

    В больших системах минимизация зависимостей, выделение стабильных подсистем, использование одних и тех же подсистем различными клиентами и т.п. — одни из главных забот, а при таком подходе, плюс тотальная "виртуальность" методов, для больших систем, имхо, это просто кошмар.
    Posted via RSDN NNTP Server 1.9 gamma
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[9]: арифметические, логические, бинарные
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 22.10.04 07:41
    Оценка: +2
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, VladD2, Вы писали:


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


    VD>>Это конечно несколько лучше чем в Паскале/Дельфи. Но все же я не понимаю на фиг так извращаться.


    СГ>А где, собственно, извращение? В том что с числами запрещены бинарные операции? Так это, как бы, правильно — кесарю кесарево, а слесарю слесарево. В тоже время это не вредит системному программированию, так как всегда можно преобразовать число в множество (BITS) и множество в число (ORD). Например, пусть есть число i: INTEGER, хотите обнулить старшие четыре бита, вуаля:

    СГ>
    СГ>i := ORD( BITS(i) - {28,29,30,31} );
    СГ>


    Нет, ну я фигею, что за изврат, а...
    Тут без бутылки фиг поймёшь, это ты и называешь понятным и классным?
    по мне дак вот такая бы запись была бы гораздо понятней:

    i := ORD(BITS(i) AND BITS (0,0,0,0, 1,1,1,1, 1,1,1,1, 1,1,1,1,)


    а вычитание совсем не логичная операция, да и запись битов тоже хрен разберёшь,
    я понимаю, что по вирту, чем туманней, тем круче, но жизнь требует совсем иного, имхо
    Re[4]: Oberon???????????????????????????????????
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 22.10.04 15:59
    Оценка: :))
    Здравствуйте, VladD2, Вы писали:

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


    LVV>>Хочется альтернативный синтаксис показать.


    VD>1. Что в нем альтернативного? Та же императивщина, толко вместо скобок бегин с эндом, а вместо "=" используется ":=". Если уж показывать, то наврено лучше действительно какие-нибудь Хаскели и Питоны.

    VD>2. Показать и научить две большие разницы. Показывать можно сколько влезет хоть десять языков. А на учение время нужно.

    LVV>>Хотя я и о яве, и о дотнете с до диезом думал.


    VD>Я бы на этом и остановился.


    Ну зачем же. Я бы добавил еще и 1С!!!
    Оптимально 1С,С#,Delphi + Хаскели и Питоны
    и солнце б утром не вставало, когда бы не было меня
    Re[2]: Oberon???????????????????????????????????
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 24.10.04 00:07
    Оценка: +2
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Форум открыт по просьбам читателей сайта проекта


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

    СГ>для обсуждения Оберона/Компонентного Паскаля/Блэкбокса как технологической платформы для современной общей системы преподавания программирования, параллельной и дополняющей систему преподавания математики. Мнения за и против, вопросы как и почему, и т.п.


    СГ>Характер форума предполагает максимальную корректность высказываний: модераторы удалят без предупреждения любые сообщения с вульгарным или неуместным контентом, переходом на личности и т.п.


    А высказываения "против" являются вульгарным или неуместным контентом?

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

    ЗЫ

    И кстати, учите детей форматировать код. А так же учитесь этому сами. А то смотреть на ваши примеры с несколькими операторами записанными в одну строчку, отновенно говоря, противно.

    ЗЗЫ

    Почитал форум по данной ссылке... Забавно там вам тоже доказывают, что не нужно морочить Обероном голову детям. Но вы не завайтесь!
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[11]: Oberon???????????????????????????????????
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 24.10.04 08:44
    Оценка: +2
    Здравствуйте, VladD2, Вы писали:

    VD>Еще раз повторюсь. Шарп я смотрел после С++ и Дельфи. Языки конечно разные (и сильно) но концепции то схожи. И благодоря интуитивности синтаксиса чтение мануалов не требуется. Смолток же это вещь в себе. Его принципы очнь долеки как от мэйнстрим-продуктов, так и от оптимальной реализации. Спасибо этому почтенному языку за то, что двинул всю индустрию в перед. Пусть теперь отдахнет на пенсии.

    Ну, Влад, просто имхо дело в том, что при разработке C# были вложены нехилые бабки именно в то, чтобы ты сел за него, и практически без книжек в него вьехал. Это не случайность, это просто полное понимание разработчиками языка потребностей своей аудитории. А смоллток разрабатывался не заради аудитории, а заради возможностей. Кстати, его принципы ты поминаешь совершенно зря. Некоторые вещи, от которых ты сейчас так плюешься, перекочуют в С# в самом ближайшем будущем. Как там у нас на Старшей речи было?
    1 to: 10 do: [:each | Transcript show: each]


    Ага. Давайте переведем на C#:
    Transcript = new TextCollector();
    foreach(int each in Range(1, 10))
    {
      Transcript.Show(each);
    }

    Это мы предположили, что Range возвращает IEnumerable.
    Или даже так:
    Transcript = new TextCollector();
    Range(1, 10).Do(delegate(int each) { Transcript.Show(each); });

    Я, конечно же, схитрил. Для того, чтобы получить полный аналог SmallTalk, пршлось бы добавить метод ToDo в System.Int32(как это, собственно, и сделано в SmallTalk.):
    1.ToDo(10, delegate(int each) { Transcript.Show(each); });
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[3]: Мэйнстрим vs. Самосовершенствование :)))
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 24.10.04 13:15
    Оценка: +2
    Здравствуйте, Зверёк Харьковский, Вы писали:

    ЗХ>Имхо, ты везде приводишь более-менее верные и логичные аргументы, но не прав в главной своей мысли: "Все пишут на Яве и Шарпе, поэтому учить больше ничего не надо".


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

    Более того. Я вот с удовольствием познакомился с Питомном. В отличии от того же СмолТока или Окамла он на меня произвел очень хорошее впечатление (хотя и без огорчений не обошлось). Интересный язык, хорошо поддерживающий разные парадигмы. Если бы не его наплевательство на типы и несколько странное видение ООП, я бы пожалуй согласился с тем, что этот язык был бы очень хорошим кандидатом на превый язык программиста.

    Однако я совершенно не понимаю зачем начинать учить детей с экзотики вроде СмолТока или с мертвячины вроде Оберона. Если человеку будет интересно, он этот Оберон и сам выучит. Ну, а не хватит времени или усидчивости, так и фиг с ним. А так получится, что человек выучит оберон, прийдет на работу, а там: С++, Ява, Дельфи, Шарп и т.п. Хочешь не хочешь, а прийдется переучиваться. Причем именно переучиваться, так как Вирт принципиально навязывает свои "привычки". Даже в Дельфи и Васике появился оператор "ретон". А у Вирта свой взгляд на мир. Он учит if-ы вкладывать. Причем начиная учить детей на Обероне им в первую очередь навязывают стиль, а не объясняют принципы построения грамотного кода. В итоге получим зазубрышей резко отвергающих то все промышленные языки и не знакомых банальными понятиями вроде абстракции, наследования, полиморфизма.

    ЗХ>Я считаю, что изучение других языков программирования идет не в минус (забиваем голову ненужной информацией), а в плюс. И не потому, что СмолТолк кому-то может пригодиться (ой, сумлеваюсь), а по очень простой причине: расширение кругозора. Просто понять, что "и такое бывает". Подцепить полезный метод или идею. В конце концов (в парадигме начального вопроса Валерия Викторовича) — просто осознать, "что не в любом языке программирования есть фигурные скобки".


    Согласен. Но пусть это будет факультативной задачей. А в качестве первого языка пусть будет нечто хорошо спроектированное, но промышленное.

    ЗХ>Возьмем, например, меня .

    ЗХ>В контексте давнего спора про то, какой язык кому нравится, могу слегка скорректировать свое тогдашнее мнение: "я люблю С++ и пока это возможно, буду писать только на нем", но сейчас собираюсь покупать Рихтера про Шарп. Не потому, что хочу на него перейти — интересно, что нового, чем он отличается; как нужно "думать на Шарпе". А и кроме того, книжки, которые валяются на винте, и которые я уже изучил или собираюсь в ближайшем будушем, посвящены языкам: Ada, Assembler, Awk, C--, C++, C#, Delphi, Eiffel, Euphoria, Forth, Go!, Haskell, Java, Lisp, OCaml, Oz, Perl, PHP, Prolog, Python, Refal, Small, Smalltalk, Tcl, VB.

    Здорово. На винтах у меня правда тоже валяется черти что. Но о некоторых языках я даже не слышал. Например, что такое Refal и Go! я не знаю.

    Кстати, очень хороший списак. Как по твоему Оберон и СмолТок заслуживают больщего внимания чем все перечисленные тобой тут языки?

    Вот по-моему нет. Вот я и предлагая в качестве первого языка выбрать один из языков мэйнстрима, а потом уже приступать к изучению всего остального. Я даже считаю, что здорово было бы изучать параллельно языки имеющие разные парадигмы. Тогда возможно было бы можно избежать ломки понимания.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[4]: Мэйнстрим vs. Самосовершенствование :)))
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 25.10.04 08:07
    Оценка: -2
    Здравствуйте, VladD2, Вы писали:

    VD>.....появился оператор "ретон". А у Вирта свой взгляд на мир. Он учит if-ы вкладывать.


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


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


    А вот компетентные в этом вопросе люди утверждают обратное. Ссылки я уже неоднократно приводил.
    Re[8]: Мэйнстрим vs. Самосовершенствование :)))
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 26.10.04 04:35
    Оценка: :))
    Здравствуйте, VladD2, Вы писали:

    ЗХ>>Хотя круче С++ языка нет, не было, и не надо, а C# — конъюнктурная поделка Мелкософта

    VD>Однако учить С++ лучше уже окрпшим умом. А то можно и кршу потерять.

    Истинно так. Так и становятся програмистами. Ну, теми, для которых программирование — диагноз.
    ... << RSDN@Home 1.1.3 stable >>
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[3]: Мэйнстрим vs. Самосовершенствование :)))
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 26.10.04 04:35
    Оценка: :))
    Здравствуйте, Зверёк Харьковский, Вы писали:

    ЗХ>А еще кто-то умный говорил, что программисту полезно знать основы генетики. Сильно развивает восприятие.

    ЗХ>Думаю, про многие другие науки/дисциплины можно сказать то же самое (что их полезно знать программисту).

    Угу:
    — философия;
    — риторика;
    — психология и азы психиатрии;
    — логика;
    — основы лингвистики.

    Эх, нехилый вводный курс в программирование может получиться! И правильно. Ибо сказано: нефиг.

    ЗХ>Во. Типа dixi.

    ... << RSDN@Home 1.1.3 stable >>
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[10]: Oberon???????????????????????????????????
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 26.10.04 09:42
    Оценка: :))
    Здравствуйте, Sinclair, Вы писали:

    СГ>>То есть сначала надо будет объяснить что такое namespace, class, static void Main, ее аргумент string[] args, вот этого кракозябла [STAThread] — объяснить. Не хило?


    S>А можно в ответ привести минимальную программу на обероне?

    MODULE MyModule;
    
    IMPORT StdLog;
    
    BEGIN
      StdLog.String("Здравствуй мир!");
    
    END MyModule;



    Примеры простейших программ:
    http://www.inr.ac.ru/~info21/cpascal/primery.htm
    Re[4]: Обновление
    От: LaptevVV Россия  
    Дата: 26.10.04 12:38
    Оценка: :))
    Здравствуйте, Kh_Oleg, Вы писали:

    СГ>>Сегодня сайт проекта Информатика 21 был серьезно обновлен. Заходите смотрите.

    СГ>>Основная новость: к концу 2004 года ожидается открытие исходного кода BlackBox.

    K_O>А мне очень понравилась вот эта статья:

    K_O>О дисциплине программирования
    А вот с того же сайта

    Вопрос: Почему столь важный продукт, как операционная система, используемая на сотне миллионов компьютеров во всем мире, строится на столь гнилом фундаменте, как язык программирования, для которого нельзя написать компилятор, генерирующий эффективный и безопасный код, с тем чтобы переложить тривиальный механический труд по нудной проверке индексов массивов с человека, которому свойственно ошибаться при выполнении механических процедур, на компьютер, который именно для таких процедур и придуман?
    Ответ: Потому что подавляющее большинство программистов Майкрософт, начиная с Билла Гейтса, — как бы хорошо ни была организована их работа и какими бы талантливыми индивидуумами они ни были сами по себе — классические программисты-самоучки, втянутые в круговорот компьютерной революции большими деньгами и задумывающиеся о методологии программирования только под сильной угрозой со стороны конкурентов.

    В начале 2002 г. Майкрософт на месяц приостановила нормальную работу, чтобы программистский персонал мог специально сосредоточиться на проблемах безопасности и надежности программ. Если оценить количество программистов Майкрософт в 20 тысяч человек при зарплате от $150 тыс. в год и выше, то стоимость месячника повышения квалификации выйдет не меньше 250 миллионов долларов. Майкрософт в состоянии это себе позволить. Остальным, видимо, все же дешевле перейти на инструменты программирования, где проверки индексов массивов не отключаются. Впрочем, и сама компания Майкрософт в настоящее время переходит на платформу .NET, в которой главный язык программирования — т.наз. C# — смоделирован во многом, в том числе и в отношении безопасности программирования, по образцу Оберона.

    К вопросу о священной войне Губанова и Влада
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[14]: Oberon???????????????????????????????????
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 26.10.04 13:38
    Оценка: -1 :)
    Здравствуйте, Sinclair, Вы писали:

    СГ>>1) Существуют модули

    S>Что такое модули? Или это в седьмом классе понятно всем и без объяснения?

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

    СГ>>2) Один модуль может импортировать другой модуль

    S>Что значит импортировать?

    Опять на это можно прямо пальцем показать, вот так, мол, смотрите, один модуль пользуется услугами другого модуля...

    СГ>>2) Существуют классы (еще одна непонятность — что еще за классы? Классы чего? Мы в седьмом классе учимся и что с того?)

    S>Верно. Что-то все-таки надо детям рассказывать.

    То-то и оно!

    СГ>>3) У классов есть статические методы (опять ребенку непонятно что такое статические и что такое методы, в чем разница между подпрограммами и методами?).

    S>А при чем тут подпрограммы? Кто-то считает понятие подпрограммы присутствующим в детской голове прямо с рождения? Лично я в седьмом классе колбасил арканоиды безо всяких подпрограмм. Так что это — заблуждение. И вводить понятие метода ничуть не хуже, чем начинать с каких-то подпрограмм.

    Метод — это подпрограмма (процедура) ассоциированная с контекстом исполнения — объектом, т.е. ввести понятие метода сложнее чем ввести понятие подпрограммы (процедуры).

    СГ>>Что такое void? Почему именно Main?

    S>Да. с Void придется повозиться.

    Опять, то-то и оно.

    S>Итак, пока что у нас Оберон — C# идут один-в-один, за исключением void. Во всем остальном паритет.


    А еще за исключением class, Main, static,...
    Re[15]: Oberon???????????????????????????????????
    От: Павел Кузнецов  
    Дата: 26.10.04 17:44
    Оценка: +2
    VladD2:

    > Он не типизированный.


    Не путаем "не типизированный" и "динамически типизированный" — суть разные вещи
    Posted via RSDN NNTP Server 1.9 gamma
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[17]: Oberon???????????????????????????????????
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 26.10.04 18:52
    Оценка: +2
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Что непонятного-то, выбросил пространтсво имен — вот упрощенная версия,

    Что значит "выбросил"? Не стал использовать — это более правильно.
    СГ>захотел написал System.Console, а захотел не написал.
    СГ>Захотел написал тег [чего-то], а захотел не написал — все это является "сокровенным", неявным, недоговоренным.
    Я фигею. То есть ты сначала критикуешь программу на C# за то, что в ней используется больше концепций, чем в Обероне. А затем ты критикуешь другую программу за то, что в ней не используются эти концепции, так что ли? По-моему, у тебя с логикой некоторые проблемы.
    СГ>А в Обероне программа что для школьника будет такой как я ее написал, что точно так же для профессионала — никаких изменений и корректировок.
    Ничего не понимаю. То есть в Обероне нет никаких концепций, кроме несчастных четырех ключевых слов и термина "подпрограмма"? Что-то мне подсказывает, что на Обероне можно не только хелловорлды писать. Давай я сейчас твою программу поругаю за то, что ты мог использовать классы, но не использовал. Мог применить WITH — но не применил. Что за недоговоренности? Скрываем от детей правду?
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[11]: Oberon???????????????????????????????????
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 26.10.04 18:54
    Оценка: +2
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>А в оберонах ее скрывать не надо — ее там нет. Нет "сокровенных", "замалчиваемых", "скрытых", "недоступных для широких слоев" тайной информации.

    Вообще-то ее и в Шарпе нет. Спецификация открыта. Так что не надо ля-ля среди взрослых людей заниматься.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[14]: Oberon???????????????????????????????????
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 27.10.04 07:44
    Оценка: -1 :)
    Здравствуйте, VladD2, Вы писали:

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


    СГ>>Между модулями и классами-то?


    VD>Да. Для начального понимания разницы почти не какой. Та же область определения методов и переменных.


    Ну вот, правильно, типичный принцип сокрытия "сокровенных знаний"....

    А разница между прочим на столько громадна, что даже не смешно. Перво-наперво надо объяснить КУДА писать исходный код программы. Модуль — это и есть то самое место куда надо писать исходный код программы, в том числе код классов надо писать внутрь модуля. Но Вы, будучи воспитанными на немодульных языках программирования, этого не знаете и код программы Вы пишите просто в текстовый файл.
    Re[15]: Oberon???????????????????????????????????
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 27.10.04 07:51
    Оценка: :))
    Здравствуйте, Сергей Губанов, Вы писали:
    СГ>Ну вот, правильно, типичный принцип сокрытия "сокровенных знаний"....

    СГ>А разница между прочим на столько громадна, что даже не смешно. Перво-наперво надо объяснить КУДА писать исходный код программы. Модуль — это и есть то самое место куда надо писать исходный код программы, в том числе код классов надо писать внутрь модуля. Но Вы, будучи воспитанными на немодульных языках программирования, этого не знаете и код программы Вы пишите просто в текстовый файл.

    Гм. А можно критерии отличия текстовых файлов от модулей? А то я может, по незнанию, совсем не туда код-то пишу...
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[17]: Oberon???????????????????????????????????
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 27.10.04 09:10
    Оценка: +2
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>не синтаксическая конструкция? Модуль вполне можно локализовать как синтаксически, так и физически (единица компиляции и единица исполнения). А пространство имен локализовать нельзя, оно размазано по куче файлов. А для того чтобы показать пальцем надо именно локализовать.


    А зачем его локализовывать? Влад ведь правильно сказал — пространство имен это чисто логическая концепция, физически никакого пространства имен не существует. Если начать без юзингов, а потом объяснить что юзинг это просто способ избавится от лишней писанины (как with к примеру), то даже школьники все прекрасно поймут, поскольку концепция не требует абсолютно никаких дополнительных знаний.
    А вот модуль уже куда более сложная концепция, поскольку чтобы ответить на вопрос "а нафига он вобще нужен" требуется объяснять принцип разделения кода по физическим единицам хранения, в отличие от дотнета, в котором до поры до времени можно на понятие сборки спокойно забить.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    AVK Blog
    Re[17]: Oberon???????????????????????????????????
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 27.10.04 09:14
    Оценка: +1 :)
    Здравствуйте, Сергей Губанов, Вы писали:
    S>>Гм. А можно критерии отличия текстовых файлов от модулей? А то я может, по незнанию, совсем не туда код-то пишу...

    СГ>Модуль — это самая большая структурная единица программы, содержащая внутри себя все остальные.

    А, ну тогда все в порядке. Поскольку эта структурная единица содержит в себе все остальные, то я никак не промахнусь с написанием кода. Вот ведь как получается-то! Я оказывается код тоже в модулях писал. А вовсе не в каких-то текстовых файлах, как меня WinDiff убеждает.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[25]: Component Pascal
    От: Kluev  
    Дата: 27.10.04 09:51
    Оценка: :))
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Чем Вам такая штуковина не нравится в качестве интерфейса:


    СГ>
    СГ>TYPE
    СГ>  Store = POINTER TO ABSTRACT RECORD
    СГ>    (s: Store) Internalize- (VAR rd: Reader), NEW, EMPTY;
    СГ>    (s: Store) Externalize- (VAR wr: Writer), NEW, EMPTY;
    СГ>  END;
    СГ>


    СГ>
    СГ>TYPE
    СГ>  MyObject = RECORD (Store)
    СГ>    ...    
    СГ>    (t: MyObject) Internalize- (VAR rd: Reader);
    СГ>    (t: MyObject) Externalize- (VAR wr: Writer);
    СГ>    ...
    СГ>  END;
    СГ>


    Что не нравится лично мне так это синтаксис. Самое смешное что почтенный дядюшка Вирт наезжал на сишный оператор присваивания = , типа мол не могу обяснить сыну почему х = y это не тоже самое что у = х.

    Интересно TYPE Store = POINTER TO ABSTRACT RECORD это тоже самое что POINTER TO ABSTRACT RECORD = TYPE Store или что-то другое?
    Re[19]: Мэйнстрим vs. Самосовершенствование :)))
    От: kbasil Россия  
    Дата: 28.10.04 01:38
    Оценка: +2
    Здравствуйте, Зверёк Харьковский, Вы писали:

    ЗХ>>>>>ОК, учтем. PL/I я просто не видел еще, интересно.

    AVK>>>>Лучше бы тебе его не видеть
    ЗХ>>>Теперь точно буду смотреть... Заинтригован.

    LVV>>Тогда ищи книжку Лепин-Дмитрюков. Программирование на PL/I (или ПЛ/1 )

    ЗХ> И где мне ее искать? В инете нету, а к библиотекам институтов доступу, как сами понимаете, уже тоже нету

    В букинистическом магазине Вариант: поищи на ВЦ, где стояли ЕС-ки и т.п. М.б. в макулатурных завалах документация осталась. Только учти — документация на ПЛ/1 неообозрима
    Re[27]: Component Pascal
    От: WFrag США  
    Дата: 28.10.04 12:07
    Оценка: +2
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Вот напугал. А в Zonnon-е есть абстракция еще более крутая чем интерфейс, называется definition.


    СГ>definition подобны interface плюс следующие фичи:


    СГ>1) definition кроме методов могут включать в себя еще и переменные

    СГ>2) definition может иметь предопределенную реализацию (implementation) некоторых методов.

    Проанализируем с точки зрения Java (хоть она и не упоминалась в контексте предыдущего сообщения).

    Для Java (например) это были бы вредные фичи. Интерфейс — это контракт на поведение, абсолютно без намеков на реализацию.

    Пункт второй привносит зависимость от реализации в интерфейсе (интерфейс здесь и ниже имеется ввиду как Java-интерфейс + 2 вышеприведенных пункта) — что нарушает такой принцип как stable Abstractions Principle — абстрактные сущности должны быть стабильны. А зависимость от реализации делает сущность (интерфейс + 2 приведенных пункта) нестабильной.

    Пункт первый, кстати, вреден по той же причине. Переменные — часть реализации. А вот свойства — это часть интерфейса, они хоть и зло (поскольку описывают не поведение, а содержание), но зло меньшее чем переменные (переменные в моем понимании — поля в Java-классах).

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

    P.S. Тем не менее я согласен с тем, что подключения предопределенных реализаций интерфейсов полезная штука (при отсутствии множественного наследования).

    P.P.S. Так, мысли вслух, про Zonnon ничего не знаю
    Re[22]: Oberon???????????????????????????????????
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.10.04 13:01
    Оценка: -2
    Здравствуйте, eugals, Вы писали:

    E>Кстати, очень удобно. Ещё никто не жаловался, даже наоборот...


    Ну, да. Очень удобно. Если не думать о последствиях. На Перле тоже очень удобно писать...

    E>Если сильно захотеть, это можно конечно назвать неявным приведением к типу, но можно и не называть.


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

    E>В шарпе, при подстановке в foreach у последовательностей неявно запрашивается IEnumerable. Это тоже плохо?


    Это понижающее приведение. С ним ошибок быть не может.

    E>Ещё, как ни ужасно это звучит, при передаче фактичеких параметров в функции они автоматически кастятся к типам формальных (если, опять же, поддерживают нужные интерфейсы).


    При понижающем приведении это нормально. Но когда int приводится к bool или список приводится к bool, то это уеж чревато ошибками.

    Ну, а объявление переменной при первом использовании, да еще и внутри вложенных блоков с видимостью во вне — это просто бардак. Тут еже баги будут пить дать.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[11]: Обновление
    От: _Obelisk_ Россия http://www.ibm.com
    Дата: 28.10.04 13:18
    Оценка: +2
    Здравствуйте, Сергей Губанов, Вы писали:


    СГ>Именно поэтому все из перечисленных Вами языков были отвергнуты. В качестве стандарта был выбран Component Pascal на котором коряво программировать не получится.


    На любом ЯП допускающим определение переменных и процедур (функций) можно написать корявую программу просто
    проименовав все переменные как V1, V2,V3,...V1001 и процедуры как P1,P2,...P1234 и не ставить коментарии вовсе.


    http://www.rsdn.org:80/File/18435/5278.png
    Душа обязана трудиться! (с) Н.Заболоцкий.
    Re[10]: Обновление
    От: Павел Кузнецов  
    Дата: 28.10.04 19:49
    Оценка: +2
    VladD2:

    > СГ> Но он действительно по-дилетантски спроектирован.


    > С теми условиями (сохранение обратной совместимости с С) сделать нечто другое было просто невозможно. Почти все отрицательные черты являются следствием наследия С. А то что спроектировал Страуструп более мнее неплохого качества. Можно было конечно сделать и лучше, но уж дилетанством — это не назавешь.


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

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

    Существенных недостатков у Оберона & co. в качестве учебных языков тоже особенно не видно, поэтому говорить о том, что на Обероне обучать плохо, тоже, по-моему, ни к чему. Кому нравится — пусть обучает на этих языках... В общем, учебные языки, как учебные языки

    По-моему, намного большее значение для обучения программированию имеет не язык, а квалификация преподавателей, коей лучше бы и уделялось должное внимание. А в остальном, как давно установлено, there is no silver bullet.
    Posted via RSDN NNTP Server 1.9 gamma
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[14]: Мэйнстрим vs. Самосовершенствование :)))
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.10.04 23:00
    Оценка: :))
    Здравствуйте, Sinclair, Вы писали:

    S>Ну, ребята. Нельзя же так вольно с терминологией! Ну где ты увидел здесь объект, который объектом не является?


    Не не въехал! Там же нет префикса std::, а это теперь считается неграмотным. И вообще, если все методы (пусть и статические) помещать в класс к которому они относятся, то любой дурак нажав точку в IDE получит их список. А это уже покушение на место проффесиональных программистов! Ведь раньше только они знали где отрыть нужный метод! Вот как по-твоему найти метод бинарного поиска в СТЛ? Аа... слабо?! (зларадно) А вот Паша уже знает. И он нам свое место не за что не уступит.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[9]: Мэйнстрим vs. Самосовершенствование :)))
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 29.10.04 16:58
    Оценка: +2
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Какие Вы демонстрируете глубоки познания! exit — это в Си/Си++ завершение приложения, а в борландовском Delphi/Pascal exit — это выход из процедуры, а завершение программы Halt();


    С каких пор Паскаль стал равен Дельфи?
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[8]: Oberon???????????????????????????????????
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 29.10.04 21:05
    Оценка: +2
    Здравствуйте, VladD2, Вы писали:

    AVK>>Дело не в этом, дело в том что на изучение шарповских фичек нужно банально больше времени.


    VD>Дык никто же не заставляет все учить.


    Увы, некоторые фишки щарпа встроены в язык намертво и используются в стандартной библиотеке. Можно конечно про них умалчивать, но задолбаешься потом флажки развешивать, куда не ступать.

    VD> Но уж за время обучения в институте такой язык как шарп можно уж точно освоить.


    Это если он один. В институте (по крайней мере на специальностях 220Х) ведь никто не читает курс язык программирования ХХХ. Курсы называются "основы системного программирования", "системное программное обеспечение", "алгоритмы и структуры данных" и т.п. Никто неставит целью именно изучить язык, надо побыстрее научить что то делать на каком либо языке, а потом объяснять основное наполднение курса. На фоне этого языки с удобными, но неконцептуальными наворотами менее выгодны.

    AVK>> Например посмотри реализацию событий. В джаве события реализуются при помощи интерфейсов, т.е. если человек уже знает про концепцию интерфейсов, то про события ему вобщем то уже объяснять не нужно.


    VD>Гы. Хороший пример. Боюсь на объяснение концепций событий из Явы уйдет в разы больше времени, чем на объяснение событий в Шарпе.


    Ничего там не уйдет. Там вобще как таковой отдельной концепции нет. Просто в некоторых библиотеках появляются listeners, причем как ими пользоваться понятно сразу же при просмотре первого примера. Что же такое эвенты, по моим наблюдениям, точно не знают весьма немалый процент профессиональных программистов. Посмотри с какой регулярностью в форуме возникает вопрос — "чем эвенты отличаются от делегатов".

    VD> А если вспомнить все эти неявные ссылки на родительские классы из вложенных...


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

    AVK>> В шарпе же нужно объяснить что такое делегат, потом что такое мультикаст делегат, потом что такое собственно эвент.


    VD>Ну, это-то как раз и хоршо. Это тот самый абстрактный функционал с которым ученикам очень было бы полезно познакомиться. Тут как видишь народ склоняется к Питону именно потому что в нем есть концепции функциональных языков.


    Это смотря какую цель преследовать. Если изучение языка, то возможно. Только это уровень техникума, а не института.

    AVK>>Единственное в чем джава сложнее шарпа, это в концепции вложенных классов.


    VD>Гы. А не на них ли теперь события делают?


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

    VD>К тому же сложностей хватет. В Яве все недостоющее эмулируется. А эти эмуляции тоже объяснять нужно.


    Значительно проще, поскольку вся механика явная.

    VD> То же применение массивов вместо ref/out модификаторов у параметров объяснять прийдется очень подробно.


    Еще раз — применение массивов это чисто практическая фишка, для обучения ее объяснять не нужно и даже вредно. В стандартной библиотеке такой финт ушами не используется.

    AVK>>Тебе часто приходится использовать ref и out?


    VD>Приходится. А что? Или типа передача ссылок и out-параметры — это не важный аспект обучения?


    Смотря какого. Для ремесленника важный, для инженера не очень.

    AVK>>И опять же — для обучения предпочтительнее для этого использовать ... нет, не массивы, а специально созданные классы, содержащие совокупность параметров.


    VD>Ну, это верх изврата.


    Нет, это правильный подход к проектированию, когда лень не мешает это делать. Сколько раз встречаются ref и out в библиотеке фреймворка?

    AVK>>От некоторых вещей отмазаться не получится, например от боксинга и структур.


    VD>Опять же или прийдется эмулировать их, или умолчать. Оба случая не в пользу Явы.


    Явная механика боксинга для обучения безусловно предпочтительнее, поскольку все сразу видно. А вот неявный боксинг приведет новичков к проблемам. Что регулярно находит подтверждение в дотнетовском форуме.
    ... << RSDN@Home 1.1.4 beta 3 rev. 216>>
    AVK Blog
    Re[25]: Мэйнстрим vs. Самосовершенствование :)))
    От: Павел Кузнецов  
    Дата: 30.10.04 16:22
    Оценка: +2
    Undying:

    > ПК> Дык, это уже речь пошла о каких-то более специализированных классах, не столь универсальных, как стандартные Array, List etc. В этих специализированных классах, для которых сортировка является не "утилитой", а основным поведением, сам байт велел делать функцию sort() членом.


    > Говорим-то мы о общих подходах к проектированию.


    +1. Я только хотел подчеркнуть, что, с моей точки зрения, общим подходом должно быть принятие подобных решений в частном порядке. И иногда, учитывая все за и против, прибегать к более сложным паттернам, а не просто ограничиваться наследованием и "ужирнением" интерфейсов (interface bloat), "пытаясь писать в ОО-стиле".

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


    В качестве одного из предусловий я упомянул, что код, использующий классы, разработчиками напрямую не контролируется. Соответственно, к изменению семантики некоторой функции в библиотечном классе я отношусь крайне настороженно, представляя последствия замены использования в методе Array.sort() функции stable_sort() (сохраняющей порядок "одинаковых" элементов) на более быструю (в некоторых случаях) quick_sort()... В этих условиях, имхо, изменение семантики как раз совершенно недопустимо.

    Да и в других случаях, когда весь код в нашем распоряжении, мы далеко не всегда готовы проводить анализ всех использований, необходимый для подобных "молчаливых" изменений семантики базовых компонент. Я бы скорее согласился, если бы были изменены места, где используется данный класс. Естественно, если все было спроектировано на совесть, дублирования аналогичных вызовов Array.sort быть не должно, т.к. доступ к некоторому Array должен контролироваться одним классом, и, соответственно, в данном классе, представляющем абстракцию уровня кода приложения, изменять семантику подобных методов вполне допустимо. Воздействие таких изменений, в отличие от правки общих компонент, ограничены и предсказуемы, т.к. соответствующая сортировка привязана к контексту, и ожидания от нее хорошо известны.

    > Я могу с тобой согласиться, что решение с добавлением Sort'а в коллекции является не совсем концептуально чистым (прежде всего из-за использования реализаций классов, а не минимально нужного набора интерфейсов — в статичном Array.Sort в частности), но пользоваться этими коллекциями очень удобно <...>


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

    > если же они применяются сплошь и рядом, то лучше всего будет сделать обертку над тем же ArrayList'ом, которая в том числе будет реализовать и эти дополнительные алгоритмы через какой-нибудь интерфейс.


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

    > если проводить аналогию с реальным миром, то можно заметить, что все действия в нем направлены именно непосредственно на объект, скажем физические законы можно считать внешними функциями, а шарик объектом. Мы же не говорим, эй физические законы толкните шарик с силой F, а говорим просто толкнем шарик с силой F, а там уже шарик сам разбирается каким физическим законам он сейчас подчиняется и как он должен на это отреагировать.


    Я придерживаюсь концепции, рекомендующей по умолчанию помещать методы в класс, являющий субъектом, а не объектом действия, предоставляя в объекте достаточный для реализации намерений субъекта интерфейс. В частности, возвращаясь к твоему примеру, мы говорим: "(Мы) толкнем шарик с силой F" (скорее, даже: "Передать шарику импульс P") Но это уже софистика, т.к. в том, что у шарика неизбежно будет какой-то метод, принимающий воздействие, ты, естественно, прав.
    Posted via RSDN NNTP Server 1.9 gamma
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[20]: Обновление
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 01.11.04 15:45
    Оценка: :))
    Здравствуйте, Mamut, Вы писали:

    M>А если я всю программу заглавными буквами напишу?


    Дык, Вам ни что не мешает и разными цветами каждую букву раскрасить, благо возможности редактора это позволяют.
    Re[23]: Обновление
    От: Кодт Россия  
    Дата: 01.11.04 17:39
    Оценка: +1 :)
    Здравствуйте, Sinclair, Вы писали:

    S>В общем, я зверств-то не хуже Вирта могу попридумывать.


    Примерно так народ с перфокартами трахался.
    Только там был ещё один пункт, о котором ты забыл: write-only memory. То есть ты, как дурак, топчешь клавиатуру перфоратора, а он тебе показывает лишь номер текущей позиции. Сбился? Отмена, и всю строку заново. Как пароль со звёздочками (до 72 штук). Вот только если ты облажался с паролем, тебе сразу скажут. А перфоратор — он тупой. Пробивает перфокарту, ты берёшь эту колоду и идёшь к машине. Пуск... Авотхрен.
    В больших ВЦ, помимо этого, существовал пространственно-временной лаг между программистом и машиной — девочки-наборщицы. Там время перекомпиляции (иногда по вине девочки) занимало до суток — пока очередь подойдёт.

    (Мне в детстве удалось поиграть у отца на работе — Fortran-4 на ЕС-1035. Вещ. С непривычки по полколоды шло сразу в макулатуру. Потом наловчился).
    http://files.rsdn.org/4783/catsmiley.gif Перекуём баги на фичи!
    Re[30]: Мэйнстрим vs. Самосовершенствование :)))
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 01.11.04 19:16
    Оценка: -2
    Здравствуйте, prVovik, Вы писали:

    V>Вот для контейнеров, сортировка которых действительно требует доступа к внутренней структуре ее, конечно, надо делать внутренним методом.

    V>Для всего остального подойдет внешний обобщенный алгоритм сортировки типа std::sort()

    А для всех остальных он просто не нужен. Он реально нужен именно в классе вроде вектора.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[31]: Мэйнстрим vs. Самосовершенствование :)))
    От: Павел Кузнецов  
    Дата: 02.11.04 04:36
    Оценка: +2
    VladD2:

    > Процетирую последнюю ссылку: <...> В ней только стеб над твоей любовью к std:: и нежелаение признавать, что и по другому можно. Призывов делать только так как сделано в Яве и дотнете нет. В прочем как и их упоминания.


    1) Я не упоминал STL.
    2) Я вполне согласен, что можно делать по-другому. Также я понимаю и недостатки делания "по-другому" (впрочем, равно как и достоинства). Именно поэтому в первом сообщении я сказал, что вопрос это спорный.
    3) В Java сделано не так, как в .Net. А именно, в Java, как уже много раз было указано, функция sort() вместе с остальными утилитами типа binarySearch(), fill() и т.п. вынесена в "namespace" java.util.Arrays, который сделан классом только из-за невозможности иметь в Java "свободные" функции. Так что, если уж поминать STL, то в этом отношении в Java сделано скорее ближе к тому, как в STL, чем к тому, как в .Net

    >>> Может быть просто признать тот факт, что это ты пыташся выдать свое мнение за единстванно верное и тем самым навязать его, а я все го лишь говорю, что считаю иначе?


    > ПК>Какое именно мое мнение?


    > О том что все не приметивные методы нужно делать глобальными функциями.


    Нет у меня такого мнения. Сложность метода никакого отношения к тому, делать ли его членом или нет, с моей точки зрения, не имеет. Для меня основное — степень его отношения к основной задаче, выполняемой классом.

    > И наезды на статические методы Sort в Яве.


    sort() в Java является статической функцией отдельного "класса" java.util.Arrays, не Array. Сделан он классом чисто номинально, т.к. "свободных" функций в Java нет. Никаких претензий или наездов на библиотеку Java по этому поводу у меня нет. Единственное, на что я обратил внимание, так это на то, что авторам библиотеки пришлось имитировать namespace с помощью класса из-за своеобразности языка. Об этом же, насколько я его понял, говорил и INTP_mihoshi. Синклер попросил пример — ему его привели. Точка.

    Вся дальнейшая дискуссия — результат твоих реплик по совершенно другой теме, а именно предпочтению тобой размещения sort() "в самом классе, к которому она относится", "чтобы IDE показывала список методов при нажатии на точку".

    > ПК> Ты опять пропустил, что началось все с того, что ты зачем-то приплел в разговор размещение sort() и т.п. "в классе, к которому они относятся", хотя речь шла совершенно о другом. Как я мог навязывать кому-то свое мнение, если я до твоего высказывания даже не упоминал?


    > Нда. Связь с реалией снова потерен.


    Очень похоже на то.

    > Вот сообщение
    Автор: Павел Кузнецов
    Дата: 28.10.04
    в котором ты ты приплел Явовский класс со списком исключительно статических методов (гы-гы) и начал изливаться про инварианты. А вот здесь ты как раз преплел методы sort из этого многострадального класса.


    И? Как это все относится к тому, помещать ли функцию sort() в класс Array?

    > Далее тебе кто-то замети, что методы статические, но тебя было уже не остановить. Ты и это как-то обосновал.


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

    > Хотя как в Яве могут быть методы не экземплярные и не статические одновременно?


    Елки-палки, лес густой Я именно об этом вместе с INTP_mihoshi и говорил, что в Java нет "свободных" функций, и поэтому приходится создавать "липовые" "классы" вместо namespace. Никаких претензий к дизайну библиотеки Java в этом отношении у меня нет и не было: разработчики сделали лучшее, что позволил им язык.

    Чтобы тебе было окончательно ясно, вот ссылка
    Автор: Павел Кузнецов
    Дата: 29.10.04
    на мое первое к тебе сообщение, в котором я, на мой взгляд, вполне ясно говорю о том, что твои претензии совершенно не по адресу, и что положение функции sort() вопрос абсолютно отдельный, не связанный с тем примером, который я привел.

    P.S. Честно говоря, я уже окончательно потерял надежду что-то тебе объяснить. Сам не знаю, зачем я это сообщение написал, ибо, думаю, абсолютно бесполезно это...
    Posted via RSDN NNTP Server 1.9 gamma
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[22]: Обновление
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 02.11.04 10:59
    Оценка: -2
    Здравствуйте, Зверёк Харьковский, Вы писали:

    ЗХ>Набирать ключевые слова большими буквами противоестественно


    ЭТО ВСЕГО ЛИШЬ ВОПРОС ПРИВЫЧКИ.
    Re[29]: Мэйнстрим vs. Самосовершенствование :)))
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 02.11.04 14:32
    Оценка: +2
    Здравствуйте, AndrewVK, Вы писали:

    V>>

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


    AVK>О! Осталось только понять что многие алгоритмы сортировки требуют доступа к внутренним структурам, а, следовательно, являются примитивными методами. Так что цитата твоя таки не в тему.


    Парадоксально, но факт. Если алгоритм сортировки требует доступа к внутренним структурам, то это уже повод задуматься о добавлении соответствующих примитивных операций в интерфейс контейнера. Или... о том, что контейнер спроектирован с ошибками.
    ... << RSDN@Home 1.1.3 stable >>
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[28]: Мэйнстрим vs. Самосовершенствование :)))
    От: Undying Россия  
    Дата: 02.11.04 22:56
    Оценка: +1 :)
    Здравствуйте, Павел Кузнецов, Вы писали:

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


    ПК>Никаких из этих проблем не возникает, если "вспомогательные" алгоритмы (то есть не основные для самого класса, в данном случае SomeList) будут вынесены за пределы класса.


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

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

    Реальный код часто одновременно является и прикладным и оберткой, в этом случае он должен пользоваться обертками для всех ситуаций, кроме тех, которые он оборачивает.
    ... << RSDN@Home 1.1.2 stable >>
    Re[32]: Мэйнстрим vs. Самосовершенствование :)))
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 03.11.04 22:06
    Оценка: +1 -1
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Хорошо. Вот несколько примеров. Очень интересно, в соответствии с "правильным мышлением", методами какого класса являются указанные функции, и почему (если на все "правильно мысля" ответить трудно, то хотя бы на самый последний)... Очень интересно при этом также узнать, как принятые решения будут влиять на такую метрику качества ОО дизайна, как зависимости между классами


    А зачем нужна независимость между классами, особенно если учесть, что они базовые и четко детерминированные? Ну, что на практике даст независимость одного втроенного типа от другого? Да и не встроенного.

    ПК>
  • Есть два класса: Date и String. Методом какого класса является функции: 1) преобразования даты в строку; 2) преобразования строки в дату?

    Очень сильно зависит от того как интерпретировать Date (в дотнете он называется DateTime) строку у же давно почти все рассматривают как встроенный тип. По этому наличие в интерфейсе других типов методов преобразования в строку уже никого не спущет. Ну, почти никого. Стало быть метод типа to_s/ToStrong() прекрасно проходит. C Date сложнее. Тут можно считать, что это такой же системный тип и его применение тастолько часто, что удобно иметь его под ругой. С другой стороны можно скзать, что тип вроде DateTime все же не стольк часто используем и метод преобразования в строке хотя и был бы наиболее удобен, но приведет к захламлению строкового класса. В этом случае имеет смысл вынести метод преобразования в отдельный класс. Однако уж если мы работаем с DateTime, то преобразование в строку точно является часто используемой операцией.

    Тут можно применить некий компромисный подход. Можно реализовать метод конвертации в строку как экземплярный метод класса DateTime, а образтное преобразование поместить в статический метод DateTime. Собственно по этому пути пошли дотнетчики. В классе DateTime имется методы Parse, преобразующие строку в дату.

    Однако ребатки из МС все же дадумались реализовать специальный интерфейс для IConvertible позволющий преобразовывать стандартные типы универсальным обрзом. К сожалению реализация этого интерфейса не выведена наружу. Но если очень хочется можно воспользоваться приведением. Опять же в дело вступает ООП со вторым своим принципом — полиморфизмом:
    // Вариант с динамической типизацией
    static DateTime ToDateTime(object obj)
    {
        return ((IConvertible)obj).ToDateTime(null);
    }
    
    static string ToString(object obj)
    {
        return ((IConvertible)obj).ToString(null);
        // или: return obj.ToString();
    }
    
    // Вариант со статической типизацией в C# 2.0
    static DateTime ToDateTime<T>(T value) where T : IConvertible
    {
        return value.ToDateTime(null);
    }
    
    static string ToString<T>(T value) where T : IConvertible
    {
        return value.ToString(null); // IConvertible.ToString(IFormatProvider)
    }
    
    static void Main(string[] args)
    {
        Console.WriteLine(ToDateTime("01.02.2004").AddYears(2));
        Console.WriteLine(DateTime.Parse("01.02.2004").AddMinutes(10));
    }


    Кроме того имеется класс Convert туевой хучей методов, но они уже не примитивный парсинг или первед в строку, а довольно сложный и интеллектуальный конвертер иногда делающий дополнительные неявные приведения типов и т.п.


    ПК>
  • Методом какого класса является функции преобразования: 1) целого в строку; 2) строки в целое? Есть ли какое-либо отличие этого примера от предыдущего?

    Опять же, и строки и целые встроенные типы. И желательно было бы иметь экземплярные методый в обе стороны. Но у дотнетчиков тут начинаются комплексы по поводу переполнения интерфейса. По этому конвертацию в строку они сделали удобно и интуитивно, а вот в обратную сторону опять таки вточности так же как с датой.

    ПК>
  • Есть два класса: Date и DateDifference. Методом какого класса являются функции: суммы/разницы двух дат, суммы/разницы двух DateDifference, суммы Date и DateDifference?

    Сумма двух дат это полный бред, а разница совершенно нормальное явление. Собственно разница и есть то что ты называешь DateDifference. В дотнете это называется TimeSpan. Совершенно интуитивно понятно, что работать в этом случае удобно (а значит нужно) с помощью перегруженных операторов. Честно говоря где объявлены эти операторы мне по барабану. Главное чтобы они не были объявлены глобальными функциями

    Пошел... глянул как осбтоят дела в дотнете. Операторы DateTime/TimeSpan и DateTime/DateTime объявлены в классе DateTime. Операторы TimeSpan/TimeSpan в классе TimeSpan. DateTime/TimeSpan можно было бы разместить где и в TimeSpan, а DateTime/DateTime физически нелзя разместить в чужом классе (намеренные ограничения языка).

    ПК>
  • Есть классы: Matrix и Vector. Методами какого класса являются функции: 1) умножения матрицы на вектор (результат — матрица); 2) умножения двух векторов по схеме "строка на столбец" (результат — матрица); 3) скалярного умножения векторов (результат — число); 4) афинных трансформаций вектора в соответствии с заданной матрицей преобразования?

    Пусть о Matrix и Vector голова болит у тех кто занимается математикой. Думаю, что рзницы с теми же DateTime/TimeSpan особой нет.

    ПК>И, наконец:


    ПК>
  • Есть классы, контролирующие размерность: Velocity (v, скорость), Acceleration (a, ускорение), Length (l, длина), Time (t, время). Методами каких классов являются функции, соответствующие следущим выражениям: 1) l = v * t; 2) v = l / t; 3) v2 = v * v; 4) a = v / t; 5) v = a * t; 6) t2 = t * t; 6) l = 1 / 2 * a * t * t

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

    Вот, кстати, хорошим прмером являются методы AddXxx из того же дотнетного DateTime-а:
    public DateTime Add(TimeSpan value);
    public DateTime AddDays(double value);
    public DateTime AddHours(double value);
    public DateTime AddMilliseconds(double value);
    public DateTime AddMinutes(double value);
    public DateTime AddMonths(int months);
    public DateTime AddSeconds(double value);
    public DateTime AddTicks(long value);
    public DateTime AddYears(int value);

    конечно без проблем было бы вынести это дело в отдельные функции. Но это было бы неудобно и приводило бы к возможности случайного неверного использования. Не создавать же для минут, секунд, часов и т.п. отдельные типы данных? Или не заниматься явной конвертацией этих понятий в TimeSpan? Когда я вызвают данне методы у экземляра даты, я прекрасно понимаю, что делаю и мои действия идут четко в конве моего мышления. Если же я вынесу их в глобальные функции, то я срузу получу:
    1. Жутчайшее неудобство поиска этих функций. На практике это приведет к тому, что многие их просто ненайдут и, в итоге, напишут собственные реализации (обычно более кривые).
    2. Мышление в привычных мозгу терминах и понятиях (добавить к дате временной срез, вычесть и даты другую...).
    3. Меньшую длинну имени функции, так как AddYearsToDateTime. Ну, или имена приводящие к неверному использованию этих методов.

    При этом я не вижу ни одного минуса у данного подхода в данном случае. И не нужно тут петь про наследование и т.п. Это, во-первых, не проблема (придуманная проблема не существующая в реальной жизни), а во-вторых, DateTime — это структура от котрой нельзя наследоваться.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
  • http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[21]: Мэйнстрим vs. Самосовершенствование :)))
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 07.11.04 13:32
    Оценка: -1 :)
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Называлась только ориентировочная дата, 2008 год.


    Гы. К этому моменту МС и Сан еще по ревизии языка произведут. Ох боюсь этот стандарт к тому времени уже мало актиульным станет.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[26]: Мэйнстрим vs. Самосовершенствование :)))
    От: Undying Россия  
    Дата: 01.11.04 20:57
    Оценка: 36 (1)
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>+1. Я только хотел подчеркнуть, что, с моей точки зрения, общим подходом должно быть принятие подобных решений в частном порядке. И иногда, учитывая все за и против, прибегать к более сложным паттернам, а не просто ограничиваться наследованием и "ужирнением" интерфейсов (interface bloat), "пытаясь писать в ОО-стиле".


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

    ПК>В качестве одного из предусловий я упомянул, что код, использующий классы, разработчиками напрямую не контролируется. Соответственно, к изменению семантики некоторой функции в библиотечном классе я отношусь крайне настороженно, представляя последствия замены использования в методе Array.sort() функции stable_sort() (сохраняющей порядок "одинаковых" элементов) на более быструю (в некоторых случаях) quick_sort()... В этих условиях, имхо, изменение семантики как раз совершенно недопустимо.


    Название функции должно однозначно определять то, что она делает, т.е. если функция называется Sort, то использование ее в качестве StableSort, даже если она в текущий момент действительно реализует сортировку сохраняющую порядок элементов, является хаком, а при использовании хака не нужно удивляться, если он отвалится в следующей версии.

    ПК>Да и в других случаях, когда весь код в нашем распоряжении, мы далеко не всегда готовы проводить анализ всех использований, необходимый для подобных "молчаливых" изменений семантики базовых компонент. Я бы скорее согласился, если бы были изменены места, где используется данный класс.


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

    ПК> Естественно, если все было спроектировано на совесть, дублирования аналогичных вызовов Array.sort быть не должно, т.к. доступ к некоторому Array должен контролироваться одним классом, и, соответственно, в данном классе, представляющем абстракцию уровня кода приложения, изменять семантику подобных методов вполне допустимо. Воздействие таких изменений, в отличие от правки общих компонент, ограничены и предсказуемы, т.к. соответствующая сортировка привязана к контексту, и ожидания от нее хорошо известны.


    Вот это не понял, можно пояснить мысль примером.

    ПК>Ну, со своей стороны могу также точно заверить тебя, что пользоваться обобщенными алгоритмами, не привязанными к конкретным коллекциям, не менее удобно. В некотором роде, при последовательном развитии этого подхода, это становится даже ближе к функциональному программированию, так модному нынче на РСДН


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

    ПК>Ага. А теперь представляем ситуацию, что часть ArrayList'ов мы получаем в "готовом" виде, из библиотечных функций, а часть, своих оберток, создаем сами... Боюсь, в результате, работать по-разному с по-сути одинаковыми контейнерами будет не очень удобно. Впрочем, здесь каждый сам для себя выбирает...


    Не понял в чем проблема и зачем с ними по разному работать? Естественно у обертки есть конструктор принимающий ArrayList, соответственно преобразование в обертку производится одной строчкой: new Wrapper(arrayList).

    ПК>Я придерживаюсь концепции, рекомендующей по умолчанию помещать методы в класс, являющий субъектом, а не объектом действия, предоставляя в объекте достаточный для реализации намерений субъекта интерфейс. В частности, возвращаясь к твоему примеру, мы говорим: "(Мы) толкнем шарик с силой F" (скорее, даже: "Передать шарику импульс P") Но это уже софистика, т.к. в том, что у шарика неизбежно будет какой-то метод, принимающий воздействие, ты, естественно, прав.


    Но "Мы" опять же объект, а не функция.

    ПК>P.S. Кстати, хорошую аналогию ты подобрал. Представим, что нам часто приходится катать шарик по кругу. С моей точки зрения функция go_round интерфейсу шарика не принадлежит, являясь наглядным примером вспомогательного алгоритма, который стоит реализовать через "основной" интерфейс "шарика" (accept_impulse etc.).


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

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

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


    Т.е. рефакторинг ты не используешь? Т.к. рефакторинг как раз означает модифицирование кода с целью уменьшения имеющихся хаков (в частности "лишних" наследований) к минимуму.
    ... << RSDN@Home 1.1.2 stable >>
    Re[4]: Oberon???????????????????????????????????
    От: Kluev  
    Дата: 20.10.04 12:55
    Оценка: 21 (1)
    Здравствуйте, LaptevVV, Вы писали:

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


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


    K>>На питоне надо новичков учить. Прост как три копейки и в командном режиме может работать как калькулятор.

    K>>Более того в джаве только классы, а в питоне можно и с функций начать.
    LVV>Спасибо за идею. Литературу не подскажете, чтоб на любуду не отвлекаться.

    В качестве примера кодец на питоне:

    >>> for i in range(10) : print i
    
    0
    1
    2
    3
    4
    5
    6
    7
    8
    9
    >>>


    Выполняется прямо в командной строке без компиляции, написания функции и т.п. ИМХО если учить то лучше питона не найти
    Re: BlackBox
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 20.10.04 13:54
    Оценка: 21 (1)
    Здравствуйте, LaptevVV, Вы писали:

    LVV>Почитал я тут защитников Оберона, и задумался. Надо первачков учить.


    Слава богу!

    Смотрите проект Информатика 21

    http://www.inr.ac.ru/~info21/

    Цели проекта

    Помочь преподавателям вузов и школьным учителям информатики поднять обучение программированию до уровня сформировавшейся к началу XXI века стандартной парадигмы программирования, представленной системами Оберон/Компонентный Паскаль, Java и C#.

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

    Помочь оформиться растущему стихийному интересу к технологиям Оберона в преподавательских, научных и профессиональных программистских кругах с целью их внедрения в систему образования в России и на пост-советском пространстве, с тем чтобы способствовать достижению стратегической цели — созданию эффективной системы преподавания современного программирования, дополняющей и развивающей существующую уникальную систему преподавания математики


    Самая академически выверенная версия Оберона на сегодняшний день есть Component Pascal. Реализация среды разработки под Windows от Oberon Microsystems среда называется BlackBox. Она совсем недавно стала бесплатной. Скачивать отсюда:

    http://www.oberon.ch/blackbox.html

    У info21 есть русификатор BlackBox-а, так что можно программы писать прямо на русском языке.

    Для более-менее начала серьезного знакомства гляньте сюда

    http://cern.ch/oberon.day

    В разделе Presentations особо гляньте на доклад:

    C. Pfister (Oberon microsystems)
    BlackBox: An Industrial-Strength Oberon Implementation
    http://cern.ch/oberon.day/talks/pfister.pdf

    Там хвастаются как на этом самом BlackBox написано ПО для ЭЛЕКТРОСТАНЦИИ!!!


    Форумы где можно пообщаться:

    http://progz.ru/forum/viewforum.php?f=49&amp;sid=1b298709ca8f03f474379a8a4b76f943
    http://www.delphikingdom.com/asp/talktopic.asp?ID=285
    http://qnxclub.net/modules.php?name=Forums&amp;file=viewforum&amp;f=14&amp;sid=2b25169c0d44448ddeb4180d614e9c7d
    Re[24]: Мэйнстрим vs. Самосовершенствование :)))
    От: Undying Россия  
    Дата: 30.10.04 14:27
    Оценка: 18 (1)
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Еще больше в "классическом ООП" принято "пинать" за работу непосредственно с классом, а не через какой-либо интерфейс.


    Согласен.

    ПК> Соответственно, если поступать по канонам, то в приведенном примере иерархию нужно будет чуть-чуть усложнить:

    ПК>
    ПК>interface Sequence<T>;
    ПК>interface RandomAccessSequence<T>;
    ПК>interface List<T> : Sequence<T>;
    ПК>interface Array<T> : RandomAccessSequence<T>;
    ПК>class ListImpl<T> : List<T>;
    ПК>class ArrayImpl<T> : Array<T>;
    ПК>

    ПК>соответственно, т.к. клиентам классы ListImpl<T> и ArrayImpl<T> не видны, добавить что-либо типа sort() мы можем только начиная с уровня List<T> или Array<T>, которые конкретными классами не являются, и добавление чего-либо в эти интерфейсы приводит к тем же проблемам, что были рассмотрены при модификации Sequence<T>.

    Никто не мешает добавить интерфейс ISort и использовать множественное наследование интерфейсов. Но тут понятно есть другая проблема, что в общем виде на каждую комбинацию наследуемых интерфейсов нам нужно иметь свой обобщающий интерфейс, т.е. всего лишь при 4 базовых интерфейсах нам может потребоваться аж 11 обобщающих. В этом пожалуй главный недостаток такого подхода. Его бы можно было нивелировать, если разрешить такое задание типов: IList&IEnumerator&ICollection, но почему-то пока такие конструкции в языки не вводят.

    ПК>Дык, это уже речь пошла о каких-то более специализированных классах, не столь универсальных, как стандартные Array, List etc. В этих специализированных классах, для которых сортировка является не "утилитой", а основным поведением, сам байт велел делать функцию sort() членом.


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

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


    Я могу с тобой согласиться, что решение с добавлением Sort'а в коллекции является не совсем концептуально чистым (прежде всего из-за использования реализаций классов, а не минимально нужного набора интерфейсов — в статичном Array.Sort в частности), но пользоваться этими коллекциями очень удобно, так как концептуальная нечистость мешает только в том случае, если мы собираемся использовать свои альтернативные реализации коллекций, а на практике это практически не встречается.

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


    Тогда поддерживаю, по сей практике проехаться дело святое.

    U>>Можно для них ввести дополнительный интерфейс и реализовывать его будут только те классы, которым это действительно надо.


    ПК>А что мы будем делать, когда нам понадобится новый "универсальный" алгоритм (скажем, partial_sort), которого в стандартном Array нет? Все равно, рано или поздно, мы придем к тому, что нам будут нужны "внешние" по отношению к классу "утилиты".


    Здесь зависит от отношения количества универсальных алгоритмов к частоте их использования. Если алгоритмов много, но применяются они редко, то внешние методы скорей всего оптимальное решение, если же они применяются сплошь и рядом, то лучше всего будет сделать обертку над тем же ArrayList'ом, которая в том числе будет реализовать и эти дополнительные алгоритмы через какой-нибудь интерфейс.

    U>>Тебя чем не устраивает связка статичные функции + инкапсулирование вызовов этих функций методами класса?


    ПК>Методами какого класса, унаследованного от "библиотечного"?


    Методами класса реализующего в том числе интерфейс библиотечного.

    ПК>"Внешние"/статические функции меня устраивают. Я только не вижу оснований делать к ним переходники в виде членов класса, пока это поведение не становится ключевым для рассматриваемых объектов. В частности, сортировка или поиск "универсальных" массивов и списков, на мой взгляд, к таковым не относятся.


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

    ПК>Безусловно. Поэтому надо смотреть в каждом конкретном случае исходя из назначения класса, а не безусловно пихать все подряд нужные "утилиты" в виде членов класса, наравне с "основными" функциями класса. Тем более, выбор того, делать ли некоторую функцию членом класса, не должен базироваться на том, как на это дело смотрит Intellisence ("любой дурак нажав точку в IDE получит их список")


    Но фактор Intellisence при этом не нужно сбрасывать со счетов при принятии решения.
    ... << RSDN@Home 1.1.2 stable >>
    Re[31]: Мэйнстрим vs. Самосовершенствование :)))
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 03.11.04 09:14
    Оценка: 16 (1)
    Здравствуйте, Павел Кузнецов, Вы писали:

    >> Дотнет умеет при помощи TransparentProxy, но ценой заметной потери производительности.


    ПК>Ну, уже лучше, чем ничего... В принципе, в динамических языках это давно есть.


    Увы, ценой все той же потери производительности, притом уже везде.

    ПК>Кстати, вопрос: а производительность "просаживается" и в том случае, если вызываемый метод явно определен в делегирующем классе, или только в случае, когда происходит "автоматическое" делегирование? Например:

    ПК>
    ПК>// Класс, которому будем делегировать.
    ПК>class A
    ПК>{
    ПК>   public void a() { }
    ПК>   public void b() { }
    ПК>};
    
    ПК>// Класс, который делегирует
    ПК>class B
    ПК>{
    ПК>   // Явное делегирование
    ПК>   public void a() { a_.a(); }
    
    ПК>   // Какая-то "магия" c TransparentProxy, чтобы остальные методы тоже делегировались.
    ПК>   // . . .
    
    ПК>   private A a_;
    ПК>};
    ПК>

    ПК>Будет ли в данном случае потеря производительности при вызове обоих методов, a() и b(), через интерфейс класса B, или же только при вызове b(), который делегируется неявно?

    TP работает иначе. Класс В создается неявно рантаймом. Один из способов примерно такой:
    MyRealProxy rp = new MyRealProxy(classAInstance);
    ClassA classAWrapper = (ClassA)rp.GetTransparentProxy();


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

    После этого все обращения к методам ClassA будут проходить через вызовы MyRealProxy.Invoke, который может выглядеть примерно так:
    public override IMessage Invoke(IMessage msg)
    {
        IMethodCallMessage mcm = (IMethodCallMessage)msg;
        IMethodReturnMessage rm = RemotingServices.ExecuteMessage(m_Instance, mcm);
        // Some stuff
        return rm;
    }


    Т.е. схема примерно такая — реальная работа по обработке вызовов производится RealProxy, но RP по типам с оборачиваемым классом несовместим. Для совместимости рантайм генерирует специальный псевдообъект — TP, единственная работа которого состоит в трансляции всех вызовов родительскому RP.
    ... << RSDN@Home 1.1.4 beta 3 rev. 219>>
    AVK Blog
    Re[29]: Мэйнстрим vs. Самосовершенствование :)))
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 02.11.04 08:03
    Оценка: 15 (1)
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>(*) Насколько я представляю, большинство статически типизированных языков этого не умеют. Впрочем, я знаком только с более-менее практически использующимися статически типизированными языками, поддерживающими ООП, и не со всеми одинаково хорошо, так что тут могу легко заблуждаться.


    Дотнет умеет при помощи TransparentProxy, но ценой заметной потери производительности.
    ... << RSDN@Home 1.1.4 beta 3 rev. 219>>
    AVK Blog
    Re[3]: Oberon???????????????????????????????????
    От: Tan4ik Россия  
    Дата: 29.10.04 08:04
    Оценка: 14 (1)
    Здравствуйте, LaptevVV, Вы писали:

    LVV>>>Кстати, какие альтернативы оберону есть, кто-нить представляет?

    V>>Java? На ней олимпиады проводятся?
    LVV>Нет, не проводятся.
    Java — давно один из официальных языков ACM World Finals. На полуфинале он также есть. Четвертьфиналы немного отстают, но, я думаю, что скоро и на них он станет доступным (у нас желающих особо не было, вот и не стали заморачиваться).

    LVV>Это конечно мысль. Или еще можно С# попробовать. Но хотелось бы не Сишного синтаксиса — для алтернативы.

    Стоит пробовать. Студенты должны выходить подготовленными к жизни (если учатся на программистов). Хотя бы поверхностные знания основных промышленных языков вуз просто обязан дать (сейчас C++, C#, Java, возможно VB, что-то забыл?).

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

    P.S. Чтобы не били ногами, ко всем фразам нужно приписать ИМХО
    ---
    С уважением,
    Лазарев Андрей
    Re[3]: Oberon???????????????????????????????????
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 21.10.04 19:03
    Оценка: 10 (1)
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Оберон не мертвяк, то что Вы о нем ничего не знаете говорит о Вас и только о Вас.


    Мертвяк. Причем чистейший воды. Ни одного комерческого проекта.

    СГ>Ява и Шарп хуже Оберона тем, что Оберон проще


    Простота должна иметь разумные пределы.

    СГ>, чище


    Вот это уже неправда.

    СГ> и меньше и в то же время он полный, в смысле, достаточный современный объектно ориентированный


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

    СГ>модульный


    А типа Ява и Шарп не модульные.

    СГ>императивный язык общего назначения со строгой статической типизацией


    Ага. Ну, просто "он один такой".

    СГ> и встроенными механизмами безопасности (проверка индексов, правильное приведение типов, сборка мусора).


    Ага. Ну, куда там той же Яве и Шарпу до него?

    СГ>О превосходстве оберонов над Явой на ее родном поле боя — в интернете, можно почитать там:

    СГ>http://www.uni-vologda.ac.ru/oberon/
    СГ>[q]
    СГ>Juice-технология

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

    СГ>Летом 1996 года профессором Калифорнийского университета в Ирвине, учеником Н.Вирта Михаэлем Францем и его аспирантом Томасом Кистлером была представлена технология распространения исполнимого кода в Интернет, названная авторами Juice (по-русски — сок). Juice основан на использовании Оберона и влючает с одной стороны инструментальную компоненту для Оберон-системы Oberon System 3, обеспечивающую компиляцию написанных на Обероне модулей в платформно-независимое представление. Второй частью Juice является дополнение (plug-in) к Интернет-браузерам, обеспечивающее компиляцию получаемого Juice-кода "на лету" в родной код, его загрузку и исполнение.


    Вот этими самыми пресрелизами все эти соки и заночилсь. Как раз в том самом 96-ом.

    СГ>Juice превосходит Java-технологию во всем кроме величины затрат на рекламу:


    СГ>1) Основан на более простом и совершенном языке


    Гы-гы. Совершенство еще то.

    СГ>2) Обеспечивает существенно большую скорость исполнения аплетов


    Два раза Гы-гы. Раскажи это тем кто не запускал ХотСпот. И вообще судить по 96-му году очень забавно.

    СГ>3) Код Juice-аплета компактнее байт-кода Java


    И как Ява живет со столь ужасно распухшим байткодом? Он же всего в двое компактнее аналогичного х86 кода?!

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

    Развитие Оберона с 96 года нет. Ява же бурно развивается и в основном в правильную сторону. Возможно в ней до сих пор хватает недочетов. Но это проверенный практикой язык (и технология). Она более чем пригодна для обучения. Так что не нужно запудривать людям мозги мертвятиной вроде Оберона. Им все же в будущем программы писать. И на не гипотетических языках. А на реальных.
    ... << RSDN@Home 1.1.4 beta 3 rev. 206>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[33]: Мэйнстрим vs. Самосовершенствование :)))
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 03.11.04 09:45
    Оценка: 10 (1)
    Здравствуйте, prVovik, Вы писали:

    V>1) Можно ли этот ТР использовать для своих нужд, то есть не только для ремотинга?


    Можно. Хотя "не для ремоутинга" не очень корректно говорить, поскольку TP это собственно ремоутинг и есть. Есть даже специальная штука для его использования в собственных нуждах в пределах одного домена — ContextBoundObject.

    V>2) А как оно работает? Через рефлекшн + эмит?


    Что именно? Если вызов метода закрываемого класса, то по дефолту рефлекшен, хотя ты можешь придумать что то свое. Если трансляция в TP, то это unmanaged stub, даже джитом не обрабатываемый.
    ... << RSDN@Home 1.1.4 beta 3 rev. 219>>
    AVK Blog
    Re[7]: вопрос знатокам SmallTalk
    От: Poisson Россия  
    Дата: 25.10.04 17:18
    Оценка: 6 (1)
    Здравствуйте, lesha-v, Вы писали:

    LV>Здравствуйте,

    LV>Решил я посмотреть на SmallTalk... скачал VisualWorks7.2.1, установил...
    LV>аа шрифт в диалогах прочитать не возможно что делать, подскажите ? неужели так и не удасться познакомиться со смолтолком...
    Да, есть там такая милая бага (проявляется с русской локалью).

    Лечится так: значение (не помню какое) в WinXPLookPolicy class>>defaultSystemFontScale надо заменить на 0.8 или в WinXPLookPolicy class>>defaultSystemFontDescription заменить 'arial' на 'arial*'
    ... << RSDN@Home 1.1 beta 2 >>
    Re[9]: Мэйнстрим vs. Самосовершенствование :)))
    От: serg_mo  
    Дата: 29.10.04 11:13
    Оценка: 6 (1)
    Здравствуйте, eugals, Вы писали:

    E>Драгдилер, блин

    E>по $350 за коробан гребёт
    Есть такое

    E>Смолток хороший язык, что меня в нем смущает, так это доступность реализаций.


    E>Под C++ есть куча компиляторов. Есть бесплатный gcc. Есть опенсорсные среды разработки. Море библиотек.

    E>У шарпа, кроме него самого, есть моно и дотгну.
    E>У питона есть питон.
    E>А что со смолтоком? gnusmalltalk, насколько я вижу, ни жив ни мерт
    E>Есть конечно VW NС, но это дело такое — сегодня они его поддерживают, а завтра бросят...
    E>Стремно как-то основывать долгоживущие разработки на такой основе.
    E>Даже если честно купить коробку, всё равно стрёмно. Вдруг они завтра разорятся (продажи-то небольшие, небось).
    Черт их знает, говорят, что у них все тип-топ. Ну а как дела обстоят на самом деле, никто не знает. Конечно, риск существует. Но, с другой стороны, этот риск существует всегда при использовании коммерческих продуктов. Та же Delphi. Та же Java, мне кажется — перестанет вдруг Сан ее развивать, и ага. Да что уж говорить, такой риск существует и при покупке сторонних библиотек.

    E>А как обстоит дело с совместимостью?

    E>Насколько реально перевести крупный проект с VW на Dolphin или обратно?
    Я не занимался, но мне кажется, что будет довольно сложно. Хотя тут зависит от специфики проекта, конечно. Например, UI придется, видимо переделывать заново, т. к. у Долфина и VW фреймворки построены на различных концепциях. Также, VW намного богаче в плане разработки распределенных приложений, Web-приложений.
    ... << RSDN@Home 1.1.3 stable >>
    Re[9]: Мэйнстрим vs. Самосовершенствование :)))
    От: faulx  
    Дата: 15.11.04 09:00
    Оценка: 5 (1)
    Здравствуйте, eugals, Вы писали:

    E>А что со смолтоком? gnusmalltalk, насколько я вижу, ни жив ни мерт

    E>Есть конечно VW NС, но это дело такое — сегодня они его поддерживают, а завтра бросят...
    E>Стремно как-то основывать долгоживущие разработки на такой основе.
    E>Даже если честно купить коробку, всё равно стрёмно. Вдруг они завтра разорятся (продажи-то небольшие, небось).
    E>Или продадутся какому-нибудь SUN-у (как с Self-ом было).
    E>А как обстоит дело с совместимостью?
    E>Насколько реально перевести крупный проект с VW на Dolphin или обратно?

    Seaside переносили со squeak на VW, здесь есть описание. Кажется, вполне реально.

    Кстати, Seaside — очень любопытная штука, я и Smalltalk смотрел только из-за него.
    Re[2]: Обновление
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 26.10.04 08:44
    Оценка: 3 (1)
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, LaptevVV, Вы писали:


    LVV>>Почитал я тут защитников Оберона, и задумался. Надо первачков учить.


    СГ>Смотрите проект Информатика 21


    СГ>http://www.inr.ac.ru/~info21/


    Сегодня сайт проекта Информатика 21 был серьезно обновлен. Заходите смотрите.

    Основная новость: к концу 2004 года ожидается открытие исходного кода BlackBox.
    Re[21]: Читайте хелп
    От: Mamut Швеция http://dmitriid.com
    Дата: 31.10.04 09:51
    Оценка: 2 (1)
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, Mamut, Вы писали:


    M>>...невозможно работать.


    СГ>Из приведенного рисунка видно следующее:


    СГ>1) Вы зачем-то засунули в Log текст программы и пару контролов... Log — предназаначен для вывода сообщений.


    Log вообще не должен позволять в нем хоть что-то писать. Лог вообще не должен что-либо делать, кроме как показывать диагностические сообщения. Это Log

    СГ>2) Для того чтобы написать свою программу нужно создать новый документ.


    Предположим. В этом случае мне не видно Log, ошибки все равни выводятся в тексте программы. А это неочевидно и неинтуитивно Если текст программы не вмещается в экран? А из-за идиотского расположения окон он не будет никогда, то мне что, весь текст программы сканировать на предмет наличия ошибок? А что мне с ошибками потом делать? Стирать их, или они не влияют на компиляцию? То, что они не влияют на компиляцию неочевидно, так как они торчат прямо посреди текста и нарушают восприятие программы

    СГ>3) Контролы, вообще-то, принято помещать на формы.


    Контролы, вообще-то, не принято вставлять внутрь исходного кода программы.

    А как создается новая форма? Controls -> New form? Что такое Link? Ладно, лезем в желп, жмем Empty. А дальше? Боже! Это — визуальная среда? В коммандной строке и то информативности больше.


    Вердикт. Oberon Microssystems наткнулась на книжицу "MFC in 21 days" и сейчас показывает нам, чему они научились. Сам такие поделки еще в прошлом году создавал (это я о среде BlackBox). Не удивлюсь, если сериализация/десериализация у них стандартными средствами MFC выполнена. И вы не поверите, но на исходники BlackBox я даже смотреть не буду. Повторяю, такие поделки выполняются на коленке в течение ... ну ... двух-трех часов. Ну и, возможно, час планирования.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>


    dmitriid.comGitHubLinkedIn
    Re[29]: Мэйнстрим vs. Самосовершенствование :)))
    От: prVovik Россия  
    Дата: 01.11.04 17:05
    Оценка: 2 (1)
    Здравствуйте, AndrewVK, Вы писали:

    AVK>О! Осталось только понять что многие алгоритмы сортировки требуют доступа к внутренним структурам

    Вот для контейнеров, сортировка которых действительно требует доступа к внутренней структуре ее, конечно, надо делать внутренним методом.
    Для всего остального подойдет внешний обобщенный алгоритм сортировки типа std::sort()
    ... << RSDN@Home 1.1.4 @@subversion >>
    лэт ми спик фром май харт
    Re[22]: Обновление
    От: Kh_Oleg Германия http://kholeg.wordpress.com
    Дата: 02.11.04 12:04
    Оценка: 2 (1)
    Здравствуйте, Зверёк Харьковский, Вы писали:

    ЗХ>Тем хуже для оберона. Набирать ключевые слова большими буквами противоестественно (все время зажимать шифт или дергать капс лок). Костыли, встроенные в BlackBox (клавиатурная комбинация для смены регистра последнего слова) — всего лишь костыли.

    ЗХ>Об этом при проектировании языка никто не задумался?

    Да фиолетово Оберону. В IDE для языка Modula-2 от фирмы TopSpeed ключевые слова поднимались в верхний регистр при нажатии на пробел после ключевого слова. Поскольку почти всегда после ключевого слова требуется пробел, то это происходило автоматически и было очень удобно.

    Кстати, в Zonnon'e изначально ключевые слова тоже были в верхнем регистре, но потом синтаксис пересмотрели и решили, чтоб они были в нижнем.
    Re[5]: Oberon???????????????????????????????????
    От: Poisson Россия  
    Дата: 21.10.04 18:12
    Оценка: 1 (1)
    Здравствуйте, Kluev, Вы писали:


    K>>>На питоне надо новичков учить. Прост как три копейки и в командном режиме может работать как калькулятор.

    K>>>Более того в джаве только классы, а в питоне можно и с функций начать.
    Про питон я знаю постольку-поскольку, поэтому дальше просто вопросы, а не придирки.

    — как обстоят дела с GUI? В смысле, насколько легко привязывается интерфейс к коду?
    — есть ли готовые библиотеки распределенного взаимодействия (a la .net remoting)?
    — как дела с IDE? С отладчиком, refactoring browser'ом ну и всем чем полагается.
    — легко ли обеспечить взаимодействие с OS? Если говорить о win32 — использование dll, COM..

    В случае VisualWorks Smalltalk эти вопросы решены на 4-5, а browser/debugger — на 5+.

    K>В качестве примера кодец на питоне:

    >>>> for i in range(10) : print i

    Вот тоже кодец, похожий, на Smalltalk'е =)

    1 to: 10 do: [:each | Transcript show: each]


    K>Выполняется прямо в командной строке без компиляции, написания функции и т.п. ИМХО если учить то лучше питона не найти


    Аналогично, выполняется в Workspace'е, без [явной] компиляции. Однако, в отличие от питона, я могу посмотреть, а что же такое происходит при выполнении этого куска кода. Дело в том что to:do: — это метод класса Number, на исходник котороо можно посмотреть или зайти отладчиком. А show: — метод класса TextCollector, опять-таки все можно посмотреть-потрогать руками и даже изменить. Ну и так далее.

    Вся прелесть смоллтока как языка для обучения в том, что в нем нет ключевых слов вроде for, while, if и т.п. — все ветвления и циклы реализованы за счет стандартного механизма посылки сообщенияй объектам. Browser в руки и вперед.
    ... << RSDN@Home 1.1 beta 2 >>
    Re[6]: Oberon???????????????????????????????????
    От: FR  
    Дата: 21.10.04 21:21
    Оценка: 1 (1)
    Здравствуйте, Poisson, Вы писали:

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



    K>>>>На питоне надо новичков учить. Прост как три копейки и в командном режиме может работать как калькулятор.

    K>>>>Более того в джаве только классы, а в питоне можно и с функций начать.
    P>Про питон я знаю постольку-поскольку, поэтому дальше просто вопросы, а не придирки.

    конечно совершено на придирки не похоже

    P>- как обстоят дела с GUI? В смысле, насколько легко привязывается интерфейс к коду?


    нормально с GUI, доступны tk, wxWindows, Qt, MFC ( ) и WinAPI

    P>- есть ли готовые библиотеки распределенного взаимодействия (a la .net remoting)?


    да

    P>- как дела с IDE? С отладчиком, refactoring browser'ом ну и всем чем полагается.


    скорее на тройку, хотя для интерпретатора это не так важно.

    P>- легко ли обеспечить взаимодействие с OS? Если говорить о win32 — использование dll, COM..


    легко, используя библиотеку PyWin

    P>В случае VisualWorks Smalltalk эти вопросы решены на 4-5, а browser/debugger — на 5+.


    K>>В качестве примера кодец на питоне:

    >>>>> for i in range(10) : print i

    P>Вот тоже кодец, похожий, на Smalltalk'е =)


    P>
    P>1 to: 10 do: [:each | Transcript show: each]
    P>


    по моему как тут уже сказали птичий язык

    K>>Выполняется прямо в командной строке без компиляции, написания функции и т.п. ИМХО если учить то лучше питона не найти


    P>Аналогично, выполняется в Workspace'е, без [явной] компиляции. Однако, в отличие от питона, я могу посмотреть, а что же такое происходит при выполнении этого куска кода. Дело в том что to:do: — это метод класса Number, на исходник котороо можно посмотреть или зайти отладчиком. А show: — метод класса TextCollector, опять-таки все можно посмотреть-потрогать руками и даже изменить. Ну и так далее.


    В питоне тоже почти все можно посмотреть и зайти отладчиком.

    P>Вся прелесть смоллтока как языка для обучения в том, что в нем нет ключевых слов вроде for, while, if и т.п. — все ветвления и циклы реализованы за счет стандартного механизма посылки сообщенияй объектам. Browser в руки и вперед.


    У смолтока очень большой недостаток для целей обучения, он слишком не похож на самые распрастраненые языки.
    ... << RSDN@Home 1.1.3 stable >>
    Re[15]: Oberon???????????????????????????????????
    От: prVovik Россия  
    Дата: 22.10.04 18:14
    Оценка: 1 (1)
    Здравствуйте, VladD2, Вы писали:

    VD>Начальный код можно исполнять и в специльно созданного для этого обертке.

    Но только это уже будет НЕ С#, а получится какой-то свой собственный доморощенный язык
    ... << RSDN@Home 1.1.4 @@subversion >>
    лэт ми спик фром май харт
    Re[7]: Vlad2
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 26.10.04 08:44
    Оценка: 1 (1)
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>А Вы посмотрите вокруг, Вы один тут делаете нападки на Оберон, только Вы один вынесли "однозначное осуждение", остальные находятся либо в нейтралитете, либо не ведут себя так же агрессивно как Вы, либо перестали утверждать что либо по этому поводу так как не считают себя компетентными в этой области.

    Ну, это, мягко говоря, не совсем так.
    СГ>[q]
    СГ>Почитал несколько веток с Вашим участием...
    СГ>У каждой такой "тусовки" есть своя специфика, со своим контИнгентом участников... RSDN в этом отношении — ярчайший и показательный пример. Волею судеб, я оказался вовлечён в работу харьковского семинара по QNX ( http://qnxclub.net ). Наиболее активный наш участник, Olej, захаживал как-то на RSDN, в ветки, посвящённые Юникс-системам и ОСРВ. То, с чем он там столкнулся (уровень знаний, информированность в "сопредельных с виндой областях", а главное — просто-таки параноидальная вера в собственную "правильность" и непогрешимость практически во всех поднимаемых на форуме вопросах), заставило Olej высказать несколько замечаний "по делу". С момента, когда RSDNовские ребята поняли, что их макают носиком в собственные примеры некомпетентности, нас забанили...
    Это не тот ли суперкомпетентный Olej, который критиковал www.TPC.org и утверждал, что прохождение его тестов стоит больших денег, что и сдерживает его гениальных друзей от занимания там первых строчек? А "ветки, посвященные ОСРВ и Unix" — это печально известный флейм Win vs Lin? Ах да, его же забанили за матерные высказывания. Прекрасный у тебя нашелся помощник .
    СГ>В Вашем случае от них "аж прэ" не то, что не понимание поднимаемых вопросов, а нет даже желания вынырнуть из собственного мирка...
    Ну, если бы ты меньше игнорировал "неудобные" тебе аргументы, и следил за логикой своих постингов, а также делал поменьше утверждений о компетентности собеседников — вот тогда подобные заявления еще могли бы снискать популярность. А так все это выглядит не более чем раскидыванием понтов. Да, Влад — человек довольно резкий. Но он говорит дело, и ты зря к нему не прислушиваешься. Доскональное знание Оберона — не критерий. Дыры в твоих рассуждениях видны невооруженным взглядом безо всякого Оберона. Влад же вполне готов вынырнуть из собственного мирка. Вот как раз ты из своего — не готов. Это называется "религиозный фанатизм".
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[7]: Обновление
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.10.04 09:33
    Оценка: 1 (1)
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Как возник этот проект

    СГ>http://www.inr.ac.ru/~info21/kak.htm

    Кстати, слова "по-дилетантски спроектированного" выдают скорее дилетантство писавших статью.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[27]: Component Pascal
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.10.04 13:01
    Оценка: 1 (1)
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Вот напугал. А в Zonnon-е...


    Ну, т.е. согласен что Оберон нужно на помойку отправить?

    ЗЫ

    Что же касается "полезности" перечисленных фич в интефейсе, то это кривой дизайн. Пора бы уже знать почему в интерфейсы не суют определение данных.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[31]: Мэйнстрим vs. Самосовершенствование :)))
    От: prVovik Россия  
    Дата: 02.11.04 23:48
    Оценка: 1 (1)
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Кстати, автоматическое делегирование, фактически, эквивалентно наследованию, минус автоматическое приведение к базовому классу.

    Ну не совсем. Тут ведь вся фишка в том, что делегированного объекта можно в рантайме задавать.
    ... << RSDN@Home 1.1.4 @@subversion >>
    лэт ми спик фром май харт
    Re[3]: Oberon???????????????????????????????????
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 20.10.04 15:06
    Оценка: +1
    Здравствуйте, LaptevVV, Вы писали:

    LVV>Это конечно мысль. Или еще можно С# попробовать. Но хотелось бы не Сишного синтаксиса — для алтернативы.


    ВБ.НЭТ потянет? Сточки зрения простоты синтакиса и отсутствия сишных скобок самое оно. Только логических операций лучше на нем не давать. Они в нем такие же кривые как в Паскле (бен разделения на бинарные илогические).
    ... << RSDN@Home 1.1.4 beta 3 rev. 206>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[6]: Oberon???????????????????????????????????
    От: FR  
    Дата: 21.10.04 06:40
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

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


    K>>Выполняется прямо в командной строке без компиляции, написания функции и т.п. ИМХО если учить то лучше питона не найти


    VD>Разницы с тем же шарпом никакой. Что до компиляции, то нажать на F5 или написать "csc filename.cs" вряд ли окажется проблемой.


    Как раз для обучения разница большая, можно начать с однострочных программ, с обычного процедурного программирования не забивая голову не нужными в начале обучения class и public static void Main()
    ... << RSDN@Home 1.1.3 stable >>
    Re[3]: Oberon???????????????????????????????????
    От: WFrag США  
    Дата: 21.10.04 13:44
    Оценка: +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Ява и Шарп хуже Оберона тем, что Оберон проще, чище и меньше и в то же время он полный, в смысле, достаточный современный

    СГ>объектно ориентированный модульный императивный язык общего назначения со строгой статической типизацией и встроенными
    СГ>механизмами безопасности (проверка индексов, правильное приведение типов, сборка мусора).

    Чище чем Java в каком плане?

    Всякие проверки и сборка мусора есть и в Java. Или ты о чем?

    Рефлекшн, кстати, в нем есть?

    СГ>О превосходстве оберонов над Явой на ее родном поле боя — в интернете, можно почитать там:

    СГ>http://www.uni-vologda.ac.ru/oberon/
    СГ>[q]
    СГ>Juice-технология

    По-моему, родное поле Java — middleware. Апплеты мне попадаются существенно реже, чем, например, stand-alone приложения на Java.

    СГ>Juice превосходит Java-технологию во всем кроме величины затрат на рекламу:


    СГ>1) Основан на более простом и совершенном языке


    Что значит более простой язык?

    СГ>2) Обеспечивает существенно большую скорость исполнения аплетов


    Видимо, за счет some kind Woodoo Magic? Откуда "существенность"-то взялась? Ну или хотя бы ссылочку бы на статистику.

    СГ>3) Код Juice-аплета компактнее байт-кода Java


    Тут ничего не скажу, страничка Juice не открывается.
    ... << RSDN@Home 1.1.4 beta 3 rev. 205>>
    Re[9]: Oberon???????????????????????????????????
    От: FR  
    Дата: 21.10.04 22:45
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

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


    FR>>Угу С# тоже никаких преимуществ перед плюсами не имеет так небольшие фичи


    VD>Это не ответ. А приемущества перед плюсами можно перечислять часами. Хотя это и не избавляет от некоторых недостатков.


    Так у тебя тоже не ответ.
    Любое преимущество можно обозвать отдельными фичами, а можно и часами его перечислять
    ... << RSDN@Home 1.1.3 stable >>
    Re[7]: Oberon???????????????????????????????????
    От: Poisson Россия  
    Дата: 22.10.04 05:10
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    VD>Здается мне, что в Питоне понятнее и логичнее.

    Дело вкуса.

    VD> А смотреть на то как работают операторы и встроенные функции как-то даже в голову не приходит.

    Понятно, что смотреть на устройство какого-нибудь print и увидеть дизассемблированный код, ну или
    даже код на C/C++ (сам питоновсаий интерпретатор вроде на C++ написан?) не очень интересно. Но в случае со смоллтоком мы видим код на том же смоллтоке (где-то в глубине упирающийся, конечно, в вызов примитива VM), что для начинающего очень и очень удобно — есть откуда брать массу полезных примеров.
    ... << RSDN@Home 1.1 beta 2 >>
    Re[6]: Oberon???????????????????????????????????
    От: Kluev  
    Дата: 22.10.04 07:47
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

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


    K>>
    >>>>> for i in range(10) : print i
    K>>


    K>>Выполняется прямо в командной строке без компиляции, написания функции и т.п. ИМХО если учить то лучше питона не найти


    VD>Ну, и чем это отличается от Шарпа:

    VD>
    VD>foreach (int i Range(10))
    VD>    Console.WriteLine(i);
    VD>

    VD>?

    Чем отличается? тем что как уже было сказано:
    K>>Выполняется прямо в командной строке без компиляции, написания функции и т.п.

    А минимальная шарп программа это как минимау класс со статической main к которой среда еще и аттрибут подосовывает. Плюс using, плюс namespace, плюс среда, плюс компиляция. Вообщем не многовато ли для начинающего?
    Re[5]: Oberon???????????????????????????????????
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 22.10.04 08:07
    Оценка: :)
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, VladD2, Вы писали:


    VD>> Мертвяк. Причем чистейший воды. Ни одного комерческого проекта.


    СГ>Вы не компетенты в вопросах об оберонах. Я уже приводил ссылки, среди которых, например, упоминается коммерческий проект создания ПО для ЭЛЕКТРОСТАНЦИИ (не хило не так-ли?), в ссылках сайта info21 есть военный проект по управлению беспилотными летающими аппаратами (опять не хило?).


    VD>> Развитие Оберона с 96 года нет.


    СГ>Мало того что Вы не компетентны в вопросах об оберонах, но Вы еще и просто не внимательны. Совсем недавно, на этом форуме обсуждались "активные объекты". Вы случаем не обратили внимание на фигурирующие в даваемых ссылках даты? Создание Aos ~ 2000 год, диссертация Мюллера 2002 год. Работа над Zonnon идет по сей день.


    СГ>Посмотрите даты проектов: http://www.cs.inf.ethz.ch/gutknecht/


    А ты очень компетентен, прям жуть?
    Вот приведи статистику по числу раб. мест на обероне?
    Хотябы в Швейцарии есть такие вообще?
    Возьми теперь и сравни даты, числа и объёмы с тем же C#, да я думаю даже со смолтолком оберон будет очень хило выглядеть (эй смолтолковцы, замолвите словечко )
    Re[7]: Oberon???????????????????????????????????
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 22.10.04 14:09
    Оценка: -1
    Здравствуйте, Kluev, Вы писали:

    K>Чем отличается? тем что как уже было сказано:

    K>>>Выполняется прямо в командной строке без компиляции, написания функции и т.п.

    Это не приемущество. Во-первых, это на фиг не упало. А, во-вторых, создать утититку эмулирующую командрую строку задача на вечер.

    K>А минимальная шарп программа это как минимау класс со статической main к которой среда еще и аттрибут подосовывает. Плюс using, плюс namespace, плюс среда, плюс компиляция. Вообщем не многовато ли для начинающего?


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

    В общем, это все не серьезные аргументы. А вот то отсуствие типов сильно попортит восприятие у начинющих. Типы концепция обязательная. Без нее еще ту кашу можно создать.
    ... << RSDN@Home 1.1.4 beta 3 rev. 206>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[8]: Oberon???????????????????????????????????
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 22.10.04 14:09
    Оценка: +1
    Здравствуйте, FR, Вы писали:

    FR>Точно из питона сперли


    Питона еще на свете не было когда в ВБ for each появился.

    FR>В питоне for помощнее он может работать с любыми итераторами.


    Гы-гы. С какими итераторами не сможет работать foreach из Шарпа? А дельфийский как раз с него слизан по повду перехода дельфи под дотнет.
    ... << RSDN@Home 1.1.4 beta 3 rev. 206>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[6]: Oberon???????????????????????????????????
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 22.10.04 15:34
    Оценка: :)
    Здравствуйте, VladD2, Вы писали:

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


    S>> То есть ты видишь разницу между побитовыми и булевыми операциями????


    VD>Ага. Причем мне откровенно жать тех кто ее не видит.


    VD>Вот простенькие примеры:

    VD>
    VD>if (a == b && b < c)
    VD>    ...
    VD>

    VD>И такой же код на Паскле:
    VD>
    VD>if a = b and b < c then
    VD>    ...
    VD>



    Твое отношение к скобкам известно. Мне лично не нравятся приоритеты особенно в длинных выражениях.
    Зачем нуэно разграничение операторов если их применение зависит от типа?????
    Плодить никому ненужные сущности????

    VD>выглядят одинаково? А смысл совершенно разный. Смысл пасклая бует таким:

    VD>
    VD>if ((a == (b & b)) < c)
    VD>    ...
    VD>


    Это бред для любого языка. Сравнивать булевы величины с числовыми.
    С точки зрения представления в байтах это роли не играет. Но bool, wordbool итд выглядят по разному.
    0 true -1 false. А в некоторых языках интерпретирутся false==0, true<>0.

    VD>что несоменнео бред для этого языка. Так что прийдется сувать скобки и провкрки:

    VD>
    VD>if (a = b) and (b < c) then
    VD>    ...
    VD>


    Вот правильный аналог твой записи.
    при int a,b,c.
    if integer(a = (b and b))<c then

    VD>Ну, а если результаты битовых операций нужно логически проверить, то проблемы могут полезть изо всех щелей.


    VD>Собственно разница между битовыми операциями и логическими очень важна и полезна. Она позволяет писать более чистый коди и обезопасить программиста от ошибок еще на стадии компиляции.


    Все и так безопасно за счет типизации.

    S>> И представление булевых переменных в битовом представлении???

    смотри выше.
    VD>Ну, что ты тут попытался сказать я так и не понял.

    S>> В Delphi (Паскале) ты можешь применять те или иные операции основываясь на их типе.


    VD>Нда. Причем тут это?


    Все при том же. Ты не сможешь приенить битовые операторы к булевым и булевы к небулевым.
    S>> Без приведения к булевому типу
    S>> Меня лично в c# бесит это разграничение.

    VD>C# не для тебя. Он для тех кому дороги слова типобезопасность и для тех кто не будет уродовать код ради лишней милисикунды.

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

    Ну Паскаль всегда был типобезопасным в отличие от некоторых языков, Иногда правда и во вред.
    Но любые ограничения легко обходятся.
    S>> Так что кривизна больше не в Паскале.

    VD>Твоме мнение о "кривизне" мне извесно. Боюсь с ним будет несогласно большинство приличных программистов.

    Ага в Яве и C# болше влияния Delphi (Паскаля) нежели C++.
    (Всетаки Delphi был раньше Явы)
    и солнце б утром не вставало, когда бы не было меня
    Re[7]: Oberon???????????????????????????????????
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 22.10.04 20:44
    Оценка: :)
    Здравствуйте, Serginio1, Вы писали:

    S> Твое отношение к скобкам известно. Мне лично не нравятся приоритеты особенно в длинных выражениях.


    Приоритеты тут в общем-то не причем. Хотя они тоже вещь полезная.

    VD>>выглядят одинаково? А смысл совершенно разный. Смысл пасклая бует таким:

    VD>>
    VD>>if ((a == (b & b)) < c)
    VD>>    ...
    VD>>


    S> Это бред для любого языка. Сравнивать булевы величины с числовыми.


    Знаток, блин... Надыбай компилятор С++ определи переменные с типом int и поробуй скомпилировать. Уверяю тебя, что все скомпилируется без проблем.

    В общем, ты меня извини. Но нехочу я с тобой осбуждать вопросы безопасного программирования. Ты его в принципе не признаешь.

    S> Все при том же. Ты не сможешь приенить битовые операторы к булевым и булевы к небулевым.


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

    VD>>C# не для тебя. Он для тех кому дороги слова типобезопасность и для тех кто не будет уродовать код ради лишней милисикунды.

    S> А ты помнишь песню "Есть только миг между прошлым и будущим, именно он называется жизнь".
    S> Все в этом мире относительно.



    S> Ну Паскаль всегда был типобезопасным в отличие от некоторых языков, Иногда правда и во вред.


    Паскаль то может и был. А вот Дельфи никгда. Там типобезопасность очень быстро порезализ для производственных нужд. Оно и понятно. Жизнь есть жинь. Но разум то нужно иметь...

    S> Но любые ограничения легко обходятся.


    А, ну, вот пусть фанаты и обходят. А детей учить на этом убожище не стоит.

    S> Ага в Яве и C# болше влияния Delphi (Паскаля) нежели C++.


    Ага. Ну, просто одно влияние дельфи... если другого не видил. Дельфи вышло в 95-ом. К этому моменту Ява уже разрабатвалась несколько лет.

    S> (Всетаки Delphi был раньше Явы)


    Ага. Примерно на пол года. Вот как они успели то все передрать.

    И главное, как грамотно подрали то! Ни одной проблемы у дельфи не переняли.
    ... << RSDN@Home 1.1.4 beta 3 rev. 206>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[7]: Oberon???????????????????????????????????
    От: serg_mo  
    Дата: 23.10.04 00:08
    Оценка: +1
    Здравствуйте, FR, Вы писали:

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


    P>>Вот тоже кодец, похожий, на Smalltalk'е =)


    P>>
    P>>1 to: 10 do: [:each | Transcript show: each]
    P>>


    FR>по моему как тут уже сказали птичий язык

    Смолток действительно не похож на С-подобные языки. Тем не менее, анатомия языка чрезвычайно проста и подчиняется очень небольшому количеству правил, которые, так сказать, являются универсальными законами во вселенной Смолтока
    Вот, например, статья, в которой на 11 странцах, с щутками и прибаутками, с массой примеров, дано практически всеобъемлющее описание синтаксиса Смолтока. Используя информацию из этой статьи, пользователь сможет прочитать _любой_ код на Смолтоке, даже если не понимает, что этот код делает.
    Возьмем для иллюстрации приведенный выше пример:
    1 to: 10 do: [:each | Transcript show: each]

    Что можно сказать, используя наши знания о синтаксисе:
    а) Имеет место посылка сообщения (или, по-другому, вызов метода) обьекта, стоящего крайним слева: 1.
    б) Вызывается метод to:do:, принимающий 2 параметра.
    в) Первый параметр, очевидно, число 10. Второй параметр сложнее. Допустим, я не знаю, что это, но я могу быть уверен, что это один из немногих специализированных конструкторов какого-то объекта. Почему я уверен? Да потому, что синтаксически альтернативы нет.

    И действительно, конструкция [] — это "синтаксически подслащенный" конструктор класа BlockClosure — блока. Блоки имеют фундаментальное значение в Смолтоке, поэтому, наряду с немногими другими (например, строками и массивами), для создания объектов этого класса есть специальная синтаксическая конструкция. В частности, с помощью блоков реализуются все управляющие конструкции (как в этом примере — цикл со счетчиком).

    Недостатком С-подобных языков, на мой взгляд, является то, что при их изучении приходится зазубривать огромное количество синтаксических конструкций и правил. Условные операторы — бац: кучка конструкций, циклы — еще одна кучка, арифметические операции — их приоритеты... Смолтокер, в свою очередь, может быть уверен, что синтаксические правила, данные в первой лекции (одной лекции будет вполне достаточно), универсальны, и сюрпризов его не ждет..

    FR>У смолтока очень большой недостаток для целей обучения, он слишком не похож на самые распрастраненые языки.

    Ну, это зависит от целей обучения
    Re[16]: Oberon???????????????????????????????????
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 23.10.04 01:30
    Оценка: :)
    Здравствуйте, FR, Вы писали:

    FR>Ну пришли.


    http://gzip.rsdn.ru/File/73/RasdCalc.zip толко он требует второго фрэймворка. Развлекался понимаш с менюшками и т.п.

    FR>Будет, тут недавно пришлось знакомым которые купили, и практически в первый раз увидели компьютер, показывать как им пользоваться, так это просто кошмар. Любая мелочь которую ты даже не замечаешь для них чуть ли не откровение. Вроде люди не глупые все понимают, а вот на мелочах застревают и все.


    Еще раз. Нет проблем сделать снипит-компилятор скроющий все детали. Да и дети те сначал будут сма компьютер изучать. Так что к этому моменту они уже будут далеко не ламерами.

    FR>Понимаешь это все настолько субъективно что вряд-ли, в общем пора закруглятся.


    Наверно. Кстати, возможно что фичи второго шарпа во многом тырили именно с питона.

    FR>Очень даже способны делать код и проще и понятней, просто тебе шоры си образного синтаксиса мешают.


    Ничего мне не мешат. Я довольно адекватно могу оценивать достоинства если они очевидны. Все эти х[3:5] долеко не очевидны. Они требуют объяснения на пальцах. А вот x.substring(3, 5) как раз можно понять и без объяснения. Тому способствует то что все методы имеют единый принцип и описание видное в редакторе. Я, например, долго тупо смотрел на х[3:5] пока не прочел о сути синтаксиса в книжке что ты привел. Когда понял, что это такой зазиповванный синтаксис для substring, то все стало проще. До сих пор, кстати, не пойму почему они для добавления элементов к спискам не сделали аналогичный синтаксис.

    FR>Так я никогда и не утверждал что питон во всем лучше шарпа.


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

    FR>только если все учить то на работу вообще времени не останется


    Да кому нужна эта работа...
    ... << RSDN@Home 1.1.4 beta 3 rev. 206>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Oberon???????????????????????????????????
    От: FR  
    Дата: 23.10.04 09:21
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

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


    FR>>Ну пришли.


    VD>http://gzip.rsdn.ru/File/73/RasdCalc.zip толко он требует второго фрэймворка. Развлекался понимаш с менюшками и т.п.


    посмотрю как доберусь до второго фрамеворка.

    VD>Еще раз. Нет проблем сделать снипит-компилятор скроющий все детали. Да и дети те сначал будут сма компьютер изучать. Так что к этому моменту они уже будут далеко не ламерами.


    В программировании будут

    FR>>Понимаешь это все настолько субъективно что вряд-ли, в общем пора закруглятся.


    VD>Наверно. Кстати, возможно что фичи второго шарпа во многом тырили именно с питона.


    Сейчас уже и не определишь кто и что откуда стырил, коммунизм практически

    FR>>Очень даже способны делать код и проще и понятней, просто тебе шоры си образного синтаксиса мешают.


    VD>Ничего мне не мешат. Я довольно адекватно могу оценивать достоинства если они очевидны. Все эти х[3:5] долеко не очевидны. Они требуют объяснения на пальцах. А вот x.substring(3, 5) как раз можно понять и без объяснения. Тому способствует то что все методы имеют единый принцип и описание видное в редакторе. Я, например, долго тупо смотрел на х[3:5] пока не прочел о сути синтаксиса в книжке что ты привел. Когда понял, что это такой зазиповванный синтаксис для substring, то все стало проще. До сих пор, кстати, не пойму почему они для добавления элементов к спискам не сделали аналогичный синтаксис.


    Как только понял что это такое, очень даже очевидна, я же говорю тебе мешают привычки, мне тоже мешали.
    Как это не сделали? Они на строки со списков и переползли.
    >>> print [0, 1, 2, 3, 4][1:3]
    [1, 2]


    >>> l = [0, 1, 2, 3, 4, 5]
    >>> l[1:3] = [9, 9]
    >>> print l
    [0, 9, 9, 3, 4, 5]


    FR>>Так я никогда и не утверждал что питон во всем лучше шарпа.


    VD>Ты заявлял что он более высокоуровнев. А я вот изучая его нашел как приемущества, так и недостатки. Но никак не превосходство в уровен.


    Я же говорю это субъективно. Много людей которые так же утверждают что шарп на одном уровне с плюсами.
    Я и сам так думал, пока питон не начал изучать
    ... << RSDN@Home 1.1.3 stable >>
    Re[9]: Oberon???????????????????????????????????
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 24.10.04 00:07
    Оценка: +1
    Здравствуйте, FR, Вы писали:

    FR>Вот только мне кажется что ближе к человеческому мышлению как раз большое количество синтаксических конструкций как и в естественных языках.


    Я бы скзал не большое, а адекватное. Выразительные средства должны быть адекватны выражаемым мыслям.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[12]: Oberon???????????????????????????????????
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 24.10.04 10:07
    Оценка: :)
    Здравствуйте, Sinclair, Вы писали:

    S>Некоторые вещи, от которых ты сейчас так плюешься, перекочуют в С# в самом ближайшем будущем.


    Не дай бог.

    S>Я, конечно же, схитрил. Для того, чтобы получить полный аналог SmallTalk, пршлось бы добавить метод ToDo в System.Int32(как это, собственно, и сделано в SmallTalk.):

    S>
    S>1.ToDo(10, delegate(int each) { Transcript.Show(each); });
    S>


    Где бы нарыть смайлик плюющий через плече и рестящийся?

    В общем, за такое нужно
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Oberon?
    От: eugals Россия  
    Дата: 24.10.04 10:55
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    VD>Тут долго пояснять.

    Вряд ли во всём перечисленном у шарпа есть существенные преимущества.
    Наверняка кое в чем он даже уступает.

    VD> Это и динамическая загрузка скомпилированных модулей,

    Без проблем. Питон динамический язык, соответственно и динамическая загрузка модулей в нем имеется. Отгрузка и перезагрузка, кстати, тоже
    VD> и интерфейсы,
    В питоне, как и в смолтоке, любому объекту можно послать любое сообщение. Куда уж гибче интерфейс.
    VD> и рефлекшен,
    Ну, тут сам б-г велел. Разве что называется по-другому (кстати, имхо, ближе к сути): интроспекшн
    VD> и дизайнеры компонентов/контролов,
    А что дизайнеры? Под питон еть порт всех популярных оконных (и вообще, компонентных) библиотек/технологий: PyQT, PythonNet, PyCOM, PyXPCOM, PyVCL...
    Вот я, например, одним из таких приложений сейчас занимаюсь
    Автор: eugals
    Дата: 04.08.04

    VD> и генерация мсила,
    Опять же, в динамическом ЯП, это всё гораздо прозрачнее, чем Reflection.Emit.
    Вот пример функции, которая генерирует новый класс (сколько раз её позовешь, столько раз и сгенерирует):
    def genClass( ):
        class AClass( object):
            # member declarations
        return AClass

    VD>и интеграция с другими языками.
    Смотри выше. Порты есть. В том числе и в дотнет. Плюс удобное Python-Си апи, А С(++), несмотря на майкрософтовский прессрелизы, всё ещё главный мировой язык для разработки библиотек.

    VD>В общем, возможность манимулирования не кодом, а готовыми бинарными модулями.

    Ну, в питоне свой формат прекомпилированных файлов. Вполне себе бинарные модули. Не хуже мсильных сборок.

    VD> Причем практически без потери производительности.

    Вот, собственно, ключевая оговорка
    Здесь да, спорить бессмысленно — шарп пока быстрее.
    Зато питон гибче и лаконичнее. Плюс у него есть много других преимуществ (встроенные возможности АОП, например).
    Но только какое отношение преимущество шарпа в скорости имеет к заявленным тобой "компонентным возможностям"? Имхо, второстепенное.

    ЗЫЖ На хочется в очередной раз начинать на этом форуме холивар Static vs. Dynamic.
    _vovin, в свое время, довольно хорошо про это написал тут. Вряд ли я смогу добавить что-то принципильно новое. А даже если и смогу, тебя всё равно не переубедить, это общеизвестно
    ... << RSDN@Home 1.1.4 @@subversion >>
    Re[4]: Мэйнстрим vs. Самосовершенствование :)))
    От: prVovik Россия  
    Дата: 24.10.04 14:00
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    VD>Однако я совершенно не понимаю зачем начинать учить детей с экзотики вроде СмолТока или с мертвячины вроде Оберона.

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


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

    Проблема мэйнстрима в том, что он все время меняется. И важно сделать так, чтобы студенты не зацикливались на нем. А если вдалбливать мэйнстриме с "самого раннего детства", то, возможно, студент и зациклится. Хотя,

    P.S.: разговаривать мы тут можем сколько угодно, но проблема в том, что наш разговор похож на обсуждение красоты заката среди слепых. Выбирать язык для начального обучения программированию должен профессиональный преподаватель с хорошим опытом преподавания. Ему виднее.
    ... << RSDN@Home 1.1.4 @@subversion >>
    лэт ми спик фром май харт
    Re[18]: Oberon?
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 24.10.04 14:33
    Оценка: +1
    Здравствуйте, eugals, Вы писали:

    E>Зато питон гибче и лаконичнее. Плюс у него есть много других преимуществ (встроенные возможности АОП, например).


    В дотнет тоже есть встроенный АОП — Transparent Proxy. Знаешь в чем проблема? В производительности этого решения.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    AVK Blog
    Re[19]: Oberon?
    От: eugals Россия  
    Дата: 24.10.04 18:01
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    VD> С твоими любимыми сообщениями большое приложение рассыпится от рантаймных багов.

    Пока ещё у меня ни одно не "рассыпалось".

    VD>Забавно так же отсутствие модификаторов доступа (видимости). Все паблик, и все виртуальное. Во, блин, решение. Ни надежности, ни скорости.

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

    E>> Под питон еть порт всех популярных оконных (и вообще, компонентных) библиотек/технологий: PyQT, PythonNet, PyCOM, PyXPCOM, PyVCL...

    VD>Во-во. Порт недо-технологий перехивших свой век.
    Ты сказал, что в питоне нет дизайнеров компонентов. Я ответил, что есть — в тех самых компонентных технологиях PyQT, PyCOM-е и т.д.
    Что же касается утверждения, что QT и .NET "пережили свой век", то тебе конечно видней, но меня лично и такое старьё устраивает пока

    E>>Вот я, например, одним из таких приложений сейчас занимаюсь
    Автор: eugals
    Дата: 04.08.04

    VD>Забавно. Ну, значит должен понимать сколько кода нуно докрутить к чистому Питону, чтобы с ним работать в компонентном стиле.
    Не много. В том и прелесть питона, что в нем такие "докручивания" делаются на раз.

    VD>Еще раз. Прозрачность должна еще должна быть зачем-то нужна. Если я получаю в 10 раз блее медленное решение, то уж лучше я обойдусь менее прозрачным.

    Не в десять.
    Тут недавно пробегало сравнение реализации решета эратосфена на Clean-е и C++.
    Вот пример на питоне:
    from time  import time
    from array import array
    
    def test( size):
        arr = array( "b", "\1" * size)
        arr[ 0] = 0
        for i, val in enumerate( arr):
            if val:
                for j in xrange( i + i, size, i):
                    arr[ j] = 0
        arr[ 0] = 1
            
    tm = time()
    test( 100000000)
    tm = time() - tm
    print tm

    Разница с вариантам WolfHound-а у меня была примерно в 3 раза.
    Вполне терпимо, для интерпретатора. Наверное можно было бы сократить отставание до двух или даже полуторакратного, если слегка подправить питоновские библиотеки array и itertools. В принципе, ничто не мешает мне, при необходимости, ввести PEP (Python Enchancement Proposal) на этот счет — отцы питона вполне либеральны в отношении таких предложений.
    Хотя решето эратосфена, мягко говоря, не самая типичная задача. В GUI, например, всё равно все события через очередь окна пропускаются, питон здесь не будет узким местом (знаю — пробовал).
    Вообще, такие сверхтребовательные к ресурсам алгоритмы составляют всё меньший и меньший процент от текущих проблем.
    Если мне нужна быстрая метематическая библиотека, то я не буду писать на питоне или шарпе свою, а возьму интеловскую MKL. Нужен универсальный парсер — ANTLR или Бизон или Кока, твой любимый. XML — expat или xerces-c. 3D — OpenGL и т.д.

    E>> Плюс удобное Python-Си апи, А С(++), несмотря на майкрософтовский прессрелизы, всё ещё главный мировой язык для разработки библиотек.

    VD>Да? И какие ты библиотеки на С++ знаешь?
    Да любые необходимые. Парсеры, Средства доступа к БД, Графические библиотеки, Всякие сетевые клиенты/серверы...

    VD> А на счет удобства. Что может быть удбонее чем просто использование в одном проекте длл-ек написанных на разных языках?

    Вот именно. В конце концов, на мсиле свет клином не сошелся. Нейтив-код это такой же универсальный язык. Более низкоуровневый, ну и фиг с ним, работает ведь.

    VD>>>В общем, возможность манимулирования не кодом, а готовыми бинарными модулями.

    E>>Ну, в питоне свой формат прекомпилированных файлов. Вполне себе бинарные модули. Не хуже мсильных сборок.
    VD>На склько я знаю каждая версия Питона имеет отличный формат и по этому бинарниками никто не поьзуется.
    Это да. Не то чтобы совсем уж несовместимы, но лучше пикод от разных версий не использовать . Хотя не знаю, может в 2.4 по этому поводу что-нибудь уже и придумали
    VD> Более того они вроде не обязательны. Не создался и ладно...
    Не. Если нужен — создастся.

    VD>Дык она даже не ключевая. Она базовая предпосылка. Т.е. дивиз такой, просто, просто насколько это можно, но не более просто чем нужно для получения производительного кода.

    Само собой. Если бы питон не устраивал нас по производительности, мы бы его не использовали. Устраивает.

    E>>Здесь да, спорить бессмысленно — шарп пока быстрее.

    VD>Покая? Шарпу 2 года. И с каждым годом он становится все быстрее и быстрее. Думаю, ко времени когда МС начнет массовый выпуск продуктов на дотнете они доведут джит и пре джит до уровня своих С++-ных компиляторов (которые у них одни из самых лучших).
    Ну догонит он, а дальше что? Правильно — упрется в железо и остановится.
    А скорость питона растет от версии к версии. Не так быстро как хотелось бы, но растет ведь. И потолок тот же — железо.

    E>>Зато питон гибче и лаконичнее.

    VD>Ну, да экономим на объявлениях типов, перменных, и т.п. В итоге получаем багодром. Гибкость должна иметь разумные пределы. Как и контроль. Баланс, вот что важно. Нужна и скорость кодирования, и скорость получаемого кода, и гибкость, и контроль. Собственно именно разумное сочетание ингридиенов и порождает в итоге конечный продукт.
    Ну, тут не поспоришь

    VD>Надо признать, что питон тоже делает шаги в пред. Как я понял его создатили уже избавились от маразматичного отсуствия вложенных уровней видимости.

    VD>Осталось выбросить статические параметры,
    Это что?
    VD>добавять обязательное объявление переменных
    Обязательное не нужно. Опциональное — может быть. Чтобы можно было оптимизнуть ( или "констрейнтнуть") "по месту".
    VD>Думаю, такой бы язык затмил бы все на своем пути (особенно если при все при этом его компиляторы порождали бы шустрый код). Но это мечта об идиале. А он, как известно, не достижим.
    Ну вот, а как же шарп???

    E>> Плюс у него есть много других преимуществ (встроенные возможности АОП, например).

    VD>Вот об этом интересно было бы послешать по подробнее.
    Почитай про метаклассы.
    Если вкратце, то вот пример, как можно единообразно сделать журналирование вызовов любых методов конкретного класса, а также всех его наследников:
    def createLoggingProxyFor( func):
        def logging_proxy( *args, **kwargs):
            func( *args, **kwargs)
            print "%s called" % func
        print "replacing %s by %s" % ( func, logging_proxy)
        return logging_proxy
    
    class LoggingMetaClass( type):
        """ Метакласс, создающий журналирующую обертку вокруг всех методов своих классов
        """
        def __init__( cls, name, bases, dct):
            type.__init__( cls, name, bases, dct)
            for name, val in dct.iteritems():
                if callable( val) and val != LoggingMetaClass:
                    setattr( cls, name, createLoggingProxyFor( val))
    
    class Test( object):
        __metaclass__ = LoggingMetaClass
        
        def foo( self):
            print "foo"
    
        def bar( self):
            print "bar"
    
    print "starting test"
    t = Test()
    print "calling foo"
    t.foo()
    print "calling bar"
    t.bar()

    Кстати, с помошью метаклассов, можно прикрутить к методам и проверку типов передаваемых в них параметров (и вообще, пред- и постусловий).
    Особенно после того, как в Python 2.4 появились атрибуты (декораторы), навроде шарповских (вообще, они и раньше типа были, но не такие удобные).

    E>>Но только какое отношение преимущество шарпа в скорости имеет к заявленным тобой "компонентным возможностям"? Имхо, второстепенное.

    VD>Гы. А кому нужны игрушки? Если собранное из компонентов ПО рассыпится или будет напоминать пошаговую стратегию, то пользователь пошлет такой софт к черту и будет пользоваться глючным С++-ным.
    Не рассыпается. Стратегию не напоминает. Пользователи не посылают.
    ... << RSDN@Home 1.1.4 @@subversion >>
    Re[5]: Мэйнстрим vs. Самосовершенствование :)))
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 25.10.04 08:09
    Оценка: +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, VladD2, Вы писали:


    VD>>.....появился оператор "ретон". А у Вирта свой взгляд на мир. Он учит if-ы вкладывать.


    СГ>Любой человек хоть немного знакомый с оберонами, не говоря уже о компетентных в этих вопросах людях, знает, что для выходя из процедуры в оберонах используется именно тот самый оператор RETURN. А вот, Вы об этом до сих пор не знаете, а еще чего-то против высказываете.



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


    СГ>А вот компетентные в этом вопросе люди утверждают обратное. Ссылки я уже неоднократно приводил.


    Сергей, это уже выглядит далеко не корректно про компетентных
    Если у тебя нет аргументов так и скажи, а нехрен посылать столько раз всех.
    Re[10]: Oberon???????????????????????????????????
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 26.10.04 09:37
    Оценка: :)
    Здравствуйте, Sinclair, Вы писали:

    СГ>>То есть сначала надо будет объяснить что такое namespace, class, static void Main, ее аргумент string[] args, вот этого кракозябла [STAThread] — объяснить. Не хило?


    S>А можно в ответ привести минимальную программу на обероне?

    MODULE MyModule;
    
    IMPORT StdLog;
    
    BEGIN
      StdLog.String('Здравствуй мир!');
    
    END MyModule;



    Примеры простейших программ:
    http://www.inr.ac.ru/~info21/cpascal/primery.htm
    Re[6]: Мэйнстрим vs. Самосовершенствование :)))
    От: INTP_mihoshi Россия  
    Дата: 26.10.04 09:40
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    VD>Объясните мне чем вам не угодил C#?


    Мне в нем не нравится (с точки зрения обучения) только одно — то, что он навязывает ООП.
    Re[13]: Oberon???????????????????????????????????
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 26.10.04 10:47
    Оценка: +1
    Здравствуйте, Kluev, Вы писали:

    K>И то и другое плохо.

    K>Вот питон здесь рулит однозначно:
    K>http://rsdn.org/File/16157/pyton.PNG
    Ну, лично меня ты практически убедил
    В качестве учебного языка мне он уже нравится. Я так понял, что единственное, что ему вменяется как помеха промышленному применению — так это производительность. Зато есть шанс показать все (или почти все) концепции современного программирования в одном флаконе. Это очень круто.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[13]: Oberon???????????????????????????????????
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 26.10.04 12:50
    Оценка: +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Лучше тем что использовано меньше понятий, судите сами:


    Опять передергиваем. Ай, как нехорошо. Разберемся подробнее:
    Г>Оберон:

    СГ>1) Существуют модули

    Что такое модули? Или это в седьмом классе понятно всем и без объяснения?
    СГ>2) Один модуль может импортировать другой модуль
    Что значит импортировать?
    СГ>3) В модулях есть подпрограммы, которые можно вызывать из других модулей
    СГ>C#:

    СГ>1) Существуют пространства имен (уже непонятность — а что, собственно, еще за пространство да еще и имен? Где они расположены? А как они выглядят эти пространства?)

    Прошу прощения, а где у нас про пространства имен?
    СГ>2) Существуют классы (еще одна непонятность — что еще за классы? Классы чего? Мы в седьмом классе учимся и что с того?)
    Верно. Что-то все-таки надо детям рассказывать.
    СГ>3) У классов есть статические методы (опять ребенку непонятно что такое статические и что такое методы, в чем разница между подпрограммами и методами?).
    А при чем тут подпрограммы? Кто-то считает понятие подпрограммы присутствующим в детской голове прямо с рождения? Лично я в седьмом классе колбасил арканоиды безо всяких подпрограмм. Так что это — заблуждение. И вводить понятие метода ничуть не хуже, чем начинать с каких-то подпрограмм.
    СГ>Что такое void? Почему именно Main?
    Да. с Void придется повозиться.
    СГ>4) Как понять что Console как-то связана с приведенной выше using System;
    Хорошо, свяжем их явно.
    class Class1
    {
        static void Main()
        {
            System.Console.WriteLine("Hello World");
        }
    }

    Итак, пока что у нас Оберон — C# идут один-в-один, за исключением void. Во всем остальном паритет.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[6]: Мэйнстрим vs. Самосовершенствование :)))
    От: Зверёк Харьковский  
    Дата: 26.10.04 13:17
    Оценка: +1
    Здравствуйте, serg_mo, Вы писали:

    _>Здравствуйте, Зверёк Харьковский, Вы писали:


    ЗХ>>СмолТок — воистину. Именно за счет того, что сильно отличается от всего остального. Просто для раздвижения, так скзть, горизонтов. Но учить его первым — по-моему, искалечить восприятие.


    _>Искалечить восприятие чего?


    Тю... Шарпа, естественно.

    А если серьезно — это возвращение к идее мэйнстрима. Грубо говоря, уж очень СмолТок не похож на то, куда движется развитие языков.
    Именно поэтому, имхо, если начать изучать программирование вообще именно со СмолТока — потом будет тяжелее. Привыкнуть, что for — это не сообщение, принимаемое цифрой 1
    FAQ — це мiй ай-кью!
    Re[14]: Oberon???????????????????????????????????
    От: LaptevVV Россия  
    Дата: 26.10.04 13:24
    Оценка: :)
    Здравствуйте, Sinclair, Вы писали:

    S>Итак, пока что у нас Оберон — C# идут один-в-один, за исключением void. Во всем остальном паритет.

    Ага, почитайте вот это

    Вопрос: Почему столь важный продукт, как операционная система, используемая на сотне миллионов компьютеров во всем мире, строится на столь гнилом фундаменте, как язык программирования, для которого нельзя написать компилятор, генерирующий эффективный и безопасный код, с тем чтобы переложить тривиальный механический труд по нудной проверке индексов массивов с человека, которому свойственно ошибаться при выполнении механических процедур, на компьютер, который именно для таких процедур и придуман?
    Ответ: Потому что подавляющее большинство программистов Майкрософт, начиная с Билла Гейтса, — как бы хорошо ни была организована их работа и какими бы талантливыми индивидуумами они ни были сами по себе — классические программисты-самоучки, втянутые в круговорот компьютерной революции большими деньгами и задумывающиеся о методологии программирования только под сильной угрозой со стороны конкурентов.

    В начале 2002 г. Майкрософт на месяц приостановила нормальную работу, чтобы программистский персонал мог специально сосредоточиться на проблемах безопасности и надежности программ. Если оценить количество программистов Майкрософт в 20 тысяч человек при зарплате от $150 тыс. в год и выше, то стоимость месячника повышения квалификации выйдет не меньше 250 миллионов долларов. Майкрософт в состоянии это себе позволить. Остальным, видимо, все же дешевле перейти на инструменты программирования, где проверки индексов массивов не отключаются. Впрочем, и сама компания Майкрософт в настоящее время переходит на платформу .NET, в которой главный язык программирования — т.наз. C# — смоделирован во многом, в том числе и в отношении безопасности программирования, по образцу Оберона.

    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[14]: Oberon???????????????????????????????????
    От: cat-man-do  
    Дата: 26.10.04 14:06
    Оценка: -1
    Здравствуйте, Sinclair, Вы писали:

    СГ>>4) Как понять что Console как-то связана с приведенной выше using System;

    S>Хорошо, свяжем их явно.
    S>
    S>class Class1
    S>{
    S>    static void Main()
    S>    {
    S>        System.Console.WriteLine("Hello World");
    S>    }
    S>}
    S>

    S>Итак, пока что у нас Оберон — C# идут один-в-один, за исключением void. Во всем остальном паритет.

    В Oberon-е мне нравится _однозначность_ его конструкций. Например, то что в C# можно написать System.Console.WriteLine и Console.WriteLine _я_ уже считаю недостатком языка. Если я в программе на Oberon вижу цепочку identifier1.identifier2.identifier3, то всегда знаю что identifier1 объявлен в текущем модуле и могу быстро посмотреть что он означает. Если мне встречается Console.WriteLine в программе на C# я не смогу сразу понять что такое Console и откуда оно взялось, я в курсе, что современные IDE легко позволяют мне это определить, но это решение одного из проявлений проблемы, а не ее самой. В Delphi похожие недоработки языка приводили к необходимости, в сложных библиотеках, идентификаторов состоящих из 8-10 слов.
    В Oberon невозможно обратится к полям/методам результата функции, его можно только присвоить переменной или передать в другую функцию/процедуру, после Delphi это очень раздражало, но то, что вызов метода выглядит как вызов метода (последовательности действий, возможно изменяющих переменные/поля) и отличается от обращения к полям _я_ засчитываю как достоинство языка.
    Re[11]: Oberon???????????????????????????????????
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 26.10.04 17:23
    Оценка: +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>
    СГ>MODULE MyModule;
    
    СГ>IMPORT StdLog;
    
    СГ>BEGIN
    СГ>  StdLog.String("Здравствуй мир!");
    
    СГ>END MyModule;
    СГ>



    Кстати, получается, что разница только в том, что объяснять прийдется про модуль вместо класса. Да уж это татальная разница.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re: Oberon???????????????????????????????????
    От: Зверёк Харьковский  
    Дата: 26.10.04 18:31
    Оценка: :)
    Здравствуйте, LaptevVV, Вы писали:

    Кстати, один неглупый человек уверяет, что надо на С начинать детей учить... Чтоб жизнь малиной.
    http://russian.joelonsoftware.com/Articles/BacktoBasics.html

    Он, кстати, довольно убедителен
    Я бы сказал, что это возврат к вопросу об академических языках (на которых кульно учиться, но становится плохо, когда тот же человек пытается на этом языке работать).
    FAQ — це мiй ай-кью!
    Re[10]: Oberon???????????????????????????????????
    От: prVovik Россия  
    Дата: 26.10.04 19:10
    Оценка: :)
    Здравствуйте, VladD2, Вы писали:

    VD>Блин, дайте мне несколько детей и через неделю они будут писать на шарпе программки.

    А ещё ему море по колено, и горы по плечу
    ... << RSDN@Home 1.1.4 @@subversion >>
    лэт ми спик фром май харт
    Re[18]: Oberon???????????????????????????????????
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 26.10.04 23:11
    Оценка: -1
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Да, конечно, бывают. Ассемблеры, Форт и т.п.


    Ассемблер не высокоуровневый язык. Форт я как-то даже не видел.

    >> В общем, как это не называй. А слабая типизация плоха.


    ПК>В Питоне типизация не слабая. Слабая типизация, скажем, в C. А в Питоне ошибки приведений типов все диагностируются.


    Фиг. Там допустимы приведения между булевыми, целыми, списками и т.п.

    Ну, и опять же вся диагностика в рантайме. Что чревато.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[23]: Component Pascal
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 27.10.04 08:23
    Оценка: +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>На Component Pascal естественно, даже не просто на нем, а на нем в (бесплатной) компонентной среде разработки и исполнения программ BlackBox от Oberon Microsystems, исходный код который обещали открыть к концу 2004 года. Именно Компонентному Паскалю посвящен проект Информатика 21

    Ну, в нем-то вроде бы список сущностей не ограничивается модулями и процедурами. Вирт таки ввел туда ООП, хотя и довольно-таки экзотическим способом. Отсутствие концепции интерфейса не даст возможности разделить спецификацию поведения от ее реализации. Я понимаю — он пытается до последнего цепляться за свое утверждение "алгоритмы+структуры=программы". Имхо подобное преподавание ООП оставит о нем совершенно неверное представление в головах учеников.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[13]: Мэйнстрим vs. Самосовершенствование :)))
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 27.10.04 08:49
    Оценка: +1
    Здравствуйте, Зверёк Харьковский, Вы писали:

    ЗХ>

    ЗХ>Языки примерно такие думал брать:
    ЗХ>Ada
    ЗХ>Eiffel
    ЗХ>Forth
    ЗХ>Oz
    ЗХ>Smalltalk
    ЗХ>(что еще подкинете, может быть?)
    ЗХ>+
    ЗХ>скриптовые, в которых есть интересеные (для меня) подходы:
    ЗХ>Perl
    ЗХ>Python
    ЗХ>Tcl
    ЗХ>+
    ЗХ>есть такое желание, но пока не копал — всякое старье, с которым я, за малостью лет, не сталкивался:
    ЗХ>PL/I
    ЗХ>Fortran
    ЗХ>Simula

    ЗХ>вот где-то так.

    ЗХ>


    ЗХ>Предложения, ясен корень, приветствуются.


    ИМХО надо добавить Ruby и выкинуть PL/1.

    ЗХ>2Модераторz: не знаю, чи в отдельную ветку это выкинуть?


    Думаешь стоит?
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    AVK Blog
    Re[18]: Oberon???????????????????????????????????
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 27.10.04 10:04
    Оценка: :)
    Здравствуйте, AndrewVK, Вы писали:

    AVK>...Если начать без юзингов...


    Дык а вывод на экран как делать без экспорта библиотечных функций?
    Re[15]: Мэйнстрим vs. Самосовершенствование :)))
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 27.10.04 10:14
    Оценка: +1
    Здравствуйте, Зверёк Харьковский, Вы писали:

    AVK>>ИМХО надо добавить Ruby и выкинуть PL/1.

    ЗХ>ОК, учтем. PL/I я просто не видел еще, интересно.

    Лучше бы тебе его не видеть

    ЗХ>>>2Модераторz: не знаю, чи в отдельную ветку это выкинуть?

    AVK>>Думаешь стоит?
    ЗХ>хз... вот сейчас снесут весь топик в войны

    Да вроде никто пока за это не голосовал. Впрочем если снесут, то эту ветку я обратно вытащу.

    ЗХ>да и офтоп это здесь...


    Да нет вроде пока. Сравнение языков самый что ни на есть онтоп.

    ЗХ>может вообще порубать ее к чертям топиков на 5-6?


    А смысл?
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    AVK Blog
    Re[19]: Oberon???????????????????????????????????
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 27.10.04 10:24
    Оценка: +1
    Здравствуйте, Сергей Губанов, Вы писали:

    AVK>>...Если начать без юзингов...


    СГ>Дык а вывод на экран как делать без экспорта библиотечных функций?


    Импорта наверное ты хотел сказать? using это не импорт, это то что я сказал, а именно фичка компилятора, позволяющая писать меньше текста. Импорт в шарпе указывается в параметрах компилятора, а не в исходном коде.
    ... << RSDN@Home 1.1.4 beta 3 rev. 209>>
    AVK Blog
    Re[16]: Oberon???????????????????????????????????
    От: Kh_Oleg Германия http://kholeg.wordpress.com
    Дата: 27.10.04 11:51
    Оценка: :)
    Здравствуйте, AndrewVK, Вы писали:

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


    СГ>>А разница между прочим на столько громадна, что даже не смешно. Перво-наперво надо объяснить КУДА писать исходный код программы. Модуль — это и есть то самое место куда надо писать исходный код программы, в том числе код классов надо писать внутрь модуля.


    AVK>Представь что я школьник и ответь на простой вопрос — а зачем все это?


    Десять лет назад я сам был школьником, которому в рамках школьной программы объясняли азы программирования. При этом использовался язык Modula-2. Уже на втором занятии нам дали задание самим написать программу вычисления корней квадратного уравнения.

    Насчет ключевого слова MODULE было сказано так: в программе ДОЛЖНЫ обязательно присутствовать MODULE ProgramName, BEGIN и END ProgramName. До BEGIN объявляем переменные, после BEGIN — пишем код. То же самое с функциями ввода-вывода: учитель показал как ими пользоваться
    FROM IO IMPORT WrStr, WrLn;
    BEGIN
    WrStr("Hello!"); WrLn;

    и этого было предостаточно, чтобы мы смогли ими пользоваться.
    Re[9]: Oberon???????????????????????????????????
    От: serg_mo  
    Дата: 27.10.04 18:07
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    VD>Предлагая (ну, так для разнообразия) открыть современную стреду вроде VS, Эклипса или Идеи и поглядеть как обстаят дела с пониманием кода в них. Уверю, что будет очень интересно. И окажется, что языки вроде Явы и Шарпа тоже можно успешно изучат без документации.


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

    VD>Прадва на счет тоже я бы усомнился. Я вот как-то пробовал покапаться в смолтоке и быстро бросил. Так как концепции не похожи на прижившиеся в современных языках. А мучиться не хотелось. За то вот Шарп и Яву я освоил очень быстро и без заглядывания в мануалы.


    Думаю, тут надо сказать "пасибо" языку С
    Я абсолютно согласен, зная С/С++, изучение Явы или Шарпа не будет большой проблемой (ну, может, разве что анонимные классы в Яве поднапрягут слегка . Но это при условии, что ты знаком с С. Я знаю людей, которые шли по пути Pascal/Delphi и имели большие трудности с освоением синтаксиса C#, хотя люди были хорошие программисты. Правда, справедливости ради надо сказать, что и Смолток их не вдохновил .

    А для начала работы со Смолтоком тебе естественно, пришлось бы прочитать туториал страниц на 10.
    Правда, изучение Self, например, после Смолтока прошло бы так же незаметно, как сейчас для тебя — C#
    ... << RSDN@Home 1.1.3 stable >>
    Re[10]: Oberon???????????????????????????????????
    От: FR  
    Дата: 27.10.04 18:12
    Оценка: +1
    Здравствуйте, serg_mo, Вы писали:

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


    FR>>Он не похож вообще на другие языки.

    FR>>Простота не всегда хорошо, что хорошо видно здесь на примере того же оберона.

    _>Пусть вещи будут простыми, но не проще, чем нужно . Я хочу сказать, что в основе Смолтока лежит очень небольшое количество правил, используя которые можно построить весьма сложные конструкции.


    с этим не согласен, по моему гораздо лучше воспринимаются среднее число более емких правил.

    FR>>А какой смысл читать код не понимая что он делает? Это примерно как выучить латинский алфавит и кричать что хорошо знаешь латынь?


    _>Ну, не скажи. Когда ты читаешь код на, допустим, не очень хорошо тебе знакомом языке, и встречаешься с непонятной конструкцией, ты пытаешься применить уже имеющиеся знания, чтобы хоть как-то понять, что она делает.


    гораздо полезнее паралельно читать документацию к этому языку

    FR>>По моему такое длиное объяснение такого элементарного понятия как цикл, уже показывает что с языком что-то не так. Во всяком случае для обучения точно это плохо.

    _>Ну, я всего лишь хотел быть предельно понятным. Моей целью было не объяснить, что такое цикл, а проанализировать этот кусок кода.

    я плохо понял, хотя если честно не особо вникал

    FR>>Вот только мне кажется что ближе к человеческому мышлению как раз большое количество синтаксических конструкций как и в естественных языках.

    _>Ну, думаю, тут можно спросить мнение человека, разбирающегося с применением артикля в английском языке или со спряжением глаголов в Passato Remoto в итальянском .
    _>На мой взгляд, наиболее просты для обучения вещи, имеющие четкую схему с минимумом отклонений от нее.

    На мой взгляд проще для изучения вещи которые хорошо ложатся на мышление "обычного" человека, не зависимо от сложности реализации этих вещей на языке програмирования. И судя по тому как распределятеся популярность языков, то именно обычные императивные языки и являются такими.
    И еще обучение это одно, а использование другое, по моему слишком простым тяжело полльзоватся.
    ... << RSDN@Home 1.1.3 stable >>
    Re[20]: Oberon???????????????????????????????????
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.10.04 10:07
    Оценка: +1
    Здравствуйте, Sinclair, Вы писали:

    Я о том и говорю, человек делал простой язык. Как и с Паскалем идея была только учить на нем детей. Вот только такая учеба сравни с колеченьем.
    ... << RSDN@Home 1.1.4 beta 3 rev. 207>>
    http://nemerle.org/Banners/?g=dark
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[25]: Component Pascal
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 28.10.04 10:29
    Оценка: -1
    Здравствуйте, VladD2, Вы писали:

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


    S>>Отсутствие концепции интерфейса не даст возможности разделить спецификацию поведения от ее реализации. Я понимаю — он пытается до последнего цепляться за свое утверждение "алгоритмы+структуры=программы". Имхо подобное преподавание ООП оставит о нем совершенно неверное представление в головах учеников.


    VD>Гы. Там не только интерфейсов нет. Там даже человеческой защиты нет. Поинтерисуйся о методах скрытия (инкапсуляции) применяемых в Обероне 2.


    Кстати, хорошая тема, надо будет ее как-нибудь развить в отдельной ветке. Сейчас только вскользь упомяну, что с инкапсуляцией в оберонах все в порядке.
    Re[9]: Обновление
    От: Mamut Швеция http://dmitriid.com
    Дата: 28.10.04 11:03
    Оценка: +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, VladD2, Вы писали:


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


    СГ>>>Как возник этот проект

    СГ>>>http://www.inr.ac.ru/~info21/kak.htm

    VD>>Кстати, слова "по-дилетантски спроектированного" выдают скорее дилетантство писавших статью.


    СГ>Но он действительно по-дилетантски спроектирован.


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


    Умение "правильно" программировать ИМХО не зависят от языка программирования. Можно коряво программировать и на Пакале и на Обжект Паскале (ака Дельфи) и на С и на С++ и на Яве и ...

    На любом языке программирования можно создавать неработоспособные или неэффективные системы.

    Другое дело, что язык и/или среда программирования может слегка корректировать программиста, но это никогда не остановит программиста от создания монстров.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>


    dmitriid.comGitHubLinkedIn
    Re[10]: Обновление
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 28.10.04 11:14
    Оценка: :)
    Здравствуйте, Mamut, Вы писали:

    M>Умение "правильно" программировать ИМХО не зависят от языка программирования. Можно коряво программировать и на Пакале и на Обжект Паскале (ака Дельфи) и на С и на С++ и на Яве и ...


    Именно поэтому все из перечисленных Вами языков были отвергнуты. В качестве стандарта был выбран Component Pascal на котором коряво программировать не получится.
    Re[29]: Component Pascal
    От: WFrag США  
    Дата: 28.10.04 13:51
    Оценка: +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>1) на счет переменных в definition. Найдите отличия:



    СГ>
    СГ>MyInterface = interface
    СГ>  function  GetMyVariable: integer;
    СГ>  procedure SetMyVariable(NewValue: integer);
    СГ>  //...
    СГ>end;
    
    СГ>MyDefinition = definition
    СГ>  var MyVariable: integer;
    СГ>  //...
    СГ>end;
    СГ>


    Разница — просто огромная. Первый вариант предлагает контракт, без его реализации. Второй вариант — с зависимостью от конкретной реализации.

    Простой пример. В первом варианте я могу подменить реализацию (заменить .jar-ку с имплементирующими интерфейс классами, в случае с Java), совершенно не изменяя остальной код и интерфейсы. А вот во втором варианте если я захочу заменить на вычисляемое поле, то придется править интерфейсы — это и есть лишняя зависимость.


    СГ>2) на счет предопределенной реализации — она не такая как в "виртуальных" функциях, т.е. не имеет побочных эффектов. Подробности смотрите в ссылке.


    Без разницы. Я про зависимости говорил.
    ... << RSDN@Home 1.1.4 beta 3 rev. 205>>
    Re[31]: Component Pascal
    От: WFrag США  
    Дата: 28.10.04 14:43
    Оценка: +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Да-а-а-а????????????? В ссылочку значит так и не глянули???????????????? А напрасненько-напрасненько. Очень рекомендую. Дело в том, что реализация этого определения может выставить на MyVariable get/set методы, и то что снаружи выглядит как простая переменная в разных реализациях может быть и функцией. А ссылочку-то Вы посмотрите, чтоб в следующий раз так просто в просак-то не попадать.


    OK, принято.

    Видишь ли, если уж говоришь в контектсе C# (о интерфейсах), то и называй понятия так, как это там принято. Я говорил про переменные. То что ты сейчас озвучил — это "свойство" в понимании (C#/Java). В C# они поддерживаются на уровне языка, а в Java — на уровне соглашения. Получается, что это уже есть. И тогда я совсем не понимаю, к чему твои слова о "дополнительных фичах".

    Тогда чем эти твои "переменные интерфейса" концептуально отличаются от свойств C#?

    СГ>>>2) на счет предопределенной реализации — она не такая как в "виртуальных" функциях, т.е. не имеет побочных эффектов. Подробности смотрите в ссылке.


    WF>>Без разницы. Я про зависимости говорил.


    СГ>Так расшифруйте что это означает:

    СГ>

    СГ>зависимость от реализации в интерфейсе

    СГ>разумеется, предварительно все же взглянув на ссылочку.

    Ладно, тут моя ошибка.

    Глянул я сслыку. Как-то сложно все — пока не сложилась у меня ментальная модель Zonnon-а, может потом еще чего скажу. Не нравится мне такое — я больше сторонник сильно упрощенных языков и стоящих за ними сильных концепций (моя любимая Java ), нежели сложных языков.


    Ну и документации я хорошей не нашел. Я читал Zonnon_Language_Report_v02r01_7_y040416.pdf, так там собственно ничего и не сказано по сути языка.
    ... << RSDN@Home 1.1.4 beta 3 rev. 205>>
    Re[34]: Component Pascal
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 28.10.04 14:49
    Оценка: :)
    Здравствуйте, Курилка, Вы писали:

    К>И остаётся только свято верить в непогрешимость Вирта и собратьев!


    Да, вот, судьба такая...
    Re[6]: Мэйнстрим vs. Самосовершенствование :)))
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 28.10.04 15:09
    Оценка: :)
    Здравствуйте, VladD2, Вы писали:


    VD>Ну, почему же не пригодность? У Паскаля есть работоспособное развите — Дельфи. Вот только результатом такой приверженности Паскалю явилось, то что появилась целая плияда ламеров непонимающих в программировании как таковом за-то знающих синтаксис Паскаля и потому выбирающих Дельфи. Вот только Дельфи — это современный ООЯ. Пусть не очень качественно споектированный, но все же современный. И его тоже нужно уметь использовать. Но наши преподаватели остановились на голом Паскале. В итоге "программист" осваивает работу с дизайнером форм, даблкликает по кнопки и фигачит там код на том самом Пасклае. Все! На большее он не способен. Хотя нет... еще при появлении какой-нибудь не тривиальной задачи он лезет в Интернет и спрашивает "А где надыбать хомпонент ХХХ для решения задачи УУУ?".


    Значит таже участь ждет и нетчиков

    VD>Вот и не нужно объяснять это на "выдуманных" язвках. Объясняйте это на вымученных языках. Современные ЯП являются такими какми они являются от того, что в них вложен опыт реального программирования на многих предшествующих языках. Ну, не просто так в Яве и Шарпе остались continue и есть return. Та же Дельфи и Васик долго жили без них, но в итоге и в них были добавлены эти конструкции. Вред этих конструкций высасан из пальца.


    Ну ты знаток Delphi. exit был еще в Паскале. Про continue могу сомневаться .Может подскажешь в какой версии появился???
    и солнце б утром не вставало, когда бы не было меня
    Re[7]: Мэйнстрим vs. Самосовершенствование :)))
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.10.04 19:58
    Оценка: -1
    Здравствуйте, Serginio1, Вы писали:

    S> Ну ты знаток Delphi. exit был еще в Паскале.