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

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

Это можно сказать об очень многих ЯП. Вот только в случае с Руби, на мой взгляд, не все решения удачные. Много и не удачных.

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

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

BZ>не видел ни ту, ни другую, ни третью, так что могу ошибаться.

100% ошибаешся.

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

Все то же самое сегодня доступно и для императивных языков. Единственное чего нет — это возможности менять классы на лету (во время исполения программы), но это уже не заслуга Смолтока и не ограничение C#-а, а заслуга Динамики и интерпретации и не ограничение статики и компиляции. Собственно эта фича так же приводит и к другому эффекту — невозможности контролировать ошибки до вызова методов. Что уже становится ограничением динамики, и заслугой статики.

BZ>что означает "уникальные идентификаторы"? я вообще лучше знаю английскую терминологию

Это относится к системе типов Хаскеля. Точнее примитивности системы Хинли-Миллера. Она конечно позволяет довольно ээфективно выводить типы, но страдает достадными ограничениями вроде невозможности перегрузки функций по имени. Например, мы не можем определить свойство (метод, поле, функцию) "x" у типа Point и скажем у типа Point3D. Разруливание на уровне модулей не катит, так как оба типа данных могут понадобиться в одном коде. Посему фукнции начинают вбирать в себя префиксы вроде pointX и point3dX. Сто лично мне очень не наравится. И вообще, я привык к "излишествам" рожденным С++: перегрузка, неявные приведения типов, объекты...

BZ>вместо C# и Delphi с теоретической точки зрения лучше изучать Eiffel, это дейсвтивительно красивый и мощный язык с чистой ООП идеологией.

А нафиг теоритическая точка зрения не нужна при выборе языков для обучения. Eiffel как и Смолток прошляпили свое время. Так что учить надо C# и Ruby, а про Eiffel и Смолток можно потом (или в процессе) рассказать и сказать, что мол так и так имеют такие-то особенности.

В конце концов проблем у этих языков выше крыши. Тот же Eiffel уступает Немерлу и Spec#-у в олласти декларации инваринатов и пред/пост-условий, так как Eiffel порождает только рантайм-проверки, а Немерле и Spec# повзоляют многое контролировать во время компялции с помощью Буги (утилиты из Spec#).

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

Я уже сказал, что Руби и C# являются представителями разных подходов. Причем живыми предтавителями. Можно без проблем найти работу на обоих. Особенно на Шарпе.

BZ>есть. я вроде и говорил про эти два языка, ты не заметил?

Пунктик то?

VD>>С каких пор Пролог стал ФЯ?

BZ>логичнсеколе программирование — тоже мощная, хотя и медлительная парадигма

Парадигм не может быть медленной. Медленные реализации. И понятно почему. Но опять же, то что ЛП интересно не значит, что оно равно ФП. Это разные вещи.

BZ>имхо после выражений нужно переходить к более сложным выражениям

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

Блни, зать за обучение не платят хороших денег.

VD>>Что касается языка, то я бы как раз выделил на роль первого языка Немерле или Руби. Руби я бы посоветовал тем учетилям которые считают, что вначале людям не надо морочить голову с типизацией, а Немерле тем кто считает, что типизация важнеший аспект. Ну, и по той причине, что на немерле можно показать практически все приемы кроме разве что ЛП.

BZ>вот именно, и ничего хорошего я тут не вижу.

А что плохого? Хрошее же то, что все можно продемонстрировать в чистом виде по одтельности и в смесе.

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

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

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

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

Но тут прлема в том, что есть назные учителя с разным взглядом на мир. И вот в том же MIT почему-то считают, что учить на нетипизированных Лиспе и Питоне лучше. В прочем, возможно они просто не видили Немерле .

BZ>а ты собираешься их смешанно давать, типа одно предложение их одной парадигмы, второе из другой?

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

BZ> имхо надо изучить каждую из них — ООП, ФП, ЛП в чистом виде,

И получим то что имеем. Фанатство и частичные знания. А так мы получаем взвешенных и всетаронних специалистов которые не будут орать "ФП фтопку!" или "ФП рулеззз!".

BZ>на чистых языках,

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

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

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

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

BZ>а ты читал книгу Вадлера или Худака или судишь по Хал-Ван Даму?

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

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

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

BZ>почему? потому, что ты сам начинал с него?

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

В общем, это была моя мысль. Не согласен? Ну, и ладно. Один фиг я вряд ли буду кого-то обучать программировать.

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

Хаскль столько же структурен как С даже больше. ЛП конечно другое. Но но то оно и ЛП. Я не призваю изучать ЛП как развитие структуроно подхода. ЛП вообще скорее средство решения конеретного класса задач. Оно по сути ближе к SQL-запросам, когда есть БД и мы пишем запросы отвечающие на те или иные вопрсы. ЛП можно давать как практику программирования вырадившуюся в конеркетный язык.

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

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

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

Еще раз. Я вообще против парадигм в обучении.

BZ>с.п. на данный момент уже можно считать частью ООП.

Ошибочный взгляд, на мой взгляд.

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

А мне не надо мыслить функционально. Я мыслю как мыслю. Удобнее так думаю, так удобнее эдак думаю эдак. Остальное догмы.

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

Нет. Сначала учить писать выражения. Язык тут монопенисуален:

1 + 2 * (33 + 1)

затем разбавлять их переменными:

def a = 33 + 1;
def b = 1 + 2 * a;

затем дать понятие мзменяемой переменной:

mutable a = 33 + 1;
def b = 1 + 2 * a;
a = 22;
def c = 1 + 2 * a;

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

BZ> а перед этим научить их програмимровать на асме, чтобы затем преподнести им идеи стурктурного программирования? а перед этим — в машинных кодах, да?

Отнюдь. Это лишнее. Выражений более чем достаточно.

BZ>твой подход хорош для доучивания людей, которые уже владжеют некоей неэффектвиной парадигмой.

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

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

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