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

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

E>>>Вай, вай! А где в Янусе нужна высокая скорость работы?
S>>В первую очередь при поиске сообщениёй в Базе, когда её размер превыщает 1 Гигабайт.

E>А развернуть свою мысль можешь?
E>Разве в Янусе поиском не Jet занимается?

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

Если я не ошибаюсь то на этом форуме Павел Дворкин в топике по эффективности уже грил, о том, что поиск Через FireFox[NNTP](могу и ошибиться) работает гараздо быстрей чем в Янусе.

Вот именно об этом я говорю, что ещё можно разворачивать ?

Но это как бы моя позиция как обычного пользователя.
А как продвинутый пользователь, и разработчик, я забиваю на это неудобство ИБО Янус шаровый, и более удобный.

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

S>из здесь

Автор: eao197
Дата: 14.03.06

S>

S>Языки путь идут. Их каждый год порядка 200 рождается и столько же умирает.
S>Главное, чтобы интересная и устраивающая меня работа мимо меня не проходила. А, как показывает мой опыт, язык программирования здесь вовсе не определяющую роль играет.

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

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

E>>Разве в Янусе поиском не Jet занимается?

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

Собственно мой вопрос к VladD2 основывался на том, что в разных баталиях по поводу производительности Януса вообще и поиска в нем в частности, разработчики Януса говорили, что тормоза Януса лежат в Jet (т.е. на уровне работы с БД). А поиска быстрого нет потому, что нет индексатора и поиск ведется чуть ли не SQL-ный LIKE. Отсюда и тормоза и малая релевантность результатов поиска.

Так вот, если в Янусе на C# сделан только GUI и работа с БД (через Jet), отображением (через IE-компонент) и работа с сетью (синхронизация), то где здесь требуется высокая производительность? Такая, которую не смог бы обеспечить Ruby в подобных условиях.

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

E>то где здесь требуется высокая производительность?

Например для отрисовки грида.

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

E>>то где здесь требуется высокая производительность?

AVK>Например для отрисовки грида.

Учитывая, что Ruby не сам отрисовывает такие вещи, а через C++ные библиотеки (FOX или Qt), то не думаю, что здесь будет серьезная разница в производительности.

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

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

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

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

Например, когда я искал для своей задачи скриптовый язык, я имел очень отдаленное представление о том, что такое Ruby. Тем не менее, Ruby оказался победителем по целому ряду факторов. Но в тройку финалистов (вместе с Perl и Python) он попал тогда, когда я его вообще не знал. Более важно на тот момент было то, что Ruby был на большом количестве платформ, для него было достаточно документации, у него был небольшой объем исходников (на С) и пр. А первоначально я перебрал штук двадцать языков (помню, что мне понравились еще Ici-4, Lua, c-smile и Groovy).

И подобная ситуация не только с языками, но даже с библиотками и фреймворками для конкретного языка. Например, мне приходилось выбирать такие вещи, как библиотека для поддержки криптографии (Crypto++, но сейчас бы выбрал Botan), для работы с SSL (OpenSSL, хотя тогда еще GnuTLS была в бетах, да и C++ная CryptLib так же очень достойно выглядела), для GUI (Qt с серьезным отрывом, хотя есть и весьма достойные конкуренты в лице FOX, wxWidgets, FLTK, Ultima++), общесистемная кроссплатформенная библиотека (ACE, хотя и здесь есть куча альтернатив). Во всех случаях в процессе выбора я узнал о таком количестве альтернатив (причем весьма серьезных), про которое даже не подозревал. И только в случае с OpenSSL и Qt выбор был сделан в пользу инструмента, о котором я знал заранее. А вот про Crypto++ и ACE я узнал уже в процессе поисков.

Так что я придерживаюсь мнения, что абстрактные, не примененные знания -- это мусор, от которого мой мозг очень быстро избавляется. Есть такая особенность -- все, что не нужно в течении нескольких недель (а то и дней) выветривается абсолютно. Гораздо важнее суметь получить и обработать новые знания из окружающего мира именно тогда, когда они потребуются. Но это my way, не могу его никому рекомендовать.

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

ПК>Не получится: там для этого язык менять придется, т.к. t[0] будет возвращать какой-нибудь Object и т.п.

А чем это отличается от t.Val1?

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

VD>>Явная типизация в большинстве случаев только ухудшает читабельность.

ПК>-1

Речь идет о тех случаях когда тип однозначно выводится из контекста конечно.

ПК>Функциональные, через рекурсию.

В C# их нет. В Nemerle я все что нужно переберу штатными средствами. Так что нет нужны в переборе значений кортэша через индекс. А С++ с его тараканами мня не интересует.

