Вышел MonoDevelop 0.12

Когда я только-только начинал учить C++, ещё в школе, у меня был таки шок по поводу private и protected. И до сих пор не могу до конца врубиться, зачем программисты сами себе строго запрещают чем-то пользоваться? Не признак ли шизофрении? А потом крепко бесился, когда нужные мне методы библиотечного класса были объявлены как private из каких-то фашистских соображений, или какие-то методы не были объявлены как virtual. В общем, кто ещё не догнал, Питон рассчитан не на девочек, которые сами не знают, что у них на уме, а на взрослых мужчин. B-) Понадобились чужие приватные методы - получай, но отвечать будешь сам.

>Питон рассчитан не на девочек, которые сами не знают, что у них на уме, а на взрослых мужчин...

...которые ищут приключений на собственную жопу.

r, признайся, ты дома все острые ножи и вилки спрятал в стальной сейф, ключ от сейфа отдал жене, а жену отправил в далёкий монастырь в горах Алтая, куда летают только вертолёты раз в четыре года в день летнего солнцестояния? А я вот привык держать их в ящике стола. Определённо, ищу приключений на собственную жопу. :D

> Ага - твой подчерк очень помешает армии индусов ими воспользоваться. Зачет.

сдается мне что флудер по имени r никакое не девелопер а простой админ эникейщик в конторе из семи с половиной машин только такие как он любят все всем запрещать и ловят от этого свой странный кайф давить

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

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

>А я вот привык держать их в ящике стола

Что ж ты их не разложил повсей квартире? Поразбрасывай на диване, на кресле, в ванной не забудь десяток промышленных кнопок разложить.

А то запер в ящик стола, и думает герой. Ведь это это ж ежу понятно - на диван надо садиться на свой страх и риск в расчете на то, что там добрый ero-sennin мог оставить гвозди.

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

Не - 7 машин - такого я не асилю. Это ты загнул. Ты меня раскрыл - у меня 3 машины - 2 корвета и один 384SX с которого я пощу на лор. В подчинении у меня сторож сельского клуба, где все это располагается, и я испытываю немерянный кайф када ору на него по поводу незакрытых дверей в туалете на улице.

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

Прямо сейчас не могу - извини. Я еще не получил дозу удовольствия от орания на сторожа моего сельского клуба.

> Java с небольшим шифтом в сторону GUI приложений (Java все таки shift имеет в ентерпрайз больше)

аццкое бугога ты нерусский дружочек? кто тебя куда имеет небольшим штифтом раскрой тему будь любезен?

> MS over Java, +конкуренция MS.NET Framework.

кто говоришь был сверху? и MS.NET сбоку? мне начинают нравится твои фантазии но нельзя неьлзя нельзя быть таким неудовлетворенным охх уссусь

>аццкое бугога ты нерусский дружочек?

Канешна нет. Албанский с примесью нанайской крови.

>мне начинают нравится твои фантазии но нельзя неьлзя нельзя быть таким неудовлетворенным охх уссусь

Ты не терпи - это вредно для перистальтики. Схожи в туалет - потом допишешь. Не нервничай так.

> Когда я только-только начинал учить C++, ещё в школе, у меня был таки шок по поводу private и protected. И до сих пор не могу до конца врубиться, зачем программисты сами себе строго запрещают чем-то пользоваться?

Про "контрактное программирование" и "интерфейсы" слышал?

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

все споры насчет языков сводятся - ниасилил ...

PS
кстати за анонимные функции не к месту
надо отрывать все выступающие части тела

> Переход между версиями GCC бьет по моральному состояниюю когда фиксишь под него C++ приложение так, что вспоминаешь такие словечки, которые думаешь, что давно забыл.

Так вы пишите нормально. Перенос 1.2мб кода с g++ 3.2 на 4.1 потребовал убрать три штуки extra qualification и добавить одну точку с запятой. Заодно стали использовать свежий ffmpeg, для него изменений больше пришлось сделать :)

