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

ПК>>Ты говоришь о другой ситуации, а именно о помещении функции sort в класс Array. Дело спорное, т.к. нарушает Open-Closed Principle, но вопрос совсем отдельный.
_>Я не очень понял, а в чем нарушение? Объясни, пожалуйста

Экий ты не понятлевый: Re[14]: Мэйнстрим vs. Самосовершенствование :)))

Автор: VladD2
Дата: 29.10.04

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

ПК>Нет, просто ни в какие классы эти функции не пихать, т.к. множество алгоритмов открыто, и, соответственно, помещение их в класс нарушает Open-Closed Principle.

Ага. Я вот как смотрю на классы Шарпа и сразу вспоминаю, что нарушены все принципы. А как смотрю на СТЛ, так сразу ... маму вспоминаю.

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

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

VD>>Ну, это ты зря. В Шарпе все концептуально полно.

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

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

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

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

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

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

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

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

К тому же сложностей хватет. В Яве все недостоющее эмулируется. А эти эмуляции тоже объяснять нужно. То же применение массивов вместо ref/out модификаторов у параметров объяснять прийдется очень подробно. Уж проще объяснить те самые ref/out...

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

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

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

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

AVK> Концептуально это даже чище ref и out. Понятно что писанины при этом больше, но при обучении это не страшно.

Это очень грязный хак. А вот ref и out очень красивые решения.

VD>> Ну, а то что пока не нужно можно и не преподовать.

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

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

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

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

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

Ну, а если умалчивать о возможностях, то пофигу где о них умалчивать.

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

int[] refInitVal = new int[1];
refInitVal[0] = defVal;
obj.CallMethod(refInitVal);

А в шарпе:

int initVal = defVal;
obj.CallMethod(ref initVal);

думаю, что объяснить ref будет проще.

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

S> Exit это выход из процедуры.

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

S> А Continue и Break еще во 2 Delphi были

Дельфи к Паскалю имеет отдаленное отношение.

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

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

С каких пор Паскаль стал равен Дельфи?

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

СГ>1) У меня нет моих людей. И я не учитель, как Вы почему-то подумали.

Тогда с чего эта инициатива?

СГ>2) На сайте info21 есть ссылки на другие сайты где кучами лежат компоненты под BlackBox. А еще, там же есть, например, ссылка на сборник олимпиадных задач для школьников.

Так можно все же конкретную ссылку. А то лазить черти-где охоты нет.

СГ>Но! Обращаю Ваше внимание, что для того чтобы смотреть исходники скачать и установить BlackBox Вам все равно придется, так как формат в котором хранятся исходные тексты программ не plain-text, а бинарный формат *.odc (Oberon Document).

Ну, это логично! Все как аголтелые стремятся к стандартизации форматов. XML изучают. Было просто банально быть как все.

СГ> odc-файл это файл в котором в бинарном виде сохранен конгломерат взаимоссылающихся друг на друга объектов (сериализованные объекты).

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

А ББ я еще вчера скачал. Надо признаться — это еще тот атракцион. Весит как пол дотнета... интуитивность потрясающая!

СГ> Благодаря этому, oberon document представляет собой среду напоминающую MS Word,

Ага. Только кривее и непонятнее.

СГ> то есть текст можно форматировать (шрифт, цвет, размер, стиль — каждой буквы).

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

СГ>Нажимаешь на кнопку — процедура выполняется!

Ну, еще немного и будет так же удобно как в консоли Питона.

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

СГ>Так ведь, с объектами это тоже можно, добавил метод подсчета слов и метод сравнения и готово...

И что есть примеры сравнения двух odc-файлов?

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

M>Это УБОЖЕСТВО, с которым невозможно работать.

О! Вот эту мысль я и пытаюсь донести.

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

Кстати, сдества отладки там тоже потрясающие. И это при бесплатном Эклпипсе и VS Express.

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

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

Еще раз. Можно поглядеть твой код?

ЗЫ

Мой можно поглядеть вот тут R#.

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

