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

I>Способный чтото делать и способный решать все задачи по проекту — это разные вещи.

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

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

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

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

I>Заменить топа может только топ. Это и есть тот риск, о котором говорит Панкратов.

Риск есть всегда. Я правильно понимаю, что ты предлагаешь вообще не брать на работу "топов", а ориентироваться на серые массы (посредственность)? Ну, что это позволит потом менять людей без проблем. Да?

Если так, то не боишься, что эта посредственность просто завалит проект или сделает его намного более дорогим?

ЗЫ

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

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

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

I>>Ты начл мне объяснять про ПМ — "Визиторы — это малюсенькая часть..." А я всего лишь сказал, что если чел попробовал визитор то он гарантировано готов узнать ПМ.

IT>И это не верно. С помощью ПМ можно решать такие же задачи, которые решаются визиторами, а именно type dispatching. Но это не значит, что сами решения как-то пересекаются и взаимозаменяемы.

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

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

IT>Ты точно внимательно прочитал то, что я написал? Ещё раз. Понять ПМ на порядок проще чем визитор. А не наоборот.

Для того, что бы понять визитор, всех знаний-умений необходимо — базовые знания ООП. Потому как визитором решаются достаточно простые задачи вроде type dispatching. А вот ПМ сильно предназначен для более сложных задач.

И до тех пор, пока человек не помет те задачи, для которых и вводился ПМ, он ПМ этот не поймет.

Т.е. грубо говоря, если ты не в состоянии выявитьили хотя бы распознать закономерность в графе объектов, ПМ тебе нисколько не поможет. Сначала нужно научиться решать такие задачи хоть как нибудь, а уже потом браться за ПМ.

Вот ты можешь перечислить минимальный набор знаний-умений освоение которого даст возможность осилить ПМ за пол-часа ?

I>>Да, я слышу это легенду уже в пятый раз наверное. Указатели на функции в С++ применяются совсем не так легко как в дотнете делегаты и типичный сиплюсник спокойно утверждает "лямбды не нужны".

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

Всякая правда когда нибудь становится легендой. Я употребил слово легенда, а не сказка и по моему разница есть

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

I>>Ну в твоем случае очевидно требования к самому себе очень высокие или ты нашел где придраться к словам Обычно на всё это уходит около года.

IT>Чтобы начать писать рабочий код года не нужно. Иначе ни одна контора в мире никогда не перешла бы на .NET.

Начть писать можно почти сразу, с этим я согласен. Но перформанс будет не тот.

IT>На самом деле у сиплюсплюсников есть определённые сложности в понимании .NET, хотя ни одной из них ты не назвал. Это проблема связанная с circle references, которая на плюсах в общем случае не решается никак, и осознание того, что выделение большого количества мелких объектов на короткое время в .NET операция бесплатная и не надо здесь заниматься никакими оптимизациями. Всё остальное берётся более менее не сложно.

В моем понимании это все входит в GC.

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

I>И до тех пор, пока человек не помет те задачи, для которых и вводился ПМ, он ПМ этот не поймет.

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

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

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

Разумеется. Чем помогут макросы немерле, если человек еще не освоил тех задач, что требуедт сложный проект ?

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

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

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

То есть, язык не помогает, но помогает ? Я шота не понял, что ты хотел сказать, но понял, что ты точно VladD2

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

Не, в такие игры мы играть не будем. В любом более менее сложном проекте приходится выяснять, какая же унутре неонка. И ДСЛ с макросами тут никак не поможет.

VD>Риск есть всегда. Я правильно понимаю, что ты предлагаешь вообще не брать на работу "топов", а ориентироваться на серые массы (посредственность)? Ну, что это позволит потом менять людей без проблем. Да?

Нет. Я предлагаю не ждать проект если такой топ отсутствует. В случае с немерле это значит, что Немерле не юзать а тем более Немерле с макросами.

VD>Если так, то не боишься, что эта посредственность просто завалит проект или сделает его намного более дорогим?

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

У вас Немерле то мейнстримный, то немейнтсримный, то для себя, то для топовых профи, короче, хрен его знает, как вы его позиционируете. Соответсвенно не ясно, куда он вообще развивается.
Вот взять сообщения немерлистов — "я макросы на нем не писал" или "написали всего один макрос". Ну куд это годится ?