>> ЗЫ: кстати, в питоне еще нужно в методах писать первым аргумент self? Эта фишка немного раздражала, когда я к нему присматривался.

>Да надо. И я так понимаю что это врядли когда-либо измениться. Меня не напрягает. Зато нет бардака как в C++ хочешь this пиши, хочешь не пиши. В Питоне партия сказала надо :-)

Я немного не точно выразился. Имеется ввиду, нужно ли при объявлении методов:

def some_method(self,...):

писать первым аргументом self? То, что при обращении к ним нужно писать self.method, фишка вполне нормальная.

r:
>>Это абсолютно верно, при соблюдении 1 маленького "но": если в программе используются только те средства языка и библиотеки, которые описаны в стандарте.

>Про сферических коней неинтересно.

>Код который написан по спеке 1998 не скомпиляется на компиляторе по спеке 2003 года. Равно как и наоборот. Хотя все в соответсвии со стандартом определенного времени.


кончай пугать народ и сам вылазь из бомбоубежища- уже 2006 год, и никакой катастрофы не произошло- в GNU/Linux чудненько используются сотни Mb исходников, среди которых попадаются написанные не то что в 1998 году- но и лет на двадцать раньше (посмотрим, что за такой срок сделает MS c дотнетовскими стандартами);
при желании можно использовать один и тот же gcc на в разы большем количестве платформ, чем моно;
в плане совместимости версий от различных производителей mono тоже похвастать нечем(знаю-знаю- "Не больно то и хотелось!"), в то время как немаленькие проекты типа Mozilla или Apache собираются на различных платформах и различными компиляторами;

пренебрежительного отношения к кросплатформеным библиотекам я тоже решительно не понял- чем поможет использование mono в случае, например, несовместимости Linux и MacOS версии какой-нибудь функции в сишных библиотеках GTK, QT или там OpenGL? оно же, в конечном итоге, использует те-же самые библиотеки? Только выбор хороших кросплатформеных сишных библиотек зааметно богаче...

мне случалось и использовать в Linux код, написанный под невесть какой UNIX еще до Прозрения Столмана, и портировать собственный код на Win/VC- и в обоих случаях трудозатраты были минимальны

> Я немного не точно выразился. Имеется ввиду, нужно ли при объявлении методов

Да нет. Ты вполне точно выразился. Я тебя так и понял. Просто ответил несколько шире :-)

При объявлении методов обязательно надо писать self.

например:

def someMethod(self, *args, **kwds):

> Теперь сам вопрос. Можно ли так сделать с помощью Tcl/Tk или Python?

> Насчёт Python гляну, не приходилось. Но думаю, что аналогичный механизм есть и там...

Active Python подойдет?

> Имеется в виду, что BerkleyDB нереляционная, использует хэш данных.

> Так пойдёт ?

На научном языке это называется "навигационная СУБД". К навигационным относятся/относились dBASE и ее клоны.

> * Отстутсвие полноценных анонимных функций.

А что, разве полноценная лямбда -- это уже не "анонимная функция"? И что в, таком случае Вы понимаете под анонимными функциями?

> Пример: Dir.chdir - без блока - просто зайти в директорию. С блоком Dir.chdir { тут пишем все что мы делаем в каталоге } заходит в каталог и выполняет блок кода в нем. За блоком делает обратный переход.

def echo(string):
   print string
 
def chdir(code=None):
   dir = "child_dir"
   echo(dir)

   if code:
      code(dir)
      dir = "parent_dir"

   echo(dir)

>>> chdir
<function chdir at 0x2ae27a22b848>
>>> chdir()
child_dir
child_dir
>>> chdir(lambda dir: echo("Processing %s" % dir))
child_dir
Processing child_dir
parent_dir

> * Нормальное разделение доступа к атрибутам класса.(не нужно использовать _ для приватных переменных...)

