Ответ на »сообщение 660« (hugi)
___________________________
Я вижу вам нравится Smalltalk.
Обратите внимание в таком случае на его молодого и удачливого потомка - Ruby.

Smalltalk прекрасный язык. Язык опередивший свое время также как и лисп.
К сожалению язык, павший жертвой неудачного выбора его создателя.
Алан Кей, также как и позже Гослинг с java, сделали колоссальную ошибку.
Оба купились на популярную в то время религию ООП, и замуровали этот ООП в самое сердце своих языков.
Можно даже сказать сделали ООП скелет для своих языков.
При этом ведь за ООП ничего не стояло. Никаких теоретических работ, никакого опыта, никаких статистических данных. Просто идеи, захватившие умы тогдашних гуру. Симула всех с толку сбила.

Увы время показало что ООП это гипотеза, не подтвердившаяся фактами.
В Лиспе или скажем OCAML в этом плане поступили гораздо лучше. В них есть полноценный и очень мощный механизм ООП. Но он при этом не диктует ничего. Можно его полностью игнорировать.

В java и Smalltalk этого сделать не удастся. Там ООП это как вера. Либо ты верующий, либо тебя сожгут на костре :))

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

А ООП и ФП - это как вода и масло. Не смешиваются. Либо то, либо другое.
Вирт вот на закате своей карьеры тоже "прозрел".
От ооп стал потихоньку отходить к модульности, и правильно.

Вообще то ругать ООП на сайте дельфи - это ересь.
Думаю щас мне не поздоровится :))

Ответ на »сообщение 659« (Артем)
___________________________
- И давно вы мучаетесь извращениями ?
- Что вы доктор, я ими наслаждаюсь :))

Ну, вот вы наконец и признались, что Лисп - это бзик :)))
А я этого никогда и не скрывал :))

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

Glasgow Haskell Complier ну никак игрушкой назвать нельзя.
Хотя мясом конечно еще не оброс. Нет IDE, нет многих практических библиотек.
Ну у него еще все впереди. Все это сейчас весьма активно наращивается.

Я в принципе не тороплюсь. Лиспа мне за глаза хватает.
Придет время и хаскель поспеет.

Хотя кое какие практические вещи на нем уже делают.
Я уже говорил что Перл 6 делают на хаскеле.
Есть еще darcs - весьма популярная система контроля версий. Тоже на хаскеле.

Ответ на »сообщение 559« (Jack Of Shadows)
___________________________
Видите ли, семантически разницы между этими двумя примерами нет никакой.
Согласен.
Даже в количестве символов они гораздо более близки чем наш с вами пример с closures и локальными функциями.
Не согласен (по крайней мере с closures VS. delegates).
Таким образом, согласно вашей логике, они идентичны и следовательно между языками в которых есть case и нет case - никакой разницы нет.
Семантически никакой разницы нет, есть разница в синтаксисе, но, как я уже говорил, для меня синтаксис не так важен, как семантика. Одного того факта, что в каком-то языке есть case, недостаточно, чтобы заставить меня на него перейти, при условии, что в языке, которым я пользуюсь в настоящий момент, есть совершенно идентичная по семантике конструкция. Тем более, что синтаксические различия преодолеваются в большинстве случаев гораздо легче, чем семантические. В том же Squeak, насколько я знаю, возможно использовать различные синтаксисы для одного и того же языка -- Smalltalk. Но если в языке нет оператора условного перехода, вам придётся напрячься, чтобы его сделать (исключение, пожалуй, составляет всё тот же Smalltalk, в котором условный оператор реализуется с помощью двух ключевых понятий языка: объектов, сообщений, а также возможности передачи блока кода, -- да-да, всё тех же closures). Так что речь идёт скорее о полноте, замкнутости и гибкости системы понятий на которых строится этот язык, а также продуманности его дизайна, а не компактности формы записи и куче наворотов, включённых в язык (о пагубности несоблюдения меры в этом вопросе наглядно свидетельствует "замечательный" язык Perl). И, кстати, механизмам того же Smalltalk я отдаю гораздо большее предпочтение, чем макросам.
Все до единого корифеи программирования, включая Вирта, Гослинга, Андерса Хейлберга, Алана Кея, и конечно же моего обожаемого Маккарти - с вами в этом не согласны. У них у всех есть case вместе с if.
Вы снова ошиблись. По крайней мере, насчёт Кея. В Smalltalk нет case, равно как и if, но их можно "построить" стандартными средствами, не прибегая к метапрограммированию. Насчёт Вирта, думаю, Вы тоже ошибаетесь. Не он ли хотел выкинуть из Оберона цикл for? Или ошибаюсь я? А Гослинг и Хейлсберг? Может, они в этом вопросе ориентировались на "посредственностей"?
Тем не менее, я думаю, лучше закончить дискуссию на эту тему, тем более, что факторы, влияющие на выбор того или иного языка программирования, ни семантикой, ни синтаксисом не исчерпываются.

