Здравствуйте, Turtle.BAZON.Group, Вы писали:

E>>Так гребут, что вынуждены делать бесплатную версию своей EiffelStudio чтобы привлечь новых разработчиков.
E>>Лет десять назад у них, вероятно, особых проблем-то и не было. А сейчас, на фоне распространенности Java (которая бесплатно есть на большем количестве платформ, чем Eiffel), агрессивного маркетинга C#, количества библиотек и фреймворков для Java и C#, количества IDE для Java/C#, количества документации/книг/учебных курсов, количества разработчиков, имеющих опыт разработки на Java/C#, перспективы у Eiffel-я, имхо, очень не важные.
TBG>Сам язык от этого не страдает. Страдает его популярность, ну и nil с ним.

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

А причина в том, что сейчас не время закрытых и платных универсальных языков. И Eiffel-евцы, похоже, поняли это слишком поздно.

E>>Не зря же Мейер сейчас статейки пишет, что мол дешевые индусы и воссточные славяне оставят без работы дорогих американских разработчиков. Если только последние не возьмутся за ум и не начнут использовать "правильные" инструменты, резко повышающие их (разработчиков то есть)
TBG>А индусы вообще всех порвут своей дешевизной. Что хотят, то и творят. Язык тут не при чем.

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

E>> производительность, то хана им. А правильным инструментом, естественно, является Eiffel Methodology + Eiffel Studio. Хотя чем Eiffel сейчас может конкурировать, например, с Java 5 + IDEA (Eclipse) лично я, например, не понимаю.
TBG>Навороченность IDE может говорить о негибкости языка. Если они появились — значит, была потребность. Где их нет, то нет и соответствующей потребности.

Так в том то и фокус, что EiffelStudio как раз претендует на звание продвинутой IDE. Но для Eiffel-я она одна такая (хотя может быть в VisualEiffel есть еще что-нибудь, но она только Windows-ная). А для той же Java подобных IDE (если не круче) гораздо больше. И дешевле.

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

Д>бессмысленно сравнивать сферу производства и сферу развлечений.

Не менее бессмысленно переносить критерии успеха из сферы развлечений на сферу производства..

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

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

а кто это делал?

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

Д>Здравствуйте, Трурль, Вы писали:

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

Д>а кто это делал?

"Тот, кто первым крикнул из ветвей — мейнстрим большой, ему видней".

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

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

Д>>а кто это делал?

EB>"Тот, кто первым крикнул из ветвей — мейнстрим большой, ему видней".

а при чем здесь сфера развлечений?

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

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

ANS>>Потребует 1-го (одного) виртуального метода под названием prettyPrint принимающего 1 (один) параметр — поток вывода и классы в количестве соответсвующем количеству матчей. Или тебя пугает необходимость создавать классы в ОО программе?
WH>А можно чуток псевдокода, а то както все очень расплывчато.

class UnaryOperator
    prettyPrint(outputStream) {
        outputStream
            .append(name)
            .append('(')
            .append(parm)
            .append(')')
    }

Ы?

WH>а использование будет както так
А можно на словах описать, а то как то малопонятно?

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

FDS> их стоит описывать и показать, что я неправ.

Всё уже сказано

Автор: Sinclair
Дата: 12.09.06

.
Но могу пояснить и я. Что касается ошибки кодирования, то твой код не безопасен по отношению к исключениям. Значит, если при вызове action (содержимым которого ты не управляеш!) вылетит исключение, то ты получиш что угодно. Начиная с утечек ресурсов, заканчивая дедлоками в самые разные моменты, например только под большой нагрузкой.

То есть переделываем:

    try {
        foreach(T Child in root) {
            ForEach(Child, action);
        }
    }
    finally {
        rootChild.Unlock();
    }

И теперь фразу "и уже ошибка" можно вычеркнуть.
Что касается ошибки проектирования, то этот код — явный кандидат на using и IDisposable.
Что касается моей фразы о двух ошибках, то мне показалось, из-за использования имени Child в наружном контексте и при итерации, что ты вызываеш Unlock в цикле. Про одно имя даже не пойму, если это просто небрежность, то это одно, но если стиль...

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

ANS>

ANS>class UnaryOperator
ANS>    prettyPrint(outputStream) {
ANS>        outputStream
ANS>            .append(name)
ANS>            .append('(')
ANS>            .append(parm)
ANS>            .append(')')
ANS>    }
ANS>

ANS>Ы?
Что Ы? А работать это как будет? Как оно поймет что это

TT.TExpr.Call (TT.TExpr.OpCode (name), [parm], _) =>

Нужно скормить этому классу?
Только не говори что нужно править AST. Это не приемлемо ибо получится редкостный бардак.
Главная прелесть match'а в том что он внешний по отношению к AST.