Вы не пояснили, зачем это нужно. В смысле, Вы не пояснили, чем мешает явное синтаксическое определение для приватных членов. Например, в C++ использование подчеркивания в начале имен параметров конструктора является требованием некоторых стилей. Это тоже плохо?

> Имхо, полезность private методов переоценена.

+1. Еще со времен проектирования на C++ помню упорное желание членов мигрировать в открытую часть. Даже сейчас на Eiffel часто спотыкаюсь о проблему "запертых атрибутов", а ведь там система защиты намного гибче. Разве что, позволяет лишний раз подумать над тем, "а нужно ли открывать доступ именно к этому члену"? Но это все декаданс и концептуальщина. В реале проще открыть доступ.

> Гмм, а что в питоне нет свойcтв?

Очевидно, что есть. Но там какие-то грабли, уже не помню деталей, но сам полгода назад натыкался, выкрутился каким-то боком через те самые getAttr и setAttr. В общем, мне тоже не понравилось.

> По поводу аргументов на которые я не ответил (про анонимные функции и блоки), этих фич в питоне действительно нет, но Гвидо говорит что оно нам и не надо, лично я склонен ему верить.

И таки есть, просто более многословно. Но если уж сравнивать по многословности, то тут Lisp, Haskell, а особенно APL/J уделывают всех.

> Про "контрактное программирование" и "интерфейсы" слышал?

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

>> Гмм, а что в питоне нет свойcтв?

>Очевидно, что есть. Но там какие-то грабли, уже не помню деталей, но сам полгода назад натыкался, выкрутился каким-то боком через те самые getAttr и setAttr. В общем, мне тоже не понравилось.

Это был риторический вопрос :-)

Разумеется в питоне своейства есть и работают они хорошо. Там есть небольшие грабли с тем, что класс у которого объявляются свойства должен быть new-style классом, т.е. потомком object.

Ты часом не на эти грабли наступил?

> Ты часом не на эти грабли наступил?

Уже не помню точно. Сейчас грепнул исходники -- использую это только для рефлексии. Видимо, "рассосалось за ненадобностью". Или таки сделал на врапперах. Вспомнил только, что нужно было реализовать свойство, и пришлость перекрывать getAttr и setAttr, и там рисовать диспетчер по именам свойств. А это явное ухудшение стиля.

Судя по тому, что о "new-style class" я узнал только что из твоего сообщения, видимо, таки грабли те самые. Впрочем, это у меня не в первый раз.

Кстати, вот за что есть смысл упрекнуть питон, так это за очень быстрые изменения в стандарте языка. Конечно же, быстрая эволюция свидетельствует о хорошей адаптируемости. Но в питоне эти изменения происходят ну уж ОЧЕНЬ быстро. Причем, зачастую, с потерей обратной совместимости.

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

Я таки слегка таки напутал. Во-первых, "new-style class" я таки знаю, более того, других и не знаю, потому и не понял с первого раза. А во-вторых, естессно, я перекрывал методы __set__ и __get__. А вот боксирование свойств я и в самом деле не знал, так же, как в свое время не сразу понял, как делаются статические методы и методы класса.

За намек спасибо!

>>> chdir(lambda dir: echo("Processing %s" % dir))

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

> Соответственно сделать еще что-то ты уже не сможешь.

Включите воображение и получите "еще что-то":

def proc1(dir): print "Processing smth on the dir %s " % dir

def proc2(dir): print "Processing smth another on the dir %s" % dir

def proc_dir(dir): print "Processing the dir %s" % dir proc1(dir) porc2(dir) print "End processing %s" % dir

chdir(lambda dir: proc_dir(dir))

> Вот это и есть принципиальное ограничение.

Угу. А вынести блок в самостоятельную функцию со сколь угодно сложным императивом уже религия не позволяет?