Ответ на »сообщение 657« (Jack Of Shadows)
___________________________
А лисп я использую потому что у меня бзик на него :))
Хаскель я обязательно буду использовать.
Я пока хожу вокруг него, рассматриваю. И чем больше смотрю тем больше он мне нравится.
Но пока нет практической задачи, на которой я бы его проверил.
А играться у меня времени нет.

Ну, вот вы наконец и признались, что Лисп - это бзик :)))
Признаю, Хаскель красив. Я сам не него смотрю. Но, к сожалению, его реализации пока похожи на интеллектуальные игрушки и в промышленном программировании он практически не используется.

Ответ на »сообщение 655« (Сварог)
___________________________


И никто не мешает программисту на Делфи, С и С++ автоматически создавать в программе потоки в любом количестве.


Автоматически нет. Вручную да.
Вам вообще то Артем и Антон Григорьев уже ответили.
Это как сравнение сборщика мусора с ручным убиванием обьектов.
Сборщик мусора ГАРАНТИРУЕТ корректное управление памятью, в то время как ручное управление памятью всегда оставляет шанс для ошибки.

Также и с потоками. Ручное управление потоками - работа чрезвычайно трудная, и 100% гарантирует ошибку.
Такую работу лучше отдать на откуп компилятору.
А сделать это в ИЯ невозможно. Никакой, даже самый навороченный компилятор не сможет корректно определить как распараллеливать код с побочными эффектами.

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

Ответ на »сообщение 656« (Артем)
___________________________
Другое дело, что чистые ФЯ довольно убоги в смысле возможностей. Видите, и сам Jack of Shadows пользуется смешанным языком.

Не согласен с вами. Чистые ФЯ очень богаты по своим возможностям.
А лисп я использую потому что у меня бзик на него :))
Хаскель я обязательно буду использовать.
Я пока хожу вокруг него, рассматриваю. И чем больше смотрю тем больше он мне нравится.
Но пока нет практической задачи, на которой я бы его проверил.
А играться у меня времени нет.

Ответ на »сообщение 655« (Сварог)
___________________________
И никто не мешает программисту на Делфи, С и С++ автоматически создавать в программе потоки в любом количестве.
Да, но в ИЯ нам приходится делать это вручную, а в ФЯ по идее это может делаться автоматически. Правда, пока только в экспериментальных непромышленных (ну,может за исключением Эрланга) языках.

[Qoute]И самое главное - остается совершенно непонятным именно то утверждение, о котором я писал ранее: "Реализация многопоточности с помощью библиотек ИЯ не может гарантировать корректное исполнение кода". Поскольку реализация этой многопоточности "на уровне языка" в ФЯ никак не может быть иной, чем на основе библиотек ИЯ, гарантии корректности исполнения у них в точности совпадают. Иначе означенный ФЯ должен был бы быть сам по себе ОС, что не имеет места.

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

Другое дело, что чистые ФЯ довольно убоги в смысле возможностей. Видите, и сам Jack of Shadows пользуется смешанным языком.

Ответ на »сообщение 654« (Антон Григорьев)
___________________________

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

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

И никто не мешает программисту на Делфи, С и С++ автоматически создавать в программе потоки в любом количестве.

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

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

Ответ на »сообщение 651« (Сварог)
___________________________

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

Не будете ли любезны объяснить, что это означает - "многопоточность реализуется на уровне языка"? А то я до сих пор полагал, что многопоточность реализуется на уровне ОС её библиотеками. А Ерланг и parallell haskell - это, вроде бы, не ОС.

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

Сегодня пришлось выполнять срочную задачу.
Крупный клиент потребовал переделать по другому Table of Contents в нескольких тысячах своих файлов (pdf)
Сами файлы хранятся на различных серверах. Пути к ним в базе данных.
На лиспе решение задачи заняло у меня меньше часа.

На дельфи я даже не уверен что справился бы за 1 день.