VD>ЗЫ

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

Я точно знаю, что это не так.

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

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

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

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

I>Кто заменит человека, который сейчас пишет на этом новом языке ?

1. Любой квалифицированный C#-программист после некоторого обучения. Пара дней для старта, месяц для уверенной работы и исправления багов в проекте, и где-то полгода-год чтобы дорасти до уровня гуру.
2. Другой человека, который сейчас пишет на этом новом языке. Не веришь, выставляй вакансию прямо здесь. Уверен, что желающие найдутся сразу же.

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

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

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

Соответсвенно, сначала надо прокачать это мышление, а потом можно предлагать ПМ.

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

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

I>При том поиске что есть сейчас найти чтото невозможно. Я эту тему уже устал поднимать. Так что как есть.

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

I>Это и есть нихрена, потому что 5 лет назад вы обещали чуть не Микрософт на Немерл пересадить

5 лет назад была весна 2006-го года. Лично я в это время даже не был знаком с Nemerle.

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

I>Раздражение сильное есть, да. А что бы нравится — ну это вряд ли. Ну может чуток подразнить хочется, но не более того.

На просторах Интернета можно найти тучу новых и не очень языков. D например, или там Scala. Но почему-то ты на форуме посвященном Nemerle. Стало быть этот язык тебе не безразличен. Почему?

Мне вот тот же D или Хаскель по барабану. Я и не лезу спорить о его перспективах.

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

VD>1. Любой квалифицированный C#-программист после некоторого обучения. Пара дней для старта, месяц для уверенной работы и исправления багов в проекте, и где-то полгода-год чтобы дорасти до уровня гуру.

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

VD>2. Другой человека, который сейчас пишет на этом новом языке. Не веришь, выставляй вакансию прямо здесь. Уверен, что желающие найдутся сразу же.

В Москве — вполне возможно. Я как то понаблюдал как пару проектов завязаных на фунциональщину отсохли. И еще один, очень крупный, скоро отдаст концы. Так что я сильно сумлеваюсь, особенно потому, что ЗП на эти проекты были топовыми настолько что топовее некуда.

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

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

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

Пусть медленно и хреново. Главное, чтобы надежно!

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

I>>При том поиске что есть сейчас найти чтото невозможно. Я эту тему уже устал поднимать. Так что как есть.

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

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

I>>Это и есть нихрена, потому что 5 лет назад вы обещали чуть не Микрософт на Немерл пересадить

VD>5 лет назад была весна 2006-го года. Лично я в это время даже не был знаком с Nemerle.

Да ладно гнать то:
"А вот в Нэмерле можно легко реализовать дополнительные проверки.
Лисп тут тоже ничем не лучше. У него тольо больше тараконов."

Январь 2006го, узнаёшь автора ?

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

VD>Прекрасный пример. Это конечно же ужасная ситуация. Куда лучше было бы оставить деплой в два часа и не поднимать количество проектов. Тогда при переходе на новое железо проблем не будет. Да и меньшее в 10 раз количество проектов поддерживать ведь проще.

VD>Пусть медленно и хреново. Главное, чтобы надежно!

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

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

VD>На просторах Интернета можно найти тучу новых и не очень языков. D например, или там Scala. Но почему-то ты на форуме посвященном Nemerle. Стало быть этот язык тебе не безразличен. Почему?

Мне в нём не нравятся две вещи — макросы и евангелисты.

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

I>Руководство заставит автоматизировать хоть на вбскрипте, потому что больше проектов хостится, больше денег приходит.

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

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

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

I>Разумеется. Чем помогут макросы немерле, если человек еще не освоил тех задач, что требуедт сложный проект ?

О! Они (при их правильном применении) могут очень сильно помочь. Решение можно сделать значительно более простым для понимания. Причем для понимания тех самых середнячков (а то и для индо-обезьян).

Вместо того чтобы учить библиотеки и разбирать тонны малопонятного кода надо всего лишь выучить семантику простого ДСЛ-я и далее читать код на совершенно ином уровне абстракции.

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

I> А ты точно VladD2 ?

Точно.

I>По идее ты должен был бы написать, что знание языка тут как раз таки помогает.

А так оно и есть. Только не так примитивно как ты думаешь. И это факт, а не слепая вера.