WH>>а использование будет както так
ANS> А можно на словах описать, а то как то малопонятно?
А что тут может быть не понятно? SprintTyExpr получает еще и замыкание в которое скармливают очередное выражение. Если замыкание его обработало то ничего не происходит, а если нет то начинается обработка при помощи того match что в SprintTyExpr.
Внутри замыкания находится такойже match только с пользовательскими вариантами. Есдинственное отличие в том что match в замыкании возвращает true если отработал и false если нет.

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

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

B>В этом случае будет брошено исключение
B>

B>blockWithReturn := [^28].
B>process := [:blockToRun | blockToRun value] newProcessWithArguments: (Array with: blockWithReturn).
B>process resume.
B>

B>В этом примере создается новый процесс и в него передается параметр — блок, который надо выполнить. Мы передаем блок с возвратом (blockWithReturn), запускаем процесс и ... никаких забавных глюков не происходит, а появлется исключение CannotReturnError (Context cannot return).
А ты уверен что создающий процесс не успел завершится? Поставь там бесконечный цикл.

Здравствуйте, WolfHound, Вы писали:
WH>Что Ы? А работать это как будет? Как оно поймет что это
WH>

WH>TT.TExpr.Call (TT.TExpr.OpCode (name), [parm], _) =>
WH>

WH>Нужно скормить этому классу?
WH>Только не говори что нужно править AST.

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

WH>А что тут может быть не понятно? SprintTyExpr получает еще и замыкание в которое скармливают очередное выражение. Если замыкание его обработало то ничего не происходит, а если нет то начинается обработка при помощи того match что в SprintTyExpr.

Это не расширение, а кривой костыль.

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

E>Это нужно Мейеру рассказать, а то он пребывает в уверенности, что если дать дорогим разработчикам дорогой инструмент, то они будут рвать дешовую рабочую силу как промакашку.

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

Здравствуйте, Turtle.BAZON.Group, Вы писали:

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

Вот интересно. Пусть дорогой разработчик на Java в Москве получает $3K в месяц. И требуется ему писать софт, который работает под Windows, Linux, Solaris и MacOS. Затраты на него будут составлять $3K в месяц + $500 на приобретение IDEA. JDK для всех этих платформ бесплатен.

Теперь пусть у нас есть такой же дорогой разработчик на Eiffel. Мы будем платить ему теже $3K в месяц. + $4799 (EiffelStudio for Windows) + $4799 (Linux) + $7999 (Solaris) + $4799 (MacOS). И того накладные расходы на одного Eiffel разработчика будут составлять $22396. Т.е. это зарплата нашего разработчика за $7.5 месяцев. Не проще ли на это время нанять еще одного дорогого Java разработчика?

А если мы нанимаем разработчиков не в Москве, а в провинции или, к примеру, на Украине или в Белоруссии? В каком-нибудь Белорусском областном центре вы можете купить за $1500 классного специалиста с потрохами (и учитывая разницу в стоимости жизни в Белоруссии и в Москве, $1.5K будет сравнима с $3K в Москве). При таких раскладах стоимость только средств разработки для Eiffel-я будет составлять больше годовой зарплаты одного хорошего специалиста.

А теперь вопрос: можете ли вы перечислить преимущества, которые Eiffel может дать разработчикам (не важно дешевым или дорогим) по сравнению с C# или Java? Настолько важные преимущества, которые окупили бы стоимость Eiffel-евских средств разработки?

И еще один вопрос в догонку: что же делать компании, которая вложила такие деньги в средства разработки и обучение специалистов, выпустила кроссплатформенный продукт на Eiffel (под Windows, Linux, Solaris, MacOS). А затем бах -- нужно его портировать под UP-UX и AIX.

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

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

Я говорил про макросы, а не про замыкания.

B>>В этом примере создается новый процесс и в него передается параметр — блок, который надо выполнить. Мы передаем блок с возвратом (blockWithReturn), запускаем процесс и ... никаких забавных глюков не происходит, а появлется исключение CannotReturnError (Context cannot return).
WH>А ты уверен что создающий процесс не успел завершится?

Уверен.

WH>Поставь там бесконечный цикл.

Происходит то же самое.

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

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

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


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

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

ANS>Не нужно ничего править, потому что дерево из узлов с такими классами должно быть сформировано парсером. Например, объект класса UnaryOperator это узел у которого есть поле "имя" и ссылка на очередной узел.
Те парсер должен сформировать дерево которое удобно печатать? А ты в курсе что этот код находится в разделе misc те этого кода может и не быть и все будет работать?
Но прикол в том что у нас еще есть генератор кода которому начхать на то что к нему пришло унарный оператор или функция с одним параметром. Ты можешь возразить что у нас есть встроеные типы и их нужно по особенному обрабатывать в MSIL'е но на это есть убойный аргумент: А зачем о встроеных типах знать парсеру, типизатру, макросам...? Не забываем про пользовательские операторы... Зачем на этих очень не простых стадиях лишнии детали?