Кстати, в Эйфеле был вопрос, почему не добавляют подпрограммs, как first-class objects. Ответ тоже был аналогичным: то, что ты пытаешься сделать с помощью блока, с высокой степенью вероятностью является методом некого класса, который можно вызывать в приложении к нему. В крайнем случае, можно воспользоваться синглетоном или утилитой. Как, например, это сделано для equality-тестеров в GOBO. В нашем же случае идеологически правильно завести для обработки соответствующий метод класса-каталога, и вызывать его, как параметр.

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

def proc1(dir):
   print "Processing smth on the dir %s " % dir

def proc2(dir):
   print "Processing smth another on the dir %s" % dir

def proc_dir(dir):
   print "Processing the dir %s" % dir
   proc1(dir)
   porc2(dir)
   print "End processing %s" % dir

chdir(lambda dir: proc_dir(dir))

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

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

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

Private и protected члены - это результат опыта очень многих программистов, занятых созданием сложных систем (private-члены неслучайно появились в Ada). Эта штука действительно работает. Никакая это не иллюзия.

>кончай пугать народ и сам вылазь из бомбоубежища- уже 2006 год, и никакой катастрофы не произошло- в GNU/Linux чудненько используются сотни Mb исходников, среди которых попадаются написанные не то что в 1998 году- но и лет на двадцать раньше

Это ты вылезай. Какую багу во фре нашли пару лет назад? ТАкую что exception брошеный в shared library не проходил type match в основном коде и не ловился catch. Это отличная иллюстрация того какое количество из этих сотен Mb действительно использует C++, а не C с классами.

>в то время как немаленькие проекты типа Mozilla или Apache собираются на различных платформах и различными компиляторами;

Смеялсо! Ты просто зайди и почитай кодинг гайдлайнс для мозиллы - и тебе все станет ясно.

http://www.mozilla.org/hacking/portable-cpp.html

Думаешь от хорошей жизни?

>Так вы пишите нормально.

А как нормально? Я вон привел пример нормально на примере мозилы - общий лозунг "if you want to write portable C++ just don't use C++".

>Никакая это не иллюзия. +1

> Вообще, если возникает желание использовать какой-то приватный член как открытый, то это обычно означает только одно - класс спроектирован с ошибкой.

Угу. Наличие рентгеновских аппаратов, ЯМР- и компьютерной томографии тоже свидетельствует, что человек спроектирован с ошибкой? ;-)

> Открытые методы должны гарантировать, что объект всегда будет переводиться из одного состояния в другое без побочных эффектов. Это и является главным "утверждением" по конктракту.

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

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

> Private и protected члены - это результат опыта очень многих программистов, занятых созданием сложных систем (private-члены неслучайно появились в Ada). Эта штука действительно работает. Никакая это не иллюзия.

Работают очень многие штуки. Например, при написании ядра linux совершенно не использовались защищенные члены. И эта штука тоже действительно работает ;-). В то же время, можно назвать библиотеки, где защищенная часть хорошо "изнасилована" в сторону открытия после проектирования. Ибо в самом начале разработки практически невозможно угадать, какая часть объекта понадобится при взаимодействии.

> Угу. А вынести блок в самостоятельную функцию со сколь угодно сложным императивом уже религия не позволяет?

Тут дело не в религии. А в удобности использовать. Смотри. Я уверен, что в Питоне нет (с коробки) процедуры для перехода в каталог, а потом возврата в него(наподобии того, что ты написал). Это нужно писать самому. Соответственно, такое решение не будет использоваться (даже в том виде, в каком ты его указал).

Аналогичная ситуация с коннектами к базе и операциями с файлами. В противовес этому, в Руби эти методы идут с коробки, тоесть Dir.chdir позволяет как просто перейти в каталог (если не задать блок кода), так и перейти в каталог и выйти из него (если задать блок кода).

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

> Кстати, в Эйфеле был вопрос, почему не добавляют подпрограммs, как first-class objects. Ответ тоже был аналогичным: то, что ты пытаешься сделать с помощью блока, с высокой степенью вероятностью является методом некого класса, который можно вызывать в приложении к нему.

