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

E>В Java бы ты комментировал метод test*. А в C++ закомментировал бы код внутри функции test*, а не весь test или ссылку на test. Получил бы то же самое, что и в Java. Здравый смысл еще никто не отменял.
Согласен, глупость сморозил.

E>И не нужно решать социальные проблемы техническими средствами.
А вот тут не соглашусь. Люди ленивы от природы и бороться с этим надо техническими средствами, и ни в коем случае не трогать лень. Она заставляет думать, вместо того, что бы пальцами кнопки давить

E>А как его протестировать, если все грабли выплывают под большой нагрузкой?

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

D>>-политика балансировки

E>Угу, автономно тестируемый load balancer. Который имитирует подключения к себе и прохождение трафика через себя.

D>>-сама задача

E>Сама задача -- это множество процессов. Которые должны работать именно вместе и так, как было задумано.

Для этой цели делают функциональные тесты, они гоняют всю систему (подсистему) целиком, тут можно и большую нагрузку устроить.

E>Я хочу сказать, что unit-тестинг -- это всего лишь один из инструментов, с довольно ограниченной сферой применения. И ни в коем случае не must have политика на все случаи жизни.

Не на все, конечно. Но область применимости удивительно широка.

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

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

E>>Но почему же лично я не считаю, что Java/C# совершили прорыв в смене сознания, как это сделал в свое время C++? Да потому, что C++ позволил массе реальных C-программистов применять ООП на практике. Java/C# не сделали этого, потому, что ООП уже не нужно было продвигать в массы. Все, что они сделали -- это создали новую, более эффективную (хотя это не бесспорно) технологию разработки ОО программ в духе C++. Но дальше они не пошли. Ведь что мы имеем в C++: статическая типизация; иерархия классов; объекты, которые не могут изменить свой тип (класс) в процессе жизни; передача сообщений между объектов в виде синхронного вызова методов. То же самое происходит в Java/C# с некоторыми изменениями/дополнениями (вложенные и анонимные классы в Java или делегаты в C#). Но здесь нет смены парадигмы. Понятно, что сменились некоторые приемы, где-то используется рефлекшен вместо шаблонов, где-то делегаты вместо указателей на методы. Но это не принципиально. Принципиальными изменениями, например, могли бы стать:
E>>- асинхронная доставка сообщений;

