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

ANS>> и на ST там всё написано кроме ВМ и виндовых контролов.

VD>Спай четко показывает, что все окна написаны на MFC или еще чем-то там (давно дело было). То есть сама среда написана на С++ или с нехилым его применением.

Ну, правильно! Я ж говорю все контролы нэтивные-виндовые.

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


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

Не совсем уловил мысль..

VD>мэйнстрим реально регекспы использует не часто. Многие программисты их или вообще не знают, или в них плавают.

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

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

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

FDS>>Ага, вопрос: что мешало авторам сделать язык без этой особенности?

VD>Если отбрасывать все решения кроме "все объект и общатся объекты могут только посылая сообщения", то и дийант получится вот такой. Ты же не можешь создать оператор if(условие) выражение else другое-выражение? Это же не укладывается в концепцию "все объект...".

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

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

Вы считаете, что Ruby это "элитарный язык"? Это не риторический вопрос.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, Eugene Beschastnov, Вы писали:

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

ANS>Так прям и никогда. В Seaside first-class continuation реализованы путём манипуляции цепочкой контекстов активации, в VW — исключения (хотя может и есть какие-то ускорения в ВМ, не знаю, проверить не могу).

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


S>>>Вопрос №2: а как это работает вместе с присвоением блока кода в переменную с последующей ее передачей за пределы контекста.

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

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

B>В Smalltalk можно написать метод doFirst: doMiddle: doLast:, который решит эту проблему. Перебор коллекции будет осуществляться внутри этого метода, а вот сами операции, которые необходимо выполнить можно передать в качестве параметров.

В Java можно написать метод

public void doMyCoolIteration(MyCoolMethodHolder holder)

где MyCoolMethodHolder есть

interface MyCoolMethodHolder {
   void doFirst(Object element);
   void doMiddle(Object element);
   void doLast(Object element);
}

B>Вызов этого метода будет выглядеть так:
B>

B>col 
B>    doFirst: [:elem | ...]
B>    doMiddle: [:elem | ...]
B>    doLast: [:elem | ...]
B>

Вызов этого метода будет выглядеть так

list.doMyCoolIteration(new MyCoolMethodHolder() {
   public void doFirst(Object element) {...}
   public void doMiddle(Object element) {...}
   public void doLast(Object element) {...}
});

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

Читабельность в данном случае, ИМХО, зависит только от того, на чем читатель привык писать.

B>Все это возможно в Smalltalk и невозможно в Java благодаря наличию блоков кода (BlockClosure).

Что-то, возможно, в Java и невозможно из-за отсутствия closures, но только не то, что было приведено в качестве примера.

B>Радует, что в C# добавили такие возможности (я говорю про лямбду в C# 3), а там глядишь и Java подтянется в этом плане.

Java может и подтянется (разговоры есть):
http://gafter.blogspot.com/2006/08/closures-for-java.html
http://gafter.blogspot.com/2006/08/whats-point-of-closures.html

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

K>Вы считаете, что Ruby это "элитарный язык"? Это не риторический вопрос.

Нет. Ruby не элитарный язык. Как, впрочем, и Smalltalk.

В вопросе Дарнея, на который я отвечал, говорилось и о новых технологиях и об "элитарных языках". Пример с 37signals, Ruby и RoR я привел в ответ на фразу об использовании новых технологий в стартапах. Как раз на тот момент Ruby и RoR для большинства разработчиков были новыми и экзотическими технологиями.

Что же касается самого Ruby, то он производит впечатление простого. Но это только впечатление. Мо моим впечатлениям, он многослоен как C++. Что является для меня привлекательной стороной Ruby, но мне кажется, что со временем это сыграет с Ruby такую же шутку, как с C++.

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

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


T>>Да фактически каждый новичок отмечает эту особенность синтаксиса смоллтока. Просто некоторые привыкают и не замечают некоторых неудобств (кажущихся?), а некоторым это кажется неуклюжим и они не могут это принять и привыкнуть.
T>>Что-то в этом духе.

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

Ерунда. Не видел ни одного нормального школьника, который что-то осваивает легко

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

E>Изначально речь шла не о преимуществах а о запущенных на RoR проектах.
E>Я не понял, тебе список не нравится, проектов мало?

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

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

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

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

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

у 12 намного больше делителей, чем у 10 -> многие дроби в ней записываются проще, чем в 10-ричной

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

хотя, если хорошо подумать.... некоторые преимущества у RoR наверно есть, если его используют. Или были на момент его появления.

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

FDS>>Если честно, то я всегда считал своим успехом то, что мои мысли стали относительно слабо зависить от языка программирования. И код стал лучше после этого. Что ж там за ломка то такая? Может эти языки, действительно, лучше на помойку выбросить, если там такая ломка

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