Здесь я соглашусь. Анонимные функции могут стать причиной плохого дизайна, если их применять не к месту. Но для этого в языках вырабатывается best-practice.

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

> в то же время, готовы втыкать "наколеночные" решения в виде анонимных блоков

чтобы судить об этом, нужно обладать опытом. Ты пока что только рассказал, как ты где-то узнал, о том, что это плохо. Разберись, посмотри как это успешно используется в Ruby/Smalltalk/Lisp/Haskell/Schema, а потом делай свои суждения.

ЗЫ: статья Джоэля в тему: http://joelonsoftware.com/items/2006/08/01.html

>Кстати, все в том же Eiffel защита от "неконтролируемого изменения состояния" гарантируется встроенным синтаксическим механизмом запрета присваивания значений атрибутам объекта за пределами самого класса.

То есть эквивалент private аттрибута в Eiffel это кошерно, а в питоне некошерно?

> Угу. Наличие рентгеновских аппаратов, ЯМР- и компьютерной томографии тоже свидетельствует, что человек спроектирован с ошибкой? ;-)

Теперь добавим к этому списку и декомпиляторы тоже ;)

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

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

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

А чем это отличается от public-getter и protected-setter? То есть пример Eiffel как раз-таки показывает полезность закрытых членов.

Кстати, что касается "контрольных точек", то подобные механизмы есть во многих современных системах программирования. В том же .NET используются Debug.Assert() и Trace.Assert() (самое интересное, что в .NET можно создавать и свои собственные изощренные методы контроля через условную компиляцию и атрибуты). Поэтому здесь можно говорить о том, что использование private- и protected-членов необходимо, но это не является достаточным.

> Работают очень многие штуки. Например, при написании ядра linux совершенно не использовались защищенные члены. И эта штука тоже действительно работает ;-).

Давай говорить честно :) Ядро linux не является большим проектом. Безусловно, это очень важный проект, но есть проекты и поболее. Потом, вопрос скорее о том, _как_ создавать сложные проекты при минимальном риске? А написать можно все и на ассемблере, но толку-то?

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

Могу сказать только одно. Такая селяви :)

> Я уверен, что в Питоне нет (с коробки) процедуры для перехода в каталог, а потом возврата в него(наподобии того, что ты написал).

Мля, народ, ну шо за дурноватая манера узнавать что-то новое, демонстрируя свое невежество? Неужели так тяжело формулировать свои гипотезы в виде вопросов?

walk(path, visit, arg) Вызывает 'visit(arg, dirname, names)' для каждого каталога в дереве, начиная с path (включая каталог path). Аргумент dirname указывает имя каталога, для которого вызывается функция visit, а names является списком файлов и каталогов в каталоге dirname (os.listdir(dirname), то есть используется путь относительно каталога dirname). Функция visit может вносить изменения в names и, тем самым, оказывать влияние на то, какие каталоги будут посещаться далее по дереву, то есть чтобы избежать посещения каких-либо частей дерева каталогов.

Приведем простой пример:

import os, sys from stat import *

def visit(arg, dir, names): for name in names: fullname = os.path.join(dir, name) mode = os.stat(fullname)[ST_MODE] if S_ISDIR(mode): print 'Каталог', fullname elif S_ISREG(mode): print 'Обычный файл', fullname else: print 'Файл неизвестного типа', fullname if __name__ == '__main__': os.path.walk(sys.argv[1], visit, None)

> Очевидно, что такое решение снижает вероятность ошибки(не закрыть дескриптор файла, коннекшн к базе). Но так как в Питоне это не практикуется, оно и не будет применяться.

Телепат хренов. Ну откуда ты знаешь, что практикуется в питоне, если ты даже стандартные библиотеки ниасилил? А про "не закрыть чего-то там", так ведь автоматический вызов деструкторов, вроде бы, и в Ruby никто не отменял?

> Но для этого в языках вырабатывается best-practice.