D>Тут есть большая проблема с возвращаемым значением. Но если ее решить (выбрать какое-нить решение), то такую фичу можно сделать на java (и, наверное на C#) уже существующими средствами. Тут нужено не изменения языка, а просто инструмент/библиотека.

Будьте проще. Здесь нужен паттерн проектирования FUTURE.
А из библиотек, специально реализующие асинхронные вызовы в Java есть: JAXM и J2EE/JavaMessage Service.

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

E>>>Принципиальными изменениями, например, могли бы стать:
E>>>- асинхронная доставка сообщений;

D>>Тут есть большая проблема с возвращаемым значением. Но если ее решить (выбрать какое-нить решение), то такую фичу можно сделать на java (и, наверное на C#) уже существующими средствами. Тут нужено не изменения языка, а просто инструмент/библиотека.

ZEN>Будьте проще. Здесь нужен паттерн проектирования FUTURE.
ZEN>А из библиотек, специально реализующие асинхронные вызовы в Java есть: JAXM и J2EE/JavaMessage Service.

Куда уж проще
В ООП объекты взаимодействуют между собой посредством отсылки сообщений. В языках C++/Java/C# эта отсылка реализована в виде синхронного вызова метода объекта. Под асинхронной отсылкой сообщений я имел в виду, что вызов метода у объекта-сервера (т.е. владельца метода) приводил к тому, чтобы сам метод отрабатывал где-то асинхронно.

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

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

E>>>>Принципиальными изменениями, например, могли бы стать:
E>>>>- асинхронная доставка сообщений;

D>>>Тут есть большая проблема с возвращаемым значением. Но если ее решить (выбрать какое-нить решение), то такую фичу можно сделать на java (и, наверное на C#) уже существующими средствами. Тут нужено не изменения языка, а просто инструмент/библиотека.

ZEN>>Будьте проще. Здесь нужен паттерн проектирования FUTURE.
ZEN>>А из библиотек, специально реализующие асинхронные вызовы в Java есть: JAXM и J2EE/JavaMessage Service.

E>Куда уж проще
E>В ООП объекты взаимодействуют между собой посредством отсылки сообщений. В языках C++/Java/C# эта отсылка реализована в виде синхронного вызова метода объекта. Под асинхронной отсылкой сообщений я имел в виду, что вызов метода у объекта-сервера (т.е. владельца метода) приводил к тому, чтобы сам метод отрабатывал где-то асинхронно.
Вот-вот, и я о том же.
Кслассическое определение "посылка сообщения объекту" как вызов его методов — это М-Е-Т-А-Ф-О-Р-А, о чём не приминут сказать Грэхем, Буч, Фаулер и другие заядлые ООП-ники в своих книжках.

Паттерн Future позволяет обойтись асинхронным вызовом любого метода любого объекта в ООП-языке без сторонних библиотек.

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

E>Куда уж проще
E>В ООП объекты взаимодействуют между собой посредством отсылки сообщений. В языках C++/Java/C# эта отсылка реализована в виде синхронного вызова метода объекта. Под асинхронной отсылкой сообщений я имел в виду, что вызов метода у объекта-сервера (т.е. владельца метода) приводил к тому, чтобы сам метод отрабатывал где-то асинхронно.
В с# есть делегаты как синхронные, так и асинхронные. Это уже свойство языка.

С уважением, Gleb.

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

ZEN>Паттерн Future позволяет обойтись асинхронным вызовом любого метода любого объекта в ООП-языке без сторонних библиотек.

Прошу прощения за невежество, но где про него можно прочитать? Желательно в электронном виде.

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

E>Здравствуйте, iZEN, Вы писали:
iZEN>>Паттерн Future позволяет обойтись асинхронным вызовом любого метода любого объекта в ООП-языке без сторонних библиотек.
E>Прошу прощения за невежество, но где про него можно прочитать? Желательно в электронном виде.
Книжка "Шаблоны проектирования в Java"
Автор: Марк Гранд
Издательство: Новое знание
Объём: 559 стр.
Год издания: 2004 г.
ISBN: 5-94735-047-5

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

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

ZEN>>Паттерн Future позволяет обойтись асинхронным вызовом любого метода любого объекта в ООП-языке без сторонних библиотек.

E>Прошу прощения за невежество, но где про него можно прочитать? Желательно в электронном виде.
Коротко, но полно

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

C>Слетит 56Мб кэша диска, в котором лежит много вкусных и полезных файлов.

С чего бы это? Памяти то 780!

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

D>Речь шла о возможности думать на языке программирования. Для того, что бы подумать на C/Java даже о простой задаче, приходится отвлекаться на массу лишних даталей.

И на Яве можно думать. Главное чтобы в коде каши не было.

D>Ну и какова применимость этого Sum?

Сумирование. Причем не нужно напрягаться и угадывать что же имел в ввиду программист под словом "inject".

D> А inject:into: можно например использовать для нахождения мин/макс элемента:
D>array inject: (array get: 0) into: [:min :element | element < min ifTrue:[element] ifFalse:[min]]

Как я уже заметил, "inject" явно туманный термин. Только зазубрив его смысл можно понять что творится. В приведенном же фрагменте к тому же еще много шума и в итоге прочеть такой код если он встретится внутри и без того не малого по объему кода будет не просто. Так что на любом языке будет более разумно определить функцию Sum. А уж ее реализация не так важна, так как ее ты смотреть скорее всего не будешь (ее смысл ведь и так очевиден). К тому же ее реализация на Яве не так уж плохо выглядит.

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

Да все можно. И что?

D>Разговор о естественных решениях, на C# — естественна итерация по коллекции, на ML — рекурсия. Важная в данном контексте разница в том, что на ML записывая рекурсию, пишется только то, что важно, а на C# тебе пришлось написать if — совершенно лишний в математическом определении рекурсивной функции.

Вообще-то я пытался пример на Яве дать. Ну, да не велика разница.
Что до if-а, то по мне без разницы видно его явно или его нужно угадать. Смысл то один и тот же. И вообще я о другом речь вел. Я говорил, о том что чтобы думать на языке нужно вводить абстракции и оперировать ими. Тогда и на С++ можно будет думать.

Ну, а что до МС, то попробуй написать код для массива и сравни его со списком. Потом сделаем вывод. Думаю, он будет таким "без связанных списков МЛ выглядит не очень крассиво".

D> А в естественно решении — итерации, приходиться думать где хранить промежуточный результат и помнить про индекс.

Где ты увидил в моем коде индекс? Что до промежуточного результата, то в рекурсивной функции его тоже нет. Так что не нужно придумывать. А вот то, что для большинства людей перебор естественее рекурсии и то что перебор лучше подходит для прохода по массивам — это факт который, как говорится, хрен оспоришь.

D> Т.е. засорять мысль о сложении всех элементов массива, второстепенными подробностями.

Еще раз. Вариат с перечислением читается довольно понятно. А будучи запакованным в функцию вообще отлично. А то что у МЛ синтаксис описания функции покороче не является огромным приемуществом. В итое в программе будет вызов Sum() и разницы не будет. Если же на МЛ-е ты влепишь тело функции, то сам сделашь код нечитаемым.

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

Согласен, но тут оно как... Если об эффективности вообще не думать, то она почему-то пропадает.

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

И? Чатается то твой любимый Смолток не очень то. Я же тебе привел код который можно написать без малейшего дополнительного телодивжения. Просто в библиотеки уже додумались вставить нужное расширение. Плюс к тому же нафига мне Смолток с непонятным синтаксисом, когда я могу расширять язык с более понятным и привычным?

Получается, что Шарп 3.0 умеет все то же что и Смолток, только делает это эффективнее и понятнее для тех кто, скажем так привык к Яве или С++.

VD>>Ну, и самое простое... C# 1.0:
VD>>

VD>>int sum = 0;

VD>>foreach (int elem in array)
VD>>    sum += elem;
VD>>

D>Опять же разница в том, что foreach — языковая конструкция, ее нельзя выразить на самом C#. Как, например, собрать строку из елементов, разделенную запятимы?
D>Smalltalk:
D>array do: [:element | добавляем] separatedBy: [разделяем]

Гы. То есть мы признаем приемуществом языка наличие в его составе функции решающей частную задачу? Ну, тогда твой Смолток отдыхает по пролной, так как у Шарпа охриненных размеров библиотека.

D>А на С#?

Я хреново понимаю смысл данной конструкции. Если речь идет о том, что в некотором массиве содержатся строки которые нужно превратить в единую строку где элементы массива будут разделены запятыми, то это бдет выглядить так:

string result = string.Join(", ", array);

D> Опять итерация и проверяем надо ли ставить разделитель?

Не угадал.

D>Разница в том что do:separatedBy: — метод, если его нет то его можно добавить. А вот foreach separatedBy ты ни в C# ни в java не вставишь...

А что в C# и java добавлять методы уже является дурным вкусом?
В общем, не нужно агитации за советскую власть. Если у Явы действительно наблюдается некая отсталость, то уже Шарп точно ничем не уступает Смолтоку. Если конечно не считать приемуществом динамическую типизацию. А методы пишутся на любых языках. Тот же string.Join() — это всего лишь метод написанных на том же C#. Кстати, в Яве он тоже есть.

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

D>Это уже лучше, с последними веяниями C# не знаком Мусора конечно еще много, но новшество мне нравится.

Мусор и маразм как раз в Смолтоке. Одно назваине метода "inject" чего стоит? Ведь вообще не отражает смысла операции.

А зачем Dyoma налепил таких сложностей я лично незнаю. Join и так сработает. Если нужно пребразовать произвольный массив в массив строк, то для этого достаточно написать так:

string[] strs = Array.ConvertAll(array, obj => obj.ToString());

После чего работает банальный строковый джонин:

string result = string.Join(", ", strs);

Или в одну строку:

var result = string.Join(", ", Array.ConvertAll(array, obj => obj.ToString()));

Или учитывая возможность создания методов расширения:

var result = string.Join(", ", array.ConvertAll(obj => obj.ToString()));

И в итое вообще:

var result = array.Join(", ", obj => obj.ToString()));

Метод расшерения для последнего вариата:

public static class ArrayExt
{
    public static string Join<T>(this T[] array, string separator)
    {
        return string.Join(", ", Array.ConvertAll(array, str => str.ToString()));
    }
}

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

ЗХ>>Но массовый-то софт с компиляцией в байт-код начали писать именно на Java и C#.

VD>Скорее на VB, а то и на Клипере, Кларионе и т.п.

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

Я это и имел в виду. Пардон, неграмотно выразился.

VladD2 wrote:

> C>Слетит 56Мб кэша диска, в котором лежит много вкусных и полезных файлов.
> С чего бы это? Памяти то 780!

У меня сейчас в кэше лежит 750Мб файлов (всего 1Гб памяти), поэтому у
меня очень быстро работает компиляция и отладка.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

VD>Как я уже заметил, "inject" явно туманный термин. Только зазубрив его смысл можно понять что творится. В приведенном же фрагменте к тому же еще много шума и в итоге прочеть такой код если он встретится внутри и без того не малого по объему кода будет не просто. Так что на любом языке будет более разумно определить функцию Sum. А уж ее реализация не так важна, так как ее ты смотреть скорее всего не будешь (ее смысл ведь и так очевиден). К тому же ее реализация на Яве не так уж плохо выглядит.

Зря ты обозвал inject туманным термином Да действительно смысл этого способа итерироваться нескольно не стандартен, я и сам в свое время долго въезжал, что он делает. Но на практике оказывается очень полезная штука. Очень часто надо пройтись по коллекции, вычисляя значение, которое завит от предыдущего результата и текущего элемента. Вот для таких случаев есть в стандартной библиотеке метод inject:<начальное значение> into:<что собственно делаем> (по сишному injectInto(<начальное значение>, <что собственно делаем>). Как его назвать более очевидным образом но вещь мега полезная.

VD>Я говорил, о том что чтобы думать на языке нужно вводить абстракции и оперировать ими. Тогда и на С++ можно будет думать.

Разница между Smalltalk и C++ в том что if, for, while и т.д. в C++ конструкции языка, а в Smalltalk методы объектов и если разработчики языка, не сделали полезный, например, цикл — ничего страшного его дописать можно. Это дает дополнительную свободу в том какие именно абстракции можно вводить.

VD>Ну, а что до МС, то попробуй написать код для массива и сравни его со списком. Потом сделаем вывод. Думаю, он будет таким "без связанных списков МЛ выглядит не очень крассиво".

Не совсем, массивы в ML — не естественное решение

VD>Получается, что Шарп 3.0 умеет все то же что и Смолток, только делает это эффективнее и понятнее для тех кто, скажем так привык к Яве или С++.

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

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

D>Зря ты обозвал inject туманным термином Да действительно смысл этого способа итерироваться нескольно не стандартен, я и сам в свое время долго въезжал, что он делает. Но на практике оказывается очень полезная штука. Очень часто надо пройтись по коллекции, вычисляя значение, которое завит от предыдущего результата и текущего элемента.

По-моему, это называется ACCUMULATE.

Что-то вроде функции accumulate(list, start, func) -> S, где collection — последовательность элементов типа E, start — значение типа S, func — функция func(elem, sum) -> S от аргументов elem типа E и уже накопленной "суммы" sum типа S. Обычно S = E

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

Если надо перебирать последовательность не всю, или в обратном порядке, или ещё как, то на последовательность сначала применяется функция-фильтр, которая возвращает новую последовательность (или псевдо-последовательность), содержащую элементы в новом порядке. Кстати, а можно ли это сделать легко в Smalltalk? Т.е. вместо `array inject` сделать `array <filter>` inject, не заю как там должно быть в его синтаксисе. На C-like это array.filter(criteria).inject(...) вместо array.inject(...).

Здравствуйте, Кодёнок, Вы писали:

D>>Зря ты обозвал inject туманным термином Да действительно смысл этого способа итерироваться нескольно не стандартен, я и сам в свое время долго въезжал, что он делает. Но на практике оказывается очень полезная штука. Очень часто надо пройтись по коллекции, вычисляя значение, которое завит от предыдущего результата и текущего элемента.

Кё>По-моему, это называется ACCUMULATE.

В Smalltalk это надо назвать в два слова, одно означает смысл начального значения, второе — лямбду. Синтаксис такой, аргументы вставляются внутрь имени. Обычно очень удобно когда несколько параметров их смысл виден в месте вызова.

Кё>Если надо перебирать последовательность не всю, или в обратном порядке, или ещё как, то на последовательность сначала применяется функция-фильтр, которая возвращает новую последовательность (или псевдо-последовательность), содержащую элементы в новом порядке. Кстати, а можно ли это сделать легко в Smalltalk? Т.е. вместо `array inject` сделать `array <filter>` inject, не заю как там должно быть в его синтаксисе. На C-like это array.filter(criteria).inject(...) вместо array.inject(...).

Есть несколько вариантов:
1. Простой. Если надо в обратном порядке и/или не все, но в прямом или обратном порядке то
(array select: [:e | <условие>]) reversed inject: x into: [...]
2. Если операция популярная — добавить в класс Collection метод(ы) с доп. аргументом(ами)
3. Если надо отсортировать то
(array asSortedCollection: [:a :b | <a сравнить с b>]) inject...
4. Если надо перемешивать то может получиться с дополнительным ACCUMULATE
(array inject: OrderedCollection new into: [:reordered :e | <перемешиваем в reordered>]) inject: x into: [...]
Но это уже пахнет нездоровым извращением

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

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

Как это не странно, но метод называется min:

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

D>Зря ты обозвал inject туманным термином

Не совсем зря. В c.l.s до сих пор(!) спорят о том, как можно было бы правильно его назвать. Но 30 летнею историю не перепишеш.
Но если так хочется понятности, то можно использовать fold:.

D>Да действительно смысл этого способа итерироваться нескольно не стандартен, я и сам в свое время долго въезжал, что он делает. Но на практике оказывается очень полезная штука. Очень часто надо пройтись по коллекции, вычисляя значение, которое завит от предыдущего результата и текущего элемента. Вот для таких случаев есть в стандартной библиотеке метод inject:<начальное значение> into:<что собственно делаем> (по сишному injectInto(<начальное значение>, <что собственно делаем>). Как его назвать более очевидным образом но вещь мега полезная.

Это да.

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

C>У меня сейчас в кэше лежит 750Мб файлов (всего 1Гб памяти), поэтому у
C>меня очень быстро работает компиляция и отладка.

А "очень быстро" — это сколько? А то у меня столько не лежит (вообще 450 метров свободных), а компиляция проходит в течении десятых долей секунд, ну, при перекомпиляции более-менее большого проекта 2-3 секунды.

C>Если я запущу какую-нибудь программу, даже на небольшое время сжирающую
C>56Мб, то у меня эти самые 56Мб дискового кэша будут очищены. Значит при
C>следующей компиляции эти файлы снова будут читаться с диска. А я
C>предпочитаю, чтобы у меня все летало.

Может лучше сменить компилятор? Что уж там по 10 мег выигрывать, когда можно 780 освободить?

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


D>Зря ты обозвал inject туманным термином Да действительно смысл этого способа итерироваться нескольно не стандартен, я и сам в свое время долго въезжал, что он делает. Но на практике оказывается очень полезная штука. Очень часто надо пройтись по коллекции, вычисляя значение, которое завит от предыдущего результата и текущего элемента.

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

Например, аналогичный метод в дотнете назвали "Fold", то есть "свертывать". "inject" же — это "вводить", "вприскивать", "вставлять" наконец. Как это название ассоциируется с поведением.

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

D>Вот для таких случаев есть в стандартной библиотеке метод inject:<начальное значение> into:<что собственно делаем> (по сишному injectInto(<начальное значение>, <что собственно делаем>). Как его назвать более очевидным образом но вещь мега полезная.

Думаю, никто не будет спорить, что подобный метод можно реализовать почти на любом языке? Здорово, что он есть штатно. Не здорово, что так назван.

D>Разница между Smalltalk и C++ в том что if, for, while и т.д. в C++ конструкции языка, а в Smalltalk методы объектов и если разработчики языка, не сделали полезный, например, цикл — ничего страшного его дописать можно. Это дает дополнительную свободу в том какие именно абстракции можно вводить.

А как же дописать, то если ни if, ни циклов?

D>Не совсем, массивы в ML — не естественное решение

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

Нехочу ввзяываться в очередной спор "ФЯ вс. все остальное", но все же, думаю, что если бы для МЛ и массив был бы естестеннен, то и МЛ был бы более естественне, и что самое важно, более используем.

VD>>Получается, что Шарп 3.0 умеет все то же что и Смолток, только делает это эффективнее и понятнее для тех кто, скажем так привык к Яве или С++.

D>Убедил, я от шарпа далек и чего в 3.0 напридумывали узнаю последним. Действительно наконец сделали возможность передать маленький кусок кода без синтаксических извращений. Что, как я думаю, есть клево.

Вот и я о том же. Думается, что если бы его создатели добавили бы еще пару возможностей из ФЯ, и еще нечто вроде миксинов/трэтсов, чтобы заменить множественное наследование, то через некоторое время про ФЯ и С++ можно было бы спокойно забыть. Но до этого явно пока долеко .