VD>>А извращения могут быть любыми. Уж извини, но С++ с Нэемерлом в компайлтайме не тягаться.

ПК>Это я в данной теме не обсуждаю. Я только высказался относительно двух разных форм записи: (i, _) = t vs. i = get<0>(t).

Дык ты говоришь, что get<0>() нужен именно для перебора в компайлтайме. Я же тебе отвечаю, что в Нэмерле есть специальные средтства. Так что по жизни при использовании кортэжей в Немерле обращаться к синтаксису x[y] не требуется.

ПК>Именно из-за разных типов я и сказал о compile-time циклах. Это вполне осмысленно для любых утилит обобщенной обработки tuples.

См. выше.

ПК>Кстати, какого типа выражение t[0] в Nemerle?

Того же что и элемент кортэжа. Физически кортэж выраждается в дженерик-класс, если конечно компилятор его полностью не устраняет.

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

WH>Что? tie? Да для всех...
WH>

WH>// Tie function templates -------------------------------------------------
WH>template<class T1, class T2, class T3>
WH>inline tuple<T1&, T2&, T3&> tie(T1& t1, T2& t2, T3& t3) {
WH>  return tuple<T1&, T2&, T3&> (t1, t2, t3);
WH>}
WH>...
WH>

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

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

E>Вай, вай! А где в Янусе нужна высокая скорость работы?

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

К тому же кроме януса есть еще много чего. Прикинь как убдет тормозить парсер на Руби? А во что выльется текстовый редактор?

E>В Web-приложениях, например, Ruby спокойно конкурирует с Java.

Да не очень то. Порталы с большой загрузкой делают на Яве, а не на Руби.

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

S>>В первую очередь при поиске сообщениёй в Базе, когда её размер превыщает 1 Гигабайт.

ANS>?!! То есть тормозит таки C#?

2 тебе по логике.
Тормозит С++.

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

E>Про проблемы в дизайне Ruby можно подробнее?

Легко. Главная — это слабый контроль эээ... мм... компилятора то вообще нет. Так что даже не знаю чего. Ну, скажем так парсера.

Переменные не типизированные и не объявляемые. А это глюки и жизнь на тестах.

Далее динамическое изменение. А это неизвеность при загрзуке любого модуля.
Текстуальные макросы. В общем, весь бугет в одном флагне. Ну, разве что еще доступа по неверным адресам нехватает и грязи в непроинициализированных переменных.

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

E>А вот теперь посмотри: год назад, ты уверял меня, что C# -- это круто, что нужно бросать C++ и писать на C#.

А я и сейчас это утверждаю. Проблемы плюсов резко преревешивают их достоинства.

E> Послушал бы я тебя тогда, к сегодняшнему моменту чего-нибудь успел бы сделать на C#.

Дык, заметь. Все смог бы использовать из Нэмерла. А так мучашся с плюами и Руби.



E> Но чу! C# то не так крут, есть и круче. Значит, нужно бросать C# и писать на Nemerle. С такими же перспективами через 1.5 года перебраться под OCaml/NET (к примеру).

OCaml не имеет ничего, что могло бы дать ему серьезные конкурентные приемущества в данном плане.

E>Так что получается, что на массированную рекламу лучше не поддаваться, никуда не перепрыгивать. Время покажет, на какую платформу имеет смысл переходить. Может и правда это будет Nemerle. Если так, то я ничуть не огорчусь, что C# прошел мимо меня.

Правильно. И зря ты С++ и Руби мучашь. Пиши на С и тогда проблем не будет. Ну, разве что свободного времени не будет.

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

S>А может ли обезьяна, при наличии мозга, программировать, пусть даже на таком удобном языке как C#, а на Nemerle ?

Ну, я видел множество обезьян программирующих на С++. Так что на C# и Nemerle — легко.

А вот где ты видел чтобы С++ на чем-то программировал?

S>Такие вот родственнички

S>как это не чем. В С++ инстанцирование шаблона осуществляется во время компиляции, а в C#, тоже, что понимается под этим в С++, производится в в рантайм.

Извини, ты читать умешь? Я по этому поводу уже ответил.

S>Исходный вопрос был чем Дженерик KeyValuePair<K, V> лучге чем шаблон std::pair
S>

S>Может тогда расскажешь чем он лучше KeyValuePair<K, V>?

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

Но я то говорил о том, что они не хуже.
Улавливашь разницу?

S>и один из пунктов, которые я привел — это был compile-time. После этого Вы грите что это в конте5сте данного обсуждения несуществено .

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