Консенсус. Но тогда давай договоримся, что для защиты членов в питоне тоже достаточно обыкновенной best-practice. Консенсус?

> Кроме того, в Руби очень много методов используют блоки, как параметры. Вобщем, если бы ты глянул доку по использованию блоков в связке с yield полезность в данном случае станет для тебя очевидной.

Не, ну и эти люди будут рассказывать, как ковыряться в носу? Дорогой мой, "доку по использованию блоков" в Ruby я читал, причем, похоже, еще тогда, когда ты и слова такого не знал. И никто на твои драгоценные блоки не покушается. Ruby -- неплохой язык, особенно, как scientific toy. В последнее время, похоже, подтянулся и в практическом плане. Но на питон я слез только лишь потому, что в его библиотеках есть все, что нужно для нормальной работы. Возможно, что библиотеки Ruby за последнее время и подтянули, но мне как-то влом съезжать с того, что уже реально работает.

В общем, завязываем с меряньем пиписками и прочими религиозными войнами.

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

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

> Разберись, посмотри как это успешно используется в Ruby/Smalltalk/Lisp/Haskell/Schema, а потом делай свои суждения.

Спасибо за совет. Я лучше буду успешно использовать Python, а на досуге посмотрю MosML и F#.

> То есть эквивалент private аттрибута в Eiffel это кошерно, а в питоне некошерно?

Кошерно все, вопрос только в обстоятельствах. Давай определимся: мы "крутые перцы", которые презирают "ремни безопасности", или "молокососы", которому язык ни в коем случае не должен дать "прострелить себе ногу"?

Если первое, то посылаем нах статическую проверку типов, защиту членов и использование кодоблоков как first-class objects. В теле образуется необычайная гибкость, а любая задачка решается в две строки.

Если второе, то обкладываем каждый класс инвариантом, каждую подпрограмму -- пред- и постусловиями, а для каждого цикла выписываем вариант и инвариант. В этом случае, конечно, делаем защиту по полной, запрещаем работу с кодоблоками, как с объектами. Работает надежно, зато объем кода растет в геометрической прогрессии.

Но если пытаемся совместить первое со вторым, то получаем вялотекущую шизофрению. В этом смысле есть только три концептуально чистых языка -- Eiffel и SmallTalk. Все остальное -- вариации этих двух. При этом и Python и Ruby оказываются по одну сторону разделительной линии. И сравнивать их по этим критериям бессмысленно.

> Теперь добавим к этому списку и декомпиляторы тоже ;)

Use source, Luke!

> Кстати, что касается "контрольных точек", то подобные механизмы есть во многих современных системах программирования. В том же .NET используются Debug.Assert() и Trace.Assert()

В C++ это тоже есть, и я даже пытался это использовать. Не выходит. Попробуй реализовать следующий узор: в базовом (абстрактном) классе определяется абстрактный метод, на который накладываются предусловия на вход и постусловия на выход. После этого в классах-наследниках этот метод конкретизируется, но контроль пред- и постусловий должен быть проверен.

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

В Эйфеле все это "зашито" на уровне синтаксиса. Еще можно вспомнить о возвратной модели исключений, которая не позволяет подпрограмме завершиться успешно, не выполнив контракт. Но это уже уход в сторону...

> Могу сказать только одно. Такая селяви :)

В таком случае, смотреть на нее нужно без розовых очков.

> def visit(arg, dir, names): for name in names:

Звыняюсь, что форматування з'илы кляти пацюкы. Если кому интересно, могу опубликовать еще раз в формате. Боюсь, правда, что тут по большей части, писатели, а не читатели...

> ЗЫ: статья Джоэля в тему: http://joelonsoftware.com/items/2006/08/01.html

[QUOTE]
Cook( "lobster", 
      "water", 
      function(x) { alert("pot " + x); }  );

Cook( "chicken", 
      "coconut", 
      function(x) { alert("boom " + x); } );
[/QUOTE]

Ну дыкть, на Питоне это еще короче:

