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

D>На самом деле, эта картинка давно известтна. Проблема была отнюдь не в супер быстром Эрланге.
D>Была проблема, что не использовались Selectors для сокетов. И до Java5 Selectors в яве не было.
D>После Java5 в Томкате соотвтетсвующей версии добавили Selectors и все стало также как для псевдомегасервера Yaws
Агащазз. Пул потоков — ограничен, а значит пара десятков задумавшихся сервлетов запросто положат сервер.

Здравствуйте, Олег Гашев, Вы писали:


G>>не стоит говорить за всех. куча народу пишет много лет на одном языке и развивается просто несколько в другую сторну.

ОГ>Куча народу просто зарабатывают деньги и пишут на том, на чём им говорят писать. Поэтому до сих пор живой perl, lisp, php, assembler. Хотя давно уже есть более современные вещи.
при чем тут это?

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

ОГ>Когда я скажу работодателю, что хочу писать на немерле, мой email уйдёт в trash. Кто будет мои проекты саппортить после меня? Такое работодатель себе не позволит.

я об обратной ситуации. когда работодатель скажет.

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

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

D>>На самом деле, эта картинка давно известтна. Проблема была отнюдь не в супер быстром Эрланге.
D>>Была проблема, что не использовались Selectors для сокетов. И до Java5 Selectors в яве не было.

D>>После Java5 в Томкате соотвтетсвующей версии добавили Selectors и все стало также как для псевдомегасервера Yaws

A>О еще один... не в селекторах дело... чем тебе помогут селекторы, если выполнение кода должно быть заблокировано? Больше 5к потоков в java ты никак не сделаешь, а значит будешь рожать всякие пулы и прочие радости. Для коротких задач — есть actors на scala, там несколько проще, но все равно: реальных потоков в java очень мало, а значит любая задача превращается в разбиение на producer/consumer цепочки, а значит это тащит за собой обработку ошибок и управление этим хозяйством (что будет если все consumer-ы подохнут?)

Так. Еще раз.

Про конкретно этот тест были в своё время разговоры. Он конкретно починился селекторами. Конкретно точка.

Фрейиворков же producer/consumer в яве достаточно.

Здравствуйте, Олег Гашев, Вы писали:


ОГ>Куча народу просто зарабатывают деньги и пишут на том, на чём им говорят писать. Поэтому до сих пор живой perl, lisp, php, assembler. Хотя давно уже есть более современные вещи.

lisp точно не поэтому.

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

D>Про конкретно этот тест были в своё время разговоры. Он конкретно починился селекторами. Конкретно точка.
Еще раз, это медленные запрос/ответ. Как именно селекторы помогут? (абстрагируйся от io, представь что для ответа тебе надо генерировать длиннющую колбасу из буков 'a' и 'b')

D>Фрейиворков же producer/consumer в яве достаточно.
Ты не понимаешь о чем я говорю.

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

D>Фрейиворков же producer/consumer в яве достаточно.
Как сказал бы McSeem, это не Фрейиворков,
тьфу ты, это не фейерверк, это так, поллюция...
по сравнению с Эрлангом.

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

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

D>>Про конкретно этот тест были в своё время разговоры. Он конкретно починился селекторами. Конкретно точка.
A>Еще раз, это медленные запрос/ответ. Как именно селекторы помогут? (абстрагируйся от io, представь что для ответа тебе надо генерировать длиннющую колбасу из буков 'a' и 'b')

D>>Фрейиворков же producer/consumer в яве достаточно.
A> Ты не понимаешь о чем я говорю.

А, то есть мы сгенерили 100000 колбас этих 'a' и 'b', но клиенты не готовы их принять? Хм, да, селекторы тут не причем

А Эрланг навреное иммет специальные лекговесные сущности, такие что вышеопесанное проблем не вызывает? Принято

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

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

D>>Фрейиворков же producer/consumer в яве достаточно.
R>Как сказал бы McSeem, это не Фрейиворков,
R>тьфу ты, это не фейерверк, это так, поллюция...
R>по сравнению с Эрлангом.

Ну где же смайлик "пад стулом"

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

T>Сам никогда под ВМ не писал, за четыре года работы юзал в общем-то только разные ассемблеры (штуки четыре или пять), C, C++ и немножко Delphi. Ну ещё выучил Lisp чтобы на досуге развлекаться. Но какт всегда думал что в общем-то пофиг managed/unmanaged, инструмент и есть инструмент.

T>В последнее же время наблюдаю совершенно ужасную тенденцию — человек переходит (из-за денег или просто по воле начальства) с неуправляемого кода на управляемый и в течении полугода объективно тупеет. Просто становится неспособен думать про управление памятью, перестаёт представлять себе как чтот функционирует внутри реального железа и как следствие больше не может перейти обратно, становится обречён писать под виртуальные машины. Некоторые даж забывают асм и становятся неспособны сломать простейший прот на программке, то есть сделать вещь которую даже шестнадцатилетние дети умеют и которая вообще навыков программирования не требует. Забывает Рихтера и организацию памяти, зато начинает думать о какойт "бизнес-логике" и прочей лабуде. Хуже того, забывает основные алгоритмы, забывает Кнута и Кормена, зато начинает хвастаться знанием каких-то "библиотек" и "платформ".

T>Сначала думал что эт касается только людей от природы не крепких духом. Но вот прочитал разительное на мой взгляд сообщение:

T>http://www.rsdn.ru/forum/message/2511620.1.aspx

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

T>Это же чудовищно. VladD2 — несомненно умный человек, автор большого количества интересных статей и сообщений. Мы все его уважаем и т.д.. Но не справиться с парой строк кода на примитивном и в общем-то берущем почти всё на себя Delphi — это финиш. Эт значит человека нужно брать и заново учить, писать код он уже явно не может.

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