I>Но яс тобой согласен, что знание языка в обозначеном вопросе не помогает. А вот незнание становится большой преградой.

Ага. Только не знание языка устраняется в сто раз проще нежели не знание проекта. Объем информации просто не сопоставим.

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

I>То есть, язык не помогает, но помогает ? Я шота не понял, что ты хотел сказать, но понял, что ты точно VladD2

А ты прочит еще рез. Язык помогает сделать проект проще. И время затрачиваемое на изучение языка сторицей компенсируется временем сэкономленным при изучении проекта.

Тут все очень просто. Изучение языка это O(1). Оно делается один раз и занимает константное время. А изучение кода проекта имеет сложность O(n * m), где n объем кода проекта, а m — сложность этого кода. Грамотное применение средств языка способно уменьшить как n, так и m. Код становится более высокоуровневым, а значит как более коротким, так и более понятным.

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

I>Не, в такие игры мы играть не будем. В любом более менее сложном проекте приходится выяснять, какая же унутре неонка. И ДСЛ с макросами тут никак не поможет.

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

VD>>Риск есть всегда. Я правильно понимаю, что ты предлагаешь вообще не брать на работу "топов", а ориентироваться на серые массы (посредственность)? Ну, что это позволит потом менять людей без проблем. Да?

I>Нет. Я предлагаю не ждать проект если такой топ отсутствует. В случае с немерле это значит, что Немерле не юзать а тем более Немерле с макросами.

Это ты уже изворачиваться начал. Ты фактически повторил мои слова. Твои слова можно перефразировать так — "Что думать? Трясти надо!". Вот только не всегда трясти — это эффктивное решение. Чем сложнее проект тем меньше шансов успешно его реализовать путем складывания усилий низкоквалифицированных кадров. Если сложность проекта в основном связана с объемом кодирования, то возможно это и сработает. Но не дай бог там есть другие виды сложности (алгоритмическая, логическая и т.п.), то проект почти наверняка обречем на провал или по крайней мере превратится в унылое дерьмо и долгострой.

VD>>Если так, то не боишься, что эта посредственность просто завалит проект или сделает его намного более дорогим?

I>Не все проекты требуют твоего Немерле, это совершенно точно.

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

I>А те которые требуют хрен его знает как их выявить. Вы в этом направлении похоже отказываетесьб делать какие либо подвижки.

У тех кто использовал язык, обычно одного взгляда на проект хватает чтобы понять, что немерл отличное средство для его реализации (или нет). Так что не надо создавать еще одну фобию.

I>У вас Немерле то мейнстримный, то немейнтсримный, то для себя, то для топовых профи, короче, хрен его знает, как вы его позиционируете. Соответсвенно не ясно, куда он вообще развивается.

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

Кроме того Немерл отлично подходит и для команд состоящих из одних лишь профи, так как позволяет им организовать процесс создания ПО на необходимом уровне (автоматизации и абстракции).

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

I>Вот взять сообщения немерлистов — "я макросы на нем не писал" или "написали всего один макрос". Ну куд это годится ?

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

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

Например, написание любого нетривиального парсара на Немреле в разы проще и эффективнее нежели на C# (да и на большинстве других языков), так как есть Nemerle.Peg.

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

I>Я точно знаю, что это не так.

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

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

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

Большинство выдающихся продуктов только так и пишется. По крайней мере первые и ключевые версии.

I>При имеющемся раскладе на рынке труда количество проектов превышает число не только этих команд, но и число этих самых специалистов.

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

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

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

