F>Если некто осуждает бездумное следование за меньшинством, это еще не значит, что он призывает бездумно следовать за большинством. Он может, например, призывать воспользоваться своей головой и самому решить, куда двигаться...
Плохо, когда обсуждение заходит далеко, ибо теряется связь с начальным контекстом. Кто-то применил эпитет, и через пару постов эпитет оброс смыслом.
Никакого буздумного следования за меньшинством не было, разумеется. Тем более, что речь идет о более сложных в применении технологиях. Откуда там взяться "бездумству". На такие шаги можно решиться лишь все тщательно взвесив предварительно.
Здравствуйте, Beam, Вы писали:
B>В Smalltalk тоже можно вообще не прыгать.
Замечательно.
B>Прыгание используется в тех же ситуациях, в которых оно используется в Java/C#. Заметьте, что и в них тоже можно не прыгать, а спокойненько дойти до конца метода.
Вообще-то нет. Java и C# — statement-based, так что return там пишется в любом случае, если ф-я что-то возвращает.
т.е. мы не можем написать
{ expr }
но всегда обязаны писать
{ return expr }
Хотя в данном случае в прыганье нет необходимости.
(в C# 3.0, правда, появились лямбда-выражения, но не суть важно.)
Важно то, что в анонимном методе в С# return имеет совсем не ту семантику, что ^ в блоке кода в смолток.
для того, чтобы прыгнуть из анонимного метода как в смолтоке нужно бросать исключение.
Поэтому, нельзя говорить, что прыганье и там и там испоьзуется в одних и тех же ситуациях.
K>>Непонятно мне другое. Почему возможность прыгнуть в Nemerle является оправдание возможности прыгнуть (причем, как я понял, гораздо дальше) в смолтоке?
B>Вы поняли неправильно — прыгнуть дальше, чем в Nemerle не получится
Ах да, я и забыл, что немерле — это воплощение зла. Впрочем, прыгнуть неограниченно далеко можно в любом языке, где есть исключения, но именно с помощью исключений. Прыгнуть в немерле штатными средствами вообще не получится, потому, что этот язык expression-based.
Никакого goto даже в ограниченной return-модификации там нет.
Даже если вы из настальгических соображений подключите Nemerle.Imperative (а такое желание, по моему убеждению надо в себе безжалостно давить),
то
{ return expr }
развернется во что-то вроде
{
return : {
return(expr)
}
}
т.е. видно, что это все равно выражение, а не передача управления.
B>А насчет Вашего вопроса я скажу следующее. После того как в этом топике были продемонстрированы примеры "с прыганием" в Smalltalk, некоторые личности, не разобравшись с вопросом, эту технику признали опасной.
Насчет не разобравшихся с вопросом — это Ваше мнение.
B>И сообщили, что в современных языках таких проблем нет.
Это не так. В современных языках такие проблемы есть.
B>Чтобы опровергнуть данное высказывание я и привел примеры с макросами Nemerle. Как видите, макросы тоже таят такую опасность.
Не полностью аналогичную. Вы не можете передать куда-то макрос-функцию, так как это не FCO. И это хорошо, кстати.
Да и вообще, компилятор, вообще говоря, должен указывать на выражение, значение которого не возвращается.
B> Но это же не повод отказываться от макросов в Nemerle?
Возможно, это не повод, да.
B>Конечно нет, ведь эта "проблема" не является проблемой
НО проблема проблемой таки является. Я вообще не понимаю, как тут одно из другого следует.
ПОнятно, что в ряде случаев проблемными средствами можно продолжать пользоваться. Однако не стоит отрицать проблемность этих средств.
И все равно аргументация более чем странная. Если Васе поставили тройку — это что, правдание моей двойке?
B>(ну никто ж не заставляет Вас писать return где попало).
Это не аргумент. Также можно и вычисляемый goto оправдывать. Используйте где надо, а не где ненадо — и все будет в порядке.
Могу я установить контракт на параметр принимающий блок кода, чтобы запретить передачу блока кода с ^, и чтобы это можно было проверить статически?
K>>Тут, конечно, были примеры по существу вопроса, как использование ^ помогает сократить код, но вот это вообще к делу отношения не имеет. B>Как раз имеет. Я, например, не знаю, зачем может понадобиться ^ внутри блоков кроме как в такой ситуации.
Это, как мне кажется, проблема языков в "простым логичным синтаксисом". Получается, что для решения двух с половиной задач добавляется багофича, которая в двух с половиной случаях фича — а во всех остальных — баг.
Уж лучше досыпать немного сахарку.
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Э... Обороты изящны.
Вы мне льстите.
ГВ>Но всё-таки, перечитайте ту дискуссию, на которую я ссылался.
Уже сделано.
ГВ>Пока что не хочу в очередной раз заниматься длинным разбором: что, кто и где сказал, и что это означает и какое впечатление производит. Я уже посвятил этому предостаточно букв.
Не утруждайте себя длинным разбором. Вот короткий:
Это было столкновение Википедии с евангелием от Алана Кэя. Которое закончилось, понятно, тем, что адепт Кэя высказался в том смысле что следование большинству интеллекта не требует, причем, что очень важно, в контексте дискуссии об общепринятости терминологии. Понятно даже и ежу, что общепринятость не критерий истины в общем случае. Но необщепринятая терминология не решает поставленные перед ней задачи, о чем я и писал. Понятно? В сообществе смолтокеров их терминология адекватна — в другом сообществе нет. И то, что терминологией владеют не 100 человек, а 10 — это не плюс, а минус такой терминологии.
ГВ>На самом деле, "правильны" только те значения терминов, которые были им присущи при их появлении.
Вечер юмора. Выходит, яблоко можно правильно назвать только на языке Адама и Евы? Вот умора! Да сам труд, который потребуется для исторических исследований, направленных на выяснение первого автора термина настолько "не экономичен", что дальше можно и не обсуждать.
ГВ>В противном случае мы всегда сталкиваемся с необходимостью опрашивать n/2 на предмет их согласия с текущим значением терминов. Это не экономично. Соответственно, "правильное" значение термина нужно спрашивать не у большинства голосованием, а у его автора или, скажем так, у достаточно узкого круга.
После этого останется проблема ознакомления большинства с этой терминологией. Вы ее в экономические подсчеты включили?
На самом деле так часто и делается. Вся система образования работает в основном на то, чтобы общепринятая терминология оставалась общепринятой.
ГВ> Истина таки да, всегда конкретна.
Господи, ну нельзя же так увлекаться Ильичем в наше суровое время. "Как получишь галстук — береги его, он же с красным знаменем цвета одного" и так далее. На самом деле, как это не печально, быть может, никакой истины не существует. Есть вероятность для еденицы и статистика для множества едениц. И все! Самое лучшее, что мы можем себе позволить, это средняя темпмература по больнице.
ГВ>Либо же значение термина должно параллельно уточняться, например, уполномоченными на то группами. В любом случае, круг тех, кто определяет значение термина должен быть достаточно узок, иначе мы превратим совершенно любую коллективную деятельность в бесконечные дебаты.
Мы спорим по процедурному или по принципиальному вопросу? Какое отношение к делу имеет способ, при помощи которого мы распространим терминологию на n/2 + 1 ? Главное, что пока мы это не сделаем — все что мы будем иметь, это даже не дебаты, а вавилонское столпотворение.
K>>Что касается каких-то фактических сведений о мире — тут все, конечно, сложнее. K>>Общепринято, что Земля — круглая. Это не так. Земля имеет форму геоида. Общеприянтые понятия "круг" и "геоид" нетождественны.
ГВ>На бытовом уровне — да, шар.
Если бы! На бытовом уровне люди слабо чувствуют разницу между шаром и кругом.
ГВ> Но на бытовом уровне и Солнце вокруг Земли может вращаться. Но попробуй, докажи это тем, кто связан с навигацией.
Тут вроде был огромный флейм по поводу того, имеет ли значение что вокруг чего вращается? Я его, правда не нашел. Очень показательный пример, кстати. Особенно если у честь, что оба широко известных варианта — неправильные.
K>>Общепринято, что вечный двигатель первого рода невозможен. Это действительно так (с очень хорошей вероятностью -> 1). Означает ли это, что перпетуум-мобилистов зажимает тупое большинство?
ГВ>Нет. Это означает, что в даном случае большинство более или менее усвоило законы физики.
Выходит, что мифическая тирания большинства это не во всех случаях тирания глупости? И наоборот тоже? Именно об этом я и говорю.
K>>В большинстве случаев все упирается в договоренность. Кое-что можно доказать, но в рамках системы, непротиворечивость которой невозможно доказать в принципе. Что-то можно проверить на опыте (впрочем, доказательстов в этом случае будет иметь гм... статистический характер. В конце концов, вопросы в науке решаются не голосованием людей, а гы-гы голосованием экспериментов) ГВ>Это ещё что такое: голосование экспериментов?
"гы-гы голосование экспериментов" — это шутка, основанная на том, что провести два одинаковых эксперимента с тождественным с какой угодно точностью результатом — невозможно. Но это средняя школа, седьмой класс. Стоит ли обсуждения?
ГВ>Я и не додумывал за автора. Я озвучил впечатление, которое произвели его слова и полагаю, что не сильно промахнулся.
С впечатлением вообще невозможно промахнуться, потому что впечатление много говорит о том, кто впечатляется, а не о том, что впечатляет. У людей обычно очень разные впечатления об одном и том же.
ГВ> Нехай автор лучше формулирует свои мысли, дабы не. Коли уж он хотел сказать что-то другое.
К этому надо стремится, но судить за неудачу не стоит. В конце концов, легче переплыть Атлантический океан по-собачьи, а потом изобрести эликсир вечной молодости чем сказать что-то нетривиальное так, чтобы ВСЕ поняли одинаково.
K>>Вот он, образ врага! Скифы, азиаты. Их много. Слышится ржание их коней. Размахивают. Голова — чтобы в нее есть. K>>Подтягивают к стенам нашей цитадели осадные ветряные мельницы на колесах. ГВ>Ах, сколь витиеваты слова, непонятные слуху простого программиста. Я прямо слышу победное ржание сфероконей и чую ммм... смрад кипящей смолы, которую льют со стен осаждённые. Если бы ещё это имело какое-то отношение к делу.
Самое прямое. Если на пальцах то:
Мировосприятие через метафору борьбы сплющивает это самое мировосприятие до состояния амбразуры и обязательно ведет к ничем не оправданной элитаризации себя и своих единомышленников и варваризации оппонентов.
NB: Людям и так друг друга понять не просто, а если еще и добрая воля необходимая для понимания отсутствует — это полный бесперспективняк.
ГВ>Да, к сожалению, во "внутреннем пользовании" очень часто приходится прибегать к додумыванию. Иначе многих просто невозможно понять.
Всех. Я объяснил почему. Если думаете, что кого-то хорошо понимаете — почитайте что-нибудь (только не opera omnia Ильича!) и это пройдет.
K>>Впрочем, воспринимать продукт творчества любого автора без некоторой доли фантазии — совершенно невозможно. Ведь существует же недоговоренность. Всегда. Любые слова вырваны из контекста, который у автора в голове и нам совершенно не известен. ГВ>Весь контекст доступен по приведённой мною ссылке. Прочтите, не пожалеете.
Ну да, кое какой контекст доступен, пофантазировать можно, вот только на контекст, который в головах участников обсуждения ссылку не дать.
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, WolfHound, Вы писали:
WH>Те парсер должен сформировать дерево которое удобно печатать? А ты в курсе что этот код находится в разделе misc те этого кода может и не быть и все будет работать?
Ничего не понял.
WH>Но прикол в том что у нас еще есть генератор кода которому начхать на то что к нему пришло унарный оператор или функция с одним параметром.
А как принтер отличает унарный оператор от функции с одним параметром?
WH> Ты можешь возразить что у нас есть встроеные типы и их нужно по особенному обрабатывать в MSIL'е но на это есть убойный аргумент: А зачем о встроеных типах знать парсеру, типизатру, макросам...? Не забываем про пользовательские операторы... Зачем на этих очень не простых стадиях лишнии детали?
Ничего не понял.
WH>И все это нужно засунуть в АСТ? И кстати в какое АСТ? их там несколько...
Несколько AST? Это пример сильного дизайна?
WH>Короче чистый ОО тут ни разу не рулит.
Пока что, кроме необходимости создания кучи AST, я "рулежа" не увидел.
Короче, меня абсолютно не волнует ни пригодность патерн-матчинга, ни пригодность ООП для создания AST. Я просто в очередной раз хотел напомнить, что если что-то сравниваете, то сравнивать нужно корректно. А трансляция "один в один" кода из парадигмы в парадигму это профанация.
ANS>>Это не расширение, а кривой костыль. WH>Отрицание... любимый прием пуристов... Великий магистр оберона темже самым занимается. WH>Аргументы будут?
Простой пример, завернул ты это расширение в либу, а у васи пупкина оно не работает, потому, что забыл вася это расширение скотчем в нужном месте прикрутить.
FDS>Ну и? А для программистов, которые пишут на Лиспе разве важно, как было писать этот ЛИСП другим программистам. Нет, им важно удобство. Покажите мне удобство для программистов, которые используют язык, а не пишут для него компилятор. Я могу за день написать простой компилятор языка assembler для Intel 8080, например, или Siemens не помню каких, но пользоваться то этим компилятором не мне. Понимаете о чём речь? Вы мне доказыватете, что для ЛИСПа удобно писать компилятор, а нужно доказывать что НА ЛИСПе удобно писать.
Нет, этого доказывать не нужно. Для реальной конторы надо было доказать совсем другое — реальность бизнес-плана. Бизнес-план включает в себя деньги, сроки и набор фич, которые требуется реализовать за это время и за эти деньги. Ведь тут речь шла о стратапах, так вот, Автокад — это кодгда-то был именно таким на коленке собранным "стартапом" (хотя на тот момент еще не было такого термина). Если бы первые версии автокада выпускала бы мощная и весьма богатая контора, я не сомневаюсь, что они позволили бы себе так же удобные для программиста фичи. Хотя... и в этом у меня большие сомнения. Первые версии вышли тогда, когда об удобстве для программиста речи не было вообще. Ну вот как-то я не слышал в те времена дисскусий на эту тему. Расширять Автокад должны были не конечные пользователи, а специализирующиеся на этом програмисты-прикладники.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[27]: Не нужность super return (нелок. возврата) [рассм. п
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>Т.е. вы предлагаете примерно так: S>Нет. Предлагаем срочно идти изучать семантику finally.
Вот накинулись, как будто я её не знаю
Re[27]: Не нужность super return (нелок. возврата) [рассм. п
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>Т.е. вы предлагаете примерно так: S>Нет. Предлагаем срочно идти изучать семантику finally.
Кстати, вы не поняли мой код, с finally он работать не будет
Здравствуйте, Andrei N.Sobchuck, Вы писали:
WH>>Те парсер должен сформировать дерево которое удобно печатать? А ты в курсе что этот код находится в разделе misc те этого кода может и не быть и все будет работать? ANS>Ничего не понял.
А чего тут не понятного? Это опциональный код которого может и не быть. Он не нужен компилятору для работы.
И хардкодить его в основной АСТ просто верх кривизны.
WH>>Но прикол в том что у нас еще есть генератор кода которому начхать на то что к нему пришло унарный оператор или функция с одним параметром. ANS>А как принтер отличает унарный оператор от функции с одним параметром?
В том куске кода что я приводил все есть. Если ты не в состоянии его понять то почему ты судишь о pattern-mattching'е.
WH>> Ты можешь возразить что у нас есть встроеные типы и их нужно по особенному обрабатывать в MSIL'е но на это есть убойный аргумент: А зачем о встроеных типах знать парсеру, типизатру, макросам...? Не забываем про пользовательские операторы... Зачем на этих очень не простых стадиях лишнии детали? ANS>Ничего не понял.
Это я к тому что загонять функциональность сотней match'ей в AST кривое решение.
Единственное правильное направление это внешняя обработка AST, а в ОО это визитер или рукопашный pattern-mattching на куче if'ов. Но проблема в том что визитер сливает в сложных случаях типа
а куча if'ов совершенно не читабельна.
Визитер не может распознять такоей паттерн. Это придется писать ручками.
WH>>И все это нужно засунуть в АСТ? И кстати в какое АСТ? их там несколько... ANS>Несколько AST? Это пример сильного дизайна?
А ты в состоянии скомпилировать Nemerle используя только один AST?
WH>>Короче чистый ОО тут ни разу не рулит. ANS>Пока что, кроме необходимости создания кучи AST, я "рулежа" не увидел.
Необходимость нескольких AST происходит из сложности задачи. Кстати я сомневаюсь что найдется хоть один компилятор современного языка в котором только одно представление кода.
А то что ты не понимаешь pattern-mattching это твои личные проблеммы.
ANS>Короче, меня абсолютно не волнует ни пригодность патерн-матчинга, ни пригодность ООП для создания AST. Я просто в очередной раз хотел напомнить, что если что-то сравниваете, то сравнивать нужно корректно. А трансляция "один в один" кода из парадигмы в парадигму это профанация.
Ну так давай сравнивать.
Перепиши те несколько строк что я приводил в ОО стиле.
ANS>Простой пример, завернул ты это расширение в либу, а у васи пупкина оно не работает, потому, что забыл вася это расширение скотчем в нужном месте прикрутить.
А ты думаешь если ОО решение не заточить на расширяемость оно будет чудесным образом работать? Наивный...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>1. Он (или Kolhoz? подозреваю, что это один и тот же человек) высказал очень верную мысль: програмирование — занятие не для всех и нечего на этих самых "всех" равняться. Мне это чертовски нравится.
Опять началось, мы "элита", круче нас бывают только яйца, а всем остальным программирование не осилить и даже и не пытайтесь. Если бы у всех программистов было такое мнение, программисты бы вымерли как вид.
К тебе никогда не подходили дети школьного возраста с огоньком в глазах и с вопросами по программированию ? Что ты им отвечаешь ? Дай угадаю: "сынок, это слишком сложно для тебя, это только для элиты, иди лучше в игрушки поиграй". Может это следующий Линус Торвальдс, Бьярн Страуструп, итд итп
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Kisloid, Вы писали:
K>К тебе никогда не подходили дети школьного возраста с огоньком в глазах и с вопросами по программированию ? Что ты им отвечаешь ? Дай угадаю: "сынок, это слишком сложно для тебя, это только для элиты, иди лучше в игрушки поиграй". Может это следующий Линус Торвальдс, Бьярн Страуструп, итд итп
Молодой человек, итересующийся программированием с огоньком в глазах -- это и есть та будущая элита программирования. Встретится с таким -- большая удача.
К сожалению, ситуация сейчас обратная. Слишком много тех, кто пытается заниматься программированием без огонька в глазах. И спрашивают, в десятый раз, одно и то же, чем же отличается p от c в приведенном примере, и почему изменение p не изменяет c:
char c = 'A';
char * p = &c;
++p;
Мой опыт показывает, что те, у кого глаза горят, понимают разницу между объектом и указателем на объект сразу. А вот тем, кто сразу не понимает, лучше, действительно, в игрушки поиграть.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, vdimas, Вы писали:
V>Я лично ничуть про макросы не переживаю. Сам на С++ использую на всю катушку, невзирая на всякие "рекомендации", ибо если есть удобный инструмент — почему бы не воспользоваться?
Ну всё! Лучше бы этого не говорил
V>Не сомневаюсь, что для тебя Nemerle удобен. Но вот у меня тут скоро встанет вопрос, какую технологию избрать для следующего проекта. Как ты думаешь, я рискну применить его в своей команде?
Я бы без предварительного погружения и чёткого понимания что происходит не рискнул. Я, кстати, и не призываю никого прямо сейчас брать и использовать N в коммерческих продуктах. Хотя, конечно, если есть желание, то почему бы и нет.
С другой стороны, это же ведь не последний твой проект, правда? К следующему уже можно будет решить надо оно тебе или нет. Но для этого, опять же, надо будет сначала пробовать.
V>Тут народ еще даже анонимные делегаты из C#2.0 боится юзать и спотыкается на иерархии ограничений генериков... А ты говоришь — Немерле
Проблема в том, что мозги императивного программиста повёрнуты на решение задач без всяких делегатов. А дибильные (простите, други, но другого слова не подобрать) примеры из серии list.ForEach() только усугубляют ситуацию, т.к. в импертивном стили они решаются не менее эффективно, а для императивщика выглядят куда проще и понятнее.
Тут надо искать примеры, которые действительно показывают силу ФП, где ФП резко устраняет дублирование кода и делает его намного проще. В принципе, если есть интерес, то такие примеры можно привести.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Klapaucius, Вы писали:
ГВ>>Пока что не хочу в очередной раз заниматься длинным разбором: что, кто и где сказал, и что это означает и какое впечатление производит. Я уже посвятил этому предостаточно букв. K>Не утруждайте себя длинным разбором. Вот короткий: K>Это было столкновение Википедии с евангелием от Алана Кэя. Которое закончилось, понятно, тем, что адепт Кэя высказался в том смысле что следование большинству интеллекта не требует, причем, что очень важно, в контексте дискуссии об общепринятости терминологии. Понятно даже и ежу, что общепринятость не критерий истины в общем случае. Но необщепринятая терминология не решает поставленные перед ней задачи, о чем я и писал. Понятно? В сообществе смолтокеров их терминология адекватна — в другом сообществе нет. И то, что терминологией владеют не 100 человек, а 10 — это не плюс, а минус такой терминологии.
Ну причём тут "адепт"? Опять на личности переходим? Нехорошо-с. Слона-то Вы и не приметили. Напоминаю начало определения, даваемого википедией (я выделил кое-что):
In computer science, object-oriented programming is a computer programming paradigm. Many programming languages support object-oriented programming (ref). Many programming frameworks, like the Java platform and the .NET Framework, are built on object-oriented principles. Object-oriented programming is often abbreviated as OOP.
...A programming paradigm provides (and determines) the view that the programmer has...
И понимаете ли в чём дело. После того, как, фактически, в определении ООП, которым потрясали как "общепринятым", появилась сугубо субъектная характеристика ("взгляд"), дальнейшими рассуждениями относительно правильности, по крайней мере, этого определения можно поливать цветы (коли не увянут). А потому размахиванием подобным определением есть сугубая бездумность.
В противовес этому определению выставлялись слова Алана Кея. Кстати, я не нашёл канонической цитаты, но кое-что можно посмотреть, например, здесь:
OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other
systems in which this is possible, but I'm not aware of them.
Грубоватый перевод:
ООП для меня означает только обмен собщениями, локальное хранение, защиту
и скрытие состояния процесса, и только позднее связывание. Это можно сделать
на Smalltalk и Lisp. Возможно, есть и другие системы, но я ничего
о них не слышал.
Но что характерно, здесь нет такого понятия, как "взгляд". Что почему-то меня не удивляет, даже не знаю, почему. Но одновременно я почему-то не удивлён появлению слова "взгляд" в википедии.
Вы разницу между объектным и субъектным определением понимаете? Надеюсь, да. Так вот, если "общепринятым", почему-то оказалось субъектное определение (тем паче, в технической области), то это означает, что ошибку совершает то самое большинство. А такие источники как Википедия нередко озвучивают бытующие убеждения, а отнюдь не "копают глубоко". Думаю, что в средние века в Википедии вполне могло быть написано, что Солнце — из чистого золота, а все симпатичные женщины — ведьмы. Тоже общепринятое мнение было на определённом этапе.
Возвращаясь к упомянутой дискуссии. Адепт там был или не адепт — не суть важно. Важно, что он сказал правильную вещь про бездумное следование за большинством. А в случае с определением объекта через субъект так оно и есть.
ГВ>>На самом деле, "правильны" только те значения терминов, которые были им присущи при их появлении. K>Вечер юмора. Выходит, яблоко можно правильно назвать только на языке Адама и Евы? Вот умора! Да сам труд, который потребуется для исторических исследований, направленных на выяснение первого автора термина настолько "не экономичен", что дальше можно и не обсуждать.
Причём тут конкретный язык? "Яблоком" же не стали называть, например, абрикосы? Кроме того, яблоком не называют, например, "взгляд из-под подушки в невечернем свете закатной Луны".
ГВ>>В противном случае мы всегда сталкиваемся с необходимостью опрашивать n/2 на предмет их согласия с текущим значением терминов. Это не экономично. Соответственно, "правильное" значение термина нужно спрашивать не у большинства голосованием, а у его автора или, скажем так, у достаточно узкого круга. K>После этого останется проблема ознакомления большинства с этой терминологией. Вы ее в экономические подсчеты включили? K>На самом деле так часто и делается. Вся система образования работает в основном на то, чтобы общепринятая терминология оставалась общепринятой.
Примерно это я и имел ввиду. К сожалению, системе образования попросту не всегда удаётся своевремнно сработать. Вот и получается кавардак.
ГВ>> Истина таки да, всегда конкретна. K>Господи, ну нельзя же так увлекаться Ильичем в наше суровое время. "Как получишь галстук — береги его, он же с красным знаменем цвета одного" и так далее. На самом деле, как это не печально, быть может, никакой истины не существует. Есть вероятность для еденицы и статистика для множества едениц. И все! Самое лучшее, что мы можем себе позволить, это средняя темпмература по больнице.
Угу. И это и есть конкретный и точный ответ на вопрос: "Какова средняя температура по больнице?" Но это не то же самое, что и: "Какова температура Васи Пупкина?"
K>>>Общепринято, что вечный двигатель первого рода невозможен. Это действительно так (с очень хорошей вероятностью -> 1). Означает ли это, что перпетуум-мобилистов зажимает тупое большинство? ГВ>>Нет. Это означает, что в даном случае большинство более или менее усвоило законы физики. K>Выходит, что мифическая тирания большинства это не во всех случаях тирания глупости? И наоборот тоже? Именно об этом я и говорю.
Да, разумеется. Я и не пытаюсь оспаривать это самое "не всегда". Это вообще параллелное рассуждение. Я говорю, что бессмысленно требовать от следования за большинством, только потому, что это большинство. Не видите разницы?
ГВ>>Я и не додумывал за автора. Я озвучил впечатление, которое произвели его слова и полагаю, что не сильно промахнулся. K>С впечатлением вообще невозможно промахнуться, потому что впечатление много говорит о том, кто впечатляется, а не о том, что впечатляет. У людей обычно очень разные впечатления об одном и том же.
Ну что же, это Ваше неотъемлемое право: делать выводы о чём и о ком угодно.
ГВ>> Нехай автор лучше формулирует свои мысли, дабы не. Коли уж он хотел сказать что-то другое. K>К этому надо стремится, но судить за неудачу не стоит. В конце концов, легче переплыть Атлантический океан по-собачьи, а потом изобрести эликсир вечной молодости чем сказать что-то нетривиальное так, чтобы ВСЕ поняли одинаково.
Если Вы заметили, я не осуждаю автора. И даже не пытаюсь назвать его адептом чего-то. Но уж если возникла двусмысленность, то как тут не ляпнуть: "Ай, да Пушкин, ай, да сукин сын!" Хотя в общем я обращаюсь к словам и их расположению.
K>NB: Людям и так друг друга понять не просто, а если еще и добрая воля необходимая для понимания отсутствует — это полный бесперспективняк.
Почему же отсутствует? Наоборот, не понимай мы друг друга, так и не смогли бы даже общаться, не то, что спорить. Скорее уж добрая воля отсутствует у тех, кто идёт за большинством ради большинства.
K>>>Впрочем, воспринимать продукт творчества любого автора без некоторой доли фантазии — совершенно невозможно. Ведь существует же недоговоренность. Всегда. Любые слова вырваны из контекста, который у автора в голове и нам совершенно не известен. ГВ>>Весь контекст доступен по приведённой мною ссылке. Прочтите, не пожалеете. K>Ну да, кое какой контекст доступен, пофантазировать можно, вот только на контекст, который в головах участников обсуждения ссылку не дать.
А он как раз и не важен. Или это сетование на невозможность "предметного мозговедства"?
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, FR, Вы писали:
FR>В динамике нет никаких приведений, какой тип передали тот и используется, и исключение если он не подерживает то что требуется. И хаками это является только для статических языков.
Динамика разная конечно бывает. Но если можно вот так свободно сложить разные числа из массива, то неявные приведения есть. Хотя конечно есть один выход... хранить все числа в виде единобразных объектов поддерживающих числа неограниченного размера. Но вот эффективность у такого подхода ой как не высока. Автор компилируемого язык на такое пойти не может.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Просто в ST авторы решили, что метод ForEach ничуть не хуже встроенного оператора foreach.
Мне просто не хочется тратить время на развинчание твоего мнения. Оставайся при нем. Авторы Смолтока тоже пусть остаются при своем, а Смолток пусть занимает то место которое он заслужил. Все ОК.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>В динамике нет никаких приведений, какой тип передали тот и используется, и исключение если он не подерживает то что требуется. И хаками это является только для статических языков.
VD>Динамика разная конечно бывает. Но если можно вот так свободно сложить разные числа из массива, то неявные приведения есть.
Совсем не обязательно. Достаточно того, чтобы метод, реализующий сложение, умел обрабатывать аргументы разных типов (что в случае динамической типизации выполняется элементарно, если все ожидаемые типы имеют одиаковый набор методов, использующихся в данном). Несколько отдельно стоят методы, реализованные через примитивы VM — потому что они не вызывают других методов. Но и в этом случае достаточно того, чтобы примитив просто умел обрабатывать аргументы разных типов.
FDS> Кстати, вы не поняли мой код, с finally он работать не будет
Прекрасно будет. Или ты полагаешь, что если вылетело не SuperReturn, то Unlock() делать не надо???
Кроме того, рекомендую еще разочек перечитать насчет запрета на внесение всякой ерунды типа обращения к базе в библиотечный ForEach.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали:
E>Вот интересно. Пусть дорогой разработчик на Java в Москве получает $3K в месяц. И требуется ему писать софт, который работает под Windows, Linux, Solaris и MacOS. Затраты на него будут составлять $3K в месяц + $500 на приобретение IDEA. JDK для всех этих платформ бесплатен.
Давайте оформим разработчика как ИП, тогда затраты на IDEA будут всего $200, экономия будет $300. А вообще, возьмем лушче Eclipse, тогда все $500.
E>А теперь вопрос: можете ли вы перечислить преимущества, которые Eiffel может дать разработчикам (не важно дешевым или дорогим) по сравнению с C# или Java? Настолько важные преимущества, которые окупили бы стоимость Eiffel-евских средств разработки?
В контексте рассмотренной абстрактной задачи — нет. Тем более, что вами явно предполагается одинаковое время общей разработки (включая проектирование, написание кода и отладку). Однако, это еще вопрос. Поскольку сам с eiffel не знаком, то и говорить не буду, но ясно только одно, что это время не одинаково. При имеющемся значении насколько не оиднаково, можно давать ответы и на другие вопросы.
E>И еще один вопрос в догонку: что же делать компании, которая вложила такие деньги в средства разработки и обучение специалистов, выпустила кроссплатформенный продукт на Eiffel (под Windows, Linux, Solaris, MacOS). А затем бах -- нужно его портировать под UP-UX и AIX.
Заранее думать надо чем разрабатывать (и где) и как собирать. Java и .Net в этом плане тоже не панацея.
Я, вообще-то, только обратил внимание на то, что сам eiffel и его создатели цветут и пахнут. Конечно, с рынком приходится считаться, но если бы язык был в полной даже не знаю как сказать где, то не было бы сайта eiffel.com, поскольку его оплачивать тоже надо. И язык вовсе как-то не страдает тем, что он не популярен в массах. Ему и не надо этого.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Я, вообще-то, только обратил внимание на то, что сам eiffel и его создатели цветут и пахнут. Конечно, с рынком приходится считаться, но если бы язык был в полной даже не знаю как сказать где, то не было бы сайта eiffel.com, поскольку его оплачивать тоже надо. И язык вовсе как-то не страдает тем, что он не популярен в массах. Ему и не надо этого.
Ну разработчики абсолютно бесплатных языков тоже не жалуются на жизнь, у них и сайты есть и языки на порядки более популярные чем Эйфель.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
E>>А теперь вопрос: можете ли вы перечислить преимущества, которые Eiffel может дать разработчикам (не важно дешевым или дорогим) по сравнению с C# или Java? Настолько важные преимущества, которые окупили бы стоимость Eiffel-евских средств разработки? TBG>В контексте рассмотренной абстрактной задачи — нет. Тем более, что вами явно предполагается одинаковое время общей разработки (включая проектирование, написание кода и отладку). Однако, это еще вопрос. Поскольку сам с eiffel не знаком, то и говорить не буду, но ясно только одно, что это время не одинаково. При имеющемся значении насколько не оиднаково, можно давать ответы и на другие вопросы.
Откуда это вам ясно, если вы с Eiffel не знакомы?
Например, я весной этого года
уделил массу своего времени ознакомлению с Eiffel и ситуацией вокруг него. В частности, проштудировал две книги по Eiffel-ю, которые шли в составе EiffelStudio, попробовал EiffelStudio и SmartEiffel, попробовал нарыть Internet-ресурсы и библиотеки для Eiffel. Ничего похожего на community C, C++, Java, Ruby, Perl, Python, Tcl/Tk нет и в помине. Вообще. Единственное достойное собрание библиотек -- только в составе EiffelStudio. Но и оно не идет ни в какое сравнение в тем, что есть для перечиленных мной выше языков (а ведь еще можно вспомнить .NET Framework, C# и Nemerle).
И в самом языке я увидел только один момент, который мог бы позволить конкурировать Eiffel-ю с Java или C#. Это Design by Contract. Но этот момент с лихвой компенсируется громаднейшим количеством готовых библиотек и фреймворков для Java/C#. А если сравнить Eiffel, например, со Scala и Nemerle, то даже в языковом плане Eiffel не имеет никаких преимуществ (даже с учетом отсутствия в Scala поддержки Design By Contract). А есть еще и D, который вообще имеет все, что есть в Eiffel-е.
И добавим сюда еще кровную вражду между Мейером и разработчиками SmartEiffel, то так же не идет на пользу языку.
Так что я отвественно говорю, что просле проведенного мной исследования языка Eiffel я не нашел в нем таких достоинств, из-за которых его стоило предпочесть современным managed языкам. А я примеривался к Eiffel совершенно серьезно.
E>>И еще один вопрос в догонку: что же делать компании, которая вложила такие деньги в средства разработки и обучение специалистов, выпустила кроссплатформенный продукт на Eiffel (под Windows, Linux, Solaris, MacOS). А затем бах -- нужно его портировать под UP-UX и AIX. TBG>Заранее думать надо чем разрабатывать (и где) и как собирать. Java и .Net в этом плане тоже не панацея.
Угу, гладко было на бумаге. Вам не приходилось сталкиваться с ситуацией, когда вы собственный продукт разрабатываете с расчетом на платформы Windows, Linux и Solaris, а затем приходит богатый клиент и говорит: "Я хочу купить ваш продукт, но у нас M мегабаксов вбухано в инфраструктуру AIX-а, есть готовые ресурсы, есть обученный персонал и мы не хотим разводить зоопарк платформ". Я вообще не знаю, найдется ли менеджер, который в таких условиях скажет клиенту: "Извините, но мы не можем вам ничего предложить". Уж скорее ответит: "Да нет проблем, нам нужно только недельки две-три на адаптацию и все будет у вас прекрасно работать. Но и стоить решение будет на 30% дороже". Даже если за эти две-три недельки разработчикам придется переписать 70% кода
TBG>Я, вообще-то, только обратил внимание на то, что сам eiffel и его создатели цветут и пахнут. Конечно, с рынком приходится считаться, но если бы язык был в полной даже не знаю как сказать где, то не было бы сайта eiffel.com, поскольку его оплачивать тоже надо. И язык вовсе как-то не страдает тем, что он не популярен в массах. Ему и не надо этого.
Вы, вообще-то, обратили внимание только на факт наличия eiffel.com и на большие цены на Eiffel. И предположили, что EiffelStudio по таким ценам раскупают. А вот для меня это ничего не значит. Поскольку с такой же вероятностью события могут развиваться как в анекдоте: "По чем спички? $10 за коробок. А почему так дорого? Деньги очень нужны". Для того, чтобы поверить в то, что Eiffel цветет и пахнет, нужно бы посмотреть на графики их продаж. А так же наблюдать количество Eiffel-евских проектов.
А пока складывается впечатление, что в свое время они подцепили ряд богатых клиентов, вроде военных и авиапромышлеников, и теперь продолжают им продавать свой EiffelStudio по баснословным ценам. А тем и деваться не куда, поскольку проще заплатить, чем переписывать унаследованные системы. Зато новых пользователей они привлечь уже не могут. Свительством чему является бесплатная (но закрытая) версия EiffelStudio (от хорошей жизни приносящий деньги продукт бесплатно раздавать не будут). Так что запах получается с душком.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Кстати, вы не поняли мой код, с finally он работать не будет 
Если нам не помогут, то мы тоже никого не пощадим.
1.1.4 stable rev. 510