Cook("lobster", "water", lambda x: alert("pot " + x))
Cook("chicken", "coconut", lambda x: alert("boom " + x))

Если кто не понял намека, напоминаю старый афоризм: "Господи! Спасибо, что ты сделал все нужное простым, а все сложное -- ненужным" :-).

То есть, если кто еще не понял, функциональная парадигма требует рассматривать код, как function-call chains, что при правильном подходе позволяет записать весь анонимный блок, как единую цепочку вложенных вызовов. И в этом случае Ruby, Python и Lisp эквивалентны с точностью до синтаксиса.

А вот попытка смешивать императивный и функциональный стиль -- это mauve ton. И чтобы не поощрять его, в Python как раз и встроен дополнительный геморрой. Кстати, так же, как и в APL/J.

>Если первое, то посылаем нах статическую проверку типов, защиту членов и использование кодоблоков как first-class objects. В теле образуется необычайная гибкость, а любая задачка решается в две строки.

ыыы? Что-то я не понял как отсутсвие кодоблоков помогает образованию гибкости. Скорее их присутсвие помогает простреливать ногу, если сильно заноситься.

>Работает надежно, зато объем кода растет в геометрической прогрессии.

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

>В этом смысле есть только _три_ концептуально чистых языка -- Eiffel и SmallTalk

;))) О - настроение поднялось.

> В Эйфеле все это "зашито" на уровне синтаксиса. Еще можно вспомнить о возвратной модели исключений, которая не позволяет подпрограмме завершиться успешно, не выполнив контракт. Но это уже уход в сторону...

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

> А вот попытка смешивать императивный и функциональный стиль -- это mauve ton.

Между прочим, именно это и собираются сделать в одной из будущих версий .NET. Деталей уже не помню, но там можно будет создавать код, похожий на тот пример с повором Cook. Одна из мотиваций - чтобы можно было смешивать SQL-запросы с обычным C# кодом. Запросы к базе данных будут представлять собой те самые функциональные блоки.

>Запросы к базе данных будут представлять собой те самые функциональные блоки.

Угу. Вот из спеки:

where clause in a query expression:

from c in customers

where c.City == "London"

select c

translates to an invocation of a Where method with a synthesized lambda expression created by combining the iteration variable identifier and the expression of the where clause:

customers.Where(c => c.City == "London")

Ага. Оно самое. Выходит, что некоторые разработчики из фирмы Микрософт не разделяют взгляды нашего оппонента eugine_kosenko? :)

r так яро защищает продукты майкросфт, причём в разных темах, и скорсть печати супер - наверное неплохо оплачивается? Ленин кстати тоже - может одно лицо?

> Одна из мотиваций - чтобы можно было смешивать SQL-запросы с обычным C# кодом.

Офигеть! Лавры Clipper не дают покоя проектировщикам C#? ;)

> Ибо в самом начале разработки практически невозможно угадать, какая часть объекта понадобится при взаимодействии

не пиши программы больше, вообще никогда
займись чем-либо полезным

> займись чем-либо полезным

Уже :-). Руковожу программистами :-))).

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

Ошибся в синтаксисе. Надеюсь, повлияло только на ботов...

> ;))) О - настроение поднялось.

Я рад. Можете даже в цитатник занести. В оригинале был еще и Лисп, но он тоже был редуцирован. Эх, говорила мне мама, не используй числительных при классификации...

> Одна из мотиваций - чтобы можно было смешивать SQL-запросы с обычным C# кодом.

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

> Лавры Clipper не дают покоя проектировщикам C#? ;)

В PL/SQL это штатная фича. Судя по тому, что перед юконом сейчас ставится задача "догнать и перегнать" сами знаете кого, то это скорее попытка наделить новое поколение T-SQL аналогичными свойствами.

> Выходит, что некоторые разработчики из фирмы Микрософт не разделяют взгляды нашего оппонента eugine_kosenko?

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

> Думаю, что это уже крайность.

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