И все это нужно засунуть в АСТ? И кстати в какое АСТ? их там несколько...

Короче чистый ОО тут ни разу не рулит.

ANS>Это не расширение, а кривой костыль.
Отрицание... любимый прием пуристов... Великий магистр оберона темже самым занимается.
Аргументы будут?

Здравствуйте, Turtle.BAZON.Group, Вы писали:

TBG>А дорогим разработчикам дай любой инструмент — и онои будут рвать девевую рабочую силу. И вообще, дорогие разработчики могут позволить себе выбирать тот инструмент, который необходим для решения той или иной задачи.
Это зависит от задачи.
Есть задачи на хоторых просто не рентабельно использовать дорогих разработчиков.

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

V>В неадекватном восприятии тобой окружающей действительности, ИМХО. Считай, что тебе просто везло, ибо "быкующие" при случае отхватывают гораздо круче "обычных", и лечатся потом дольше. Такой закон жизни, фиг его знает, с чем это связано.

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

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

VD>Синклер, уточни, плиз, с чем ты не согласен? Тебе нравится идея организации логики на исключениях?
Я не согласен ровно с тем абзацем, который ты написал. "Неверная передача управления" приведет к вылету исключения, поэтому пассаж про ее отличие от исключений — неверен. Вот и все.
А все остальные передачи управления — верные, и ничуть не хуже вот такого кода

bool SearchForItem(IEnumerable<MyClass> items)
{
    foreach(MyClass item in items)
    {
        if (item.A = 5)
            return true; // нашли! нелокальный возврат.
    }
    return false;
}

Что, этот код чреват проблемой? Плохо читается? А ведь мы блин передали управление поперек скобочек!
Вот "кошерный" вариант:

bool SearchForItem(IEnumerable<MyClass> items)
{
  bool result = false;
    foreach(MyClass item in items)
    {
        if (item.A = 5)
        {
            result = true; // нашли! 
            break; // локальный возврат
        }
    }
    return result;
}

Что, лишние две строчки сильно улучшили читаемость? Нет? Просто в ST авторы решили, что метод ForEach ничуть не хуже встроенного оператора foreach. И в нем тоже полезно иметь возможность сделать return. Да, потенциально это ведет к некоторым проблемам. Но, во-первых, злоупотребить можно и оператором +, а во-вторых, все же меры по борьбе приняты — как минимум попытка вернуть управление в разрушенный контекст ведет к defined behavior, который вполне согласуется со здравым смыслом.

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

Д>это я к тому, что хорошего бизнесмена (менеджера) найти еще посложнее, чем хорошего программиста. Поэтому странновато называть хорошего бизнесмена плохим программистом
Вообще, чтобы продукт стал успешным, необходим правильный баланс между желанием пользователей и возможностями технологии.
Одно без другого не существует. Невозможно разрабатывать продукты, не представляя себе потребностей рынка — а понимание потребностей рынка (причем не тех, что были 5 лет назад, и даже не тех, которые есть сейчас, а тех, которые возникнут на момент окончания разработки) — это и есть основной талант бизнесмена. Конечно, еще полезно уметь управлять ресурсами, но это в целом более-менее хорошо изученная область, которая поддается не талантам, а банальному изучению. Огромное количество MBA, ежегодно выпускающихся из разнообразных бизнес-школ, тому подтверждение.

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

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


V>>А в Немерле 80% кода будет оптическим обманом, типа как в современной С++ программе.

IT>Откуда такая уверенность? Опять макросы? Зря переживаешь. Я вот за месяц интенсивной и плодотворной работы с N не написал ещё ни одного. Но зато вижу, что те задачи которые я решаю на C# решались бы на порядок сложнее и соответственно привели бы к более сложному, непонятному и запутанному коду.

Я лично ничуть про макросы не переживаю. Сам на С++ использую на всю катушку, невзирая на всякие "рекомендации", ибо если есть удобный инструмент — почему бы не воспользоваться? Макросы добавляют в код элементы управляемости и настраиваемости, макросы позволяют порождать из одного и того же исходника семантические разные программы. Сотни раз слышал и тут в т.ч. что эта фича опасна, но для меня она чертовски удобна. Как говорят врачи — всё можно, если осторожно.

Не сомневаюсь, что для тебя Nemerle удобен. Но вот у меня тут скоро встанет вопрос, какую технологию избрать для следующего проекта. Как ты думаешь, я рискну применить его в своей команде? Тут народ еще даже анонимные делегаты из C#2.0 боится юзать и спотыкается на иерархии ограничений генериков... А ты говоришь — Немерле