T>Разубедите меня.

T>P.S. Я думаю очень скоро тенденции рынка пересадят на Java/C# громадное количество программистов во всяких банковских и прочих сферах, которые медленно но верно деградируют там до уровня "VB-кодеров" и "1С-программистов". Что освободит рынок где требуются профессионалы для настоящей разработки и создаст чудовищный кадровый голод на действительно понимающих людей. Такчт пора освежать скиллы в pure C.

T>P.P.S. Кроме программирования, преподаю сейчас на кафедре и вижу почти те же тенденции у своих студентов, прям с детства стремление меньше думать больше получать.

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

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

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

D>>Люди пересаживаются на иномарки и забывают как разобрать-собрать двигатель.
D>>ИМХО на самом деле всё совсем не так фатально. Просто переходим на всё более
D>>высокие уровни абстракции. А на старые при необходимости вернуться хоть и не
D>>элементарно, но вполне можно.

T>Нет, не всё так просто. Более высокий уровень абстракции эт скажем использование STL и Boost где надо. Здесь кто бы спорил, чем выше тем лучше. Но отдавать такой важный ресурс как память на откуп автоматическому сбору мусора это уже не более высокий уровень, это уже смена мировоззрения. Вместо ответственной оценки потребления памяти, мы грубо говоря плюём на эту сторону вопроса.

T>Мне вот наверное всё-таки придётся выучить хотя бы один управляемый язык просто чтобы поставить эксперимент: берём алгоритм с теоретическим O(f(N)) по памяти, гоняем его реализацию на большом объёме тестовых данных с детерминированным управлением памятью, замеряем реальные расходы, оцениваем константы Cmin и Cmax для данной платформы, потом то же самое со сборщиком мусора, снова замеряем реальный расход памяти и смотрим, осталось у нас рассчётное O(f(N)) или реально стало уже O(g(N)) и куда уползли константы. Я почемут очень подозреваю что недетерминированность в управлении памятью может отражаться на базовых свойствах вычислений как таковых, особенно если научится специально подбирать выборки так чтобы сборщик мусора на них ломался. Например как поведёт себя автоматическое управление памятью, когда мы подойдём к физическому пределу памяти на машине?

T>Кстати про алгоритмы этих сборщиков тоже надо почитать. Но здесь я жду следующего стандарта C++, когда GC можно будет попробовать в отрыве от виртуальной машины. И без отрыва от любимого языка. Тогда и займусь этим плотней.

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

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

IO>Макросы Немерля достаточной длины, что-бы выстрелить себе в ногу?

Если есть лишняя ногда, то можешь попробовать.

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

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

Дык, за одно отличный ценз. Может выучить — наш человек. Нет? А ну его на...

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

G>не стоит говорить за всех. куча народу пишет много лет на одном языке и развивается просто несколько в другую сторну.

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

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

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

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

Здравствуйте, Олег Гашев, Вы писали:

ОГ>Когда я скажу работодателю, что хочу писать на немерле, мой email уйдёт в trash. Кто будет мои проекты саппортить после меня? Такое работодатель себе не позволит.

А ты будь умнее. Не говори, что хочешь, а говори что можешь. Уверяю тебя, что твой работадатель, если он сам что-то понимает в индустрии, будет только рад если ты напишешь, что в совершенстве владешь Лиспом и/или Немерле.

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

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

Извини, ты хочешь конкурировать с производителями дешевого ширпотреба? Да еще пользуясь аналогичными средствами производства (коленками)? Успехов тебе в этом занятии.

A>С остальным согласен , правда это пока идеал, к которому надо стремиться

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

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

ДВ>>> (компьютерная графика
VD>>Вот только это не те области где пуравляемые языки не справляются .
CC>На досуге скачай "CellFactor — Revolution" и полюбуйся как там .NET справляется.

Я даже поверю, что в этом "CellFactor — Revolution" что-то плохо и не так (хотя не знаю, что это). Но что это даказывает? Я вот на досуге, как-то, ставил Frontpage (первый) и он дико тормозил даже на небльших документах. Написан он был на С++. Но почему-то мне даже в голову не пришло ассоциировать тормоза конекретного продукта с С++. Так почему же я должен думать иначе в случае дотнета? У меня перед глазами масса примеров где основанные на дотнете продукты работают быстро, стаблильно и качественно.

Вот тот же Paint .NET. Или несколько игр которые были написаны на дотнете.

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

D>>Фрейиворков же producer/consumer в яве достаточно.
R>Как сказал бы McSeem, это не Фрейиворков,
R>тьфу ты, это не фейерверк, это так, поллюция...
R>по сравнению с Эрлангом.

Мне кажется послднее приятнее .

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

AF>Только в случае с механическими инструментами никто не говорит "я решил использовать для изготовления стола напильник вместо рубанка, потому что он дает более качественную поверхность. С рубанком такой никогда не добиться.". Или например "я решил спилить это дерево лобзиком, потому что лучше знаком с этим инструментом". Засмеют. А вот в случае с программированием подобные заявления звучат сплошь и рядом.

Хм. Я тоже это заметил недавно. Однако, тенденция .

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

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


VD>Дык. Если сидеть на заднице, то кроме геморроя и дырки на портках точно ничего не получишь. Так что по любому нужно дергаться. Любое конкуретное приемущество есть благо. И уж значитлеьно более мощьный инструмент в руказ значительно более толковых программистов — это точно хорошее начало для того чтобы взгреть толпу индусов.

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

Я отступлю от темы , может мне ктонить кратко опяснить , почему современные JIT отстают от лучших оптимизирующих компиляторов по качеству кода. Хотя теоретически такого быть не должно ? Это связанно с тем что JIT не имеет право тратить много времени на компиляцию ?

Спасибо!