FR>>Тут http://devlink.crimea.ua/articles/article.php?article_id=20 краткое описание.
FR>>Вообще Ruby в общем конкурент питона, но по моему синтаксис у него менее понятный, и он ближе к функциональным языкам.

AVK>ИМХО наоборот, Руби чем то ближе по духу джаве и шарпу.

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

Переход из ФЯ в ООЯ просто красив:

# Императивщина
sum = 0
1..10.each do
    |i| sum += i
end
...
# Функциональщина 
sum = 0
1..10.each { |i| sum += i }

На дотнет и Яву это смахивает мало. Все это именно что нетипизированный интерпретируемый язык со встроенными контейнерами. Но и от Питона это серьезно отличается.

Заточка на ФС проглыдяывается не вооруженным взглядом.

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

ПК>> Ты говоришь о другой ситуации, а именно о помещении функции sort в класс Array. Дело спорное, т.к. нарушает Open-Closed Principle, но вопрос совсем отдельный.

_>Я не очень понял, а в чем нарушение? Объясни, пожалуйста

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

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

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

Ссылку в этом топике я уже давал.

Здравствуйте, 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>Опять же или прийдется эмулировать их, или умолчать. Оба случая не в пользу Явы.

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

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

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

Например?

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

Незнаю, незнаю. Я бы вещи вроде Шарпа и Плюсов читал бы в обязательном порядке. Шарп по раньше, плюсы по позже. Так же бы читал какой-нить ФЯ, но не Лисп или Схем.

AVK>Ничего там не уйдет. Там вобще как таковой отдельной концепции нет.

Агащасблин. На них и визуальные контролы завязаны и ЁЖиБи.

AVK> Просто в некоторых библиотеках появляются listeners, причем как ими пользоваться понятно сразу же при просмотре первого примера.

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

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

Дык с тем же успехом взникают вопросы "чем переменные отличаются от свойств".

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

AVK>Я уже сказал — здесь джава действительно требует больше усилий, нежели шарп.

Ну, и выходит даш на даш.

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

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

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

Ну, уж извини.

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

Вот только этот прием теперь во всех книжках по Яве идет как базовый способ реализации событий. Еще бы (?!) он же в половине библиотек испльзвется.

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

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

Не батенька. Когда явной механики вагон и нехилая тележка, то объяснять задолбаешся. Иначе бы С++ был бы самым простым языком в мире.

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

Здорово. Значит часть возможностей языка не объясняем. Тогда уж извини. Необъяснять можно что угодно. Эдак любую закрытую дыру в яве можно не объяснять и языки станут идентичеными. Вот только работать на таком языке человек на практике не сможет. Один хрен прийдется изучать "приемы" как обойти дыру.

В Яве уже появилась куча возможностей из Шарпа. Те же атрибуты, например. Их тоже прикажешь не учить? Тогда можно вообще к Яве 1.0 обратиться. Уж там учить еще меньше.

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

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

Реального. Или мы учим детей играться в программирование. Или учим программировать.

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

Много. Но это к делу не относится.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Можно объяснить принцип Open-Closed Principle?

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

Совсем согласен. Но все же когда язык или среда подталкивают все же лучше. Не все же программисты супер-ассы. Да и ассы в запарке лажу гонят. Это на детских примерах хорошо говорить, что continue не нужен, или что, мол, вот как все просто и красиво. А когда в программе стоят параллельно требования сделать быстро, производительно, надежно и красиво, то обязательно чем-то придется жертвовать. И такие фишки как типобезопасность, поддержка того же рефакторинга средой, читаемость кода начинают играть большую роль. Но, безусловно, в руках у неандертальца все эти фишки даже бесполезнее чем каменный топор (так как им то они пользоваться умеет).

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

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

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

ПК> соответственно, при разработке последних придется создать Lists и Deques с тем же содержимым, что в Arrays.

Зачем? Темболее что ArrayList содержит в себе массив и поьзуется его функциями.

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

Ну, про статические методы и наследование ты не слышал?

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

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

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

Так что если концепция мне не помогает, то ну ее в лес.