S>Виртуальная машина — эот эмуляция реальной, байт-код — это псевдо код — эмуляция машинного

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

Твои же подмигивания в данном случае выглядят мягко говоря странно.

VD>>Понимаш ли в чем дело? Разница между нашими подходами в том, что ты думашь сколько ты набьешь кода, а я о том насколько понятным будет мой код. Только и всего.

S>Для кого понятным ?

Для тех кто будет его читать. То есть в первую очередь для себя любимого.

S> Для домохозяйки ? Для телеведущего ? Для компилятора ? Или для адекватного специалиста ?

Ну, домохозяек опустим, а вот для неадекватного специалиста хорошо бы чтобы код тоже был понятен. Ведь если он полезет его править, то хотя бы не угробит окончательно.

S> В Делфи код ещё более наглядный.

Чем где?

S> TForm1.OnClose() и все дела.

Это типа "- Да совсеми. Надо все взять и поделить!"?

S>Мой продакшн-код тоже понятный, очень наглядный — это даже не аксиома, ИБО эот не мои слова.

Боюсь даже спросить "чьи".

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

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

VD>> в Янусе 2.5 метра кода. И просто так его переписывать никто не будет.

ПК>Неужели? А как же столь расхвалявшиеся

Автор: VladD2
Дата: 06.02.06

преимущества как можно более быстрого перехода на новые перспективные технологии?

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

Чтобы перейти на тот же Нэмерле достаточно просто начать развивать то же Янус на Нэемерле. Но не обязательно его преписывать.

Была бы у меня поддрежка среды хотя бы на уровне С++, то я бы не задумываясь писал бы на Нэмерле уже сейчас. Хотя язык еще в бэтах.

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

E>Учитывая, что Ruby не сам отрисовывает такие вещи, а через C++ные библиотеки (FOX или Qt), то не думаю, что здесь будет серьезная разница в производительности.

А нафига тогда Ruby вобще нужен, если грид на С++, модель данных на С++ (потому что от нее зависит скрость отрисовки), формирование текста сообщения на С++ (потому что от скорости форматтера тоже многое зависит), подсветка синтаксиса в редакторе на С++, докинг на С++, работа с веб-сервисом на С++ (потому что нужен быстрый SOAP-форматтер).

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

AVK>А нафига тогда Ruby вобще нужен, если грид на С++

Грид на C++ потому, что в Ruby нет нативной реализации GUI.

AVK>, модель данных на С++ (потому что от нее зависит скрость отрисовки), формирование текста сообщения на С++ (потому что от скорости форматтера тоже многое зависит), подсветка синтаксиса в редакторе на С++, докинг на С++, работа с веб-сервисом на С++ (потому что нужен быстрый SOAP-форматтер).

Все остальное совсем не факт.
И нафига быстрый SOAP-форматтер, если затем будет качаться информация по узкому каналу?

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

AVK>>А нафига тогда Ruby вобще нужен, если грид на С++

E>Грид на C++ потому, что в Ruby нет нативной реализации GUI.

А в янусе его море, этого нативного GUI.

E>Все остальное совсем не факт.

Факт. Потеря в производительности на порядок в любой из этих точек привела бы к серьезным проблемам.

E>И нафига быстрый SOAP-форматтер, если затем будет качаться информация по узкому каналу?

А кто сказал про узкий канал? Производительности моего WiFi, к примеру, вполне хватает чтобы заметно подгрузить этим форматтером процессор.

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

AVK>А в янусе его море, этого нативного GUI.

И? Весь этот нативый GUI пойдет через C++ный FOX.

E>>Все остальное совсем не факт.

AVK>Факт. Потеря в производительности на порядок в любой из этих точек привела бы к серьезным проблемам.

Пока нет замеров, не факт.

E>>И нафига быстрый SOAP-форматтер, если затем будет качаться информация по узкому каналу?

AVK>А кто сказал про узкий канал? Производительности моего WiFi, к примеру, вполне хватает чтобы заметно подгрузить этим форматтером процессор.

Так www.rsdn.ru может отдавать данные со скоростью твоего WiFi?

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

AVK>>А в янусе его море, этого нативного GUI.

E>И? Весь этот нативый GUI пойдет через C++ный FOX.

А нафик тогда Руби?

AVK>>Факт. Потеря в производительности на порядок в любой из этих точек привела бы к серьезным проблемам.

E>Пока нет замеров, не факт.

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

AVK>>А кто сказал про узкий канал? Производительности моего WiFi, к примеру, вполне хватает чтобы заметно подгрузить этим форматтером процессор.

E>Так www.rsdn.ru может отдавать данные со скоростью твоего WiFi?

Может.