Решение немерла — это специализация инструмента под задачу. В общем, инструмент остается простым (на уровне C#), но позволяет существенно увеличить свою мощность за счет подключаемых модулей.

Кроме того такой подход позволяет объединить усилия спецов и серой массы. Ведь спецы могут ваять те самые специализированные инструменты (в виде ДСЛ-ей и фрэймворков), а серые массы использовать их для повышения уровня кода реализующего рутину.

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

Так что по сути это революция в мире разработки ПО. Вот только пока что массы этого не осознают.

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

I>Просто это значит, что у людей абстрактное мышление прокачано не настолько сильно, что бы видеть картину в целом.

Ага. Снова возвращаемся к тезису о том что все вокруг дебилы, а только "я" д'артаньян на белом коне.

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

VD>>1. Любой квалифицированный C#-программист после некоторого обучения. Пара дней для старта, месяц для уверенной работы и исправления багов в проекте, и где-то полгода-год чтобы дорасти до уровня гуру.

I>До гуру может и вся жизнь уйдет. За пол-года год можно получить свободное владение, т.е. 80% вопросов будут решаться сходу, а оставшиеся 20% будут решаться самостоятельно безо всяких рисков и существенных издержек.

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

Как я понимаю других возражений нет?

VD>>2. Другой человека, который сейчас пишет на этом новом языке. Не веришь, выставляй вакансию прямо здесь. Уверен, что желающие найдутся сразу же.

I>В Москве — вполне возможно.

Плати нормальные деньги и люди поедут в другие города.

I>Я как то понаблюдал как пару проектов завязаных на фунциональщину отсохли. И еще один, очень крупный, скоро отдаст концы.

Я даже не смог понять о чем ты тут говоришь. Плюс не ясно почему ты так упорно делаешь акцент на "функциональщине"? Немерл не ортодоксальный ФЯ. Это гибрид. Он в том числе позволяет применять ФП на уровне лучших ФЯ. Но ФП в нем не более чем одна из поддерживаемых парадигм. ИП, КОП, ДСЛ и МП не менее родные парадигмы. Если же делать ставку на ФП, то возможно имеет смысл выбирать Хаскель.

I>Так что я сильно сумлеваюсь, особенно потому, что ЗП на эти проекты были топовыми настолько что топовее некуда.

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

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


I>Не, с меня уже хватит. Я больше ничего на рсдн не ищу поиском. Гугл и яндекс находят мало, а встроеный поиск какой то избирательный.
...
I>Да ладно гнать то:
I>"А вот в Нэмерле можно легко реализовать дополнительные проверки.
I>Лисп тут тоже ничем не лучше. У него тольо больше тараконов."
I>Январь 2006го, узнаёшь автора ?

О, как? А как же ты нашел это, если поиск не работает? Какое-то противоречие. Значит или ты по памяти цитируешь и дату цитаты называешь, или все же поиск работает и то что было он все же находит.

Неувязочка у вас.

Что касается твоих слов, то ты утверждал что 5 лет назад звучали заявления о том, что будет через 5 лет. Я может и ошибаюсь в месяцах, но о Nemerle я точно узнал в 2006-ом. И в то время я не мог ничего говорить о нем просто потому, что не был к нему причастен. Я только изучал его в то время.

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

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

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

VD>>На просторах Интернета можно найти тучу новых и не очень языков. D например, или там Scala. Но почему-то ты на форуме посвященном Nemerle. Стало быть этот язык тебе не безразличен. Почему?

I>Мне в нём не нравятся две вещи — макросы и евангелисты.

Но значит что-то нравится, раз ты здесь и общаешся с этими неугодными евангилистами?

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

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

I>Т.е. грубо говоря, если ты не в состоянии выявитьили хотя бы распознать закономерность в графе объектов, ПМ тебе нисколько не поможет. Сначала нужно научиться решать такие задачи хоть как нибудь, а уже потом браться за ПМ.
I>Вот ты можешь перечислить минимальный набор знаний-умений освоение которого даст возможность осилить ПМ за пол-часа ?

Всё же я не понимаю твоей логики. То тебя решаемые задачи интересуют, то знания-умения Впрочем, знания-умения нужны где-то на уровне знания ООП, не более.

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

Конечно, придётся. Но это другая проблема. Ты же до этого утверждал, что твои люди не способны вообще это понять.

IT>>Чтобы начать писать рабочий код года не нужно. Иначе ни одна контора в мире никогда не перешла бы на .NET.
I>Начть писать можно почти сразу, с этим я согласен. Но перформанс будет не тот.

Главное, что он будет.

IT>>На самом деле у сиплюсплюсников есть определённые сложности в понимании .NET, хотя ни одной из них ты не назвал. Это проблема связанная с circle references, которая на плюсах в общем случае не решается никак, и осознание того, что выделение большого количества мелких объектов на короткое время в .NET операция бесплатная и не надо здесь заниматься никакими оптимизациями. Всё остальное берётся более менее не сложно.

I>В моем понимании это все входит в GC.

Не совсем так. Можно детально разобраться в том как работает GC, но эти вещи всё равно не будут тебя отпускать.