Можете дать какую-нидуь ссылку на Лисп (компилятор и, хотя бы, стандарт, а лучше книгу на русском), а то у меня от поиска в интернете крышу сносит

VD>Гарантирую, что это ощущение ни в какое сравнение не идет с недовольством от того или иного алголоподобного языка.

FDS>>Макросы (полностью)

VD>И что с ними не так? Ты писал когда нибудь программу которая генерировала бы код другой программы?

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

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

FDS>> и то, что нужно объявлять все переменные как переменные

VD>Хм. А как что же их тогда объявлять? Или ты предлагаешь вообще их не объявлять? Последнее приводит к ошибкам. Это натуральные грабли. Одна опечатка и ищи ошибку часами.

Я имею ввиду модификатор mutable. Насколько я понимаю, без него переменная — не переменная, а константа (точнее readonly поле).
"Одна опечатка и ищи ошибку часами." — я не поклонник скриптовых языков, но когда на них пишу таких ошибок почему-то не допускаю (именно в скриптах ). Уже много о них читал и всё время удивлялся.



VD>Это ошибочное мнение. Он не неотличается. Он успешно "косит" под привычный язык. А отличается он сильно. Но чтобы это прочувствовать нужно пописать на нем код и попытаться использовать те вещи которые пока просто непонятны.

Не очень понял, какие вещи нужно попытаться использовать, да ещё если они непонятны? Можно приблизительный списочек: я попытаюсь.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

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

ANS>Блин, реально не пойму о каком непредсказуемом пути идёт реч. Если в блоке есть нелокальный возврат, то выход проискодит из места определения блока. То есть код работает так же как и код, который ты привёл. Это указано в спецификации метода. Если тебя пугает то, что метод делает не то, что должен делать, то не стоит пользоваться ни одним ЯП вообще.

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

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

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

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

B>Ваше предчуствие Вас обманывает. Таким "хакерским" приемом Вы и сами пользуетесь постоянно.

B>

B>int method(){
B>    if (a < 5) {
B>        return 8;
B>    } else
B>        return 10;
B>    }
B>}
B>

Я делаю это так:

int method(){

    if (a < 5)
        {
       return 8;
    };

      return 10;
}

B>Теперь и сам Smalltalk. Угадайте, куда перейдет управление
B>

B>method
B>    (a < 5) ifTrue: [^8] ifFalse: [^10].
B>

B>P.S. В Smalltalk знак ^ аналогичен ключевому слову return

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

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

ANS>Ран-тайм исключение.

А ведь это можно проверить статически...

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

EB>Здравствуйте, Eugene Beschastnov, Вы писали:

VD>>>>>В функциональных языках return то не приветствуется, а тут вольный выход из любой точки выражения. По-моему, то чистой воды грабли.
EB>>>>Ну блин %-). А ТЫ как относишься к exception-ам?
WH>>>А как исключения относятся к выходу черт знает куда?
EB>>Ну, во-первых, не чёрт знает куда, а в контекст, находящийся в стеке непосредственно перед контекстом, в котором был определён блок. А во-вторых "вольный выход из любой точки выражения" — это несколько о другом (даже если закрыть глаза, что это устверждение неверно, и выход может быть отнюдь не из любой точки выражения

Автор: Eugene Beschastnov
Дата: 05.09.06

).
EB>Забыл добавить — и, собственно, unchecked exception-ы в плане "вольного выхода из любой точки выражения" значительно более "опасны" — они могут возникнуть в любом месте, а отнюдь не только в value*-методах.

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

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

Мне очень интересно, почему именно ты так часто обвиняешь оппонентов в демагогии. Очень странно. Ни у кого другого это так часто не наблюдал. Даже у Влада
Не подскажешь, в чем тут секрет? Только не говори, что тебя несчастного все травят.

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

FDS>Можете дать какую-нидуь ссылку на Лисп (компилятор и, хотя бы, стандарт, а лучше книгу на русском), а то у меня от поиска в интернете крышу сносит
Перевод классической Structure and Interpretation Of Computer Programs
здесь
Интерпретатор
здесь

Там не совсем лисп, а Scheme, диалект лиспа, но общее представление он дает..

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

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


VD>>Еще раз. Это не лябда! Это эдакий вариант континюэшона, а еще точнее замена дальнего goto. За такое в приличных программистских конторах по пальцем железной линейкой были во времена С. Код может получиться столь не предсказуемым, что его отладка и изучение может стать пыткой.
EB>Ну не получается . Ни у меня, ни у кого другого, использующего Smalltalk (замечу — именно использующего). Что мы не так делаем?

Вы уверены?
Наверное, это сродни тому, что я не делаю опечаток в названии переменных в скриптовых языках (там, где переменные не нужно объявлять) — кто-то может так делать, кто-то нет. Но согласитесь, VladD2 привёл классный пример, кто даст гарантию, что какой-нибудь "умник" так не сделает