Здравствуйте, Ikemefula, Вы писали:
I>Как же он поймет если ты не хочешь прояснять и пояснять свою позицию ?
Извини, но я не знаю как объяснять такие вещи. Название темы абсолютно не допускает ни какого толкования. Там прямым и понятным русским языком сказано.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Ikemefula, Вы писали: IT>>Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности. I>Я на полном серьезе считаю, что второй вариант проще. Кода больше, но он и сообщает много больше.
А я на полном серьезе считаю, что второй вариант очень сложный, но мощный. Я до сих пор путаюсь в format specifiers, но зато я могу, к примеру, точно выбрать формат вывода даты.
Доллар-нотация мне не нравится потому, что я к ней не привык, и потому, что я не понимаю как, к примеру, указать необходимость выводить два знака после запятой. Хотя объяснять ее, несомненно, проще.
Может, кто-нибудь из фанатов Nemerle покажет мне, как написать аналог вот этого:
Console.WriteLine("Rum-Coke: ${0:F2}", 10/3);
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Lloyd, Вы писали:
L>Можно поинтересоваться, когда вы договариваетесь с заказчиком об используемых технологиях, вы говорите ему, что собираетесь в качестве основного языка разработки использовать язык, разрабатываемый на добровольных началах небольшой группкой русских программистов? Или тактично замалчиваете этот момент?
Языки программирования, которые мы можем использовать, определяются политикой компании. К сожалению. Но парадигмы программирования, техники и технологии политикой компании не ограничиваются никак. Поэтому, мы используем МП на всю катушку. Это позволяет нам сокращать в разы количество соответствующего кода, существенно упрощать его поддержку и ускорять разработку. Для меня лично эффективность МП не просто очевидна, она доказана практически.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sinclair, Вы писали:
S>Доллар-нотация мне не нравится потому, что я к ней не привык, и потому, что я не понимаю как, к примеру, указать необходимость выводить два знака после запятой. Хотя объяснять ее, несомненно, проще.
Здравствуйте, mihailik, Вы писали:
M>$"Output: $a"
IT>>Первый вариант довольно тупо реализуется в runtime через string.Concat.
M>Вряд ли кому-то после такого объяснения останется непонятно, зачем там доллары внутри и снаружи кавычек.
Думаю, что суть примера стала ясна всем с первого взгляда. В том числе и тебе. Но тебе же очень хочется поспорить, правда? Потролить чуток. Посамолюбоваться. Тут я бессилен.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, rameel, Вы писали:
I>>Я честно скажу — с трудом догоняю эти $. Я хорошо понимаю только то что легко проговаривать.
R>Подстановка переменных, сплайс-строка, интерполяция строки
Ну вот сравни
string.Format
статический метод Format класса String. Это ООП и потому легко. ООП — это уже каменый век. Такое знает почти каждый студент первого курса.
R>>>А почему не наоборот Причем, что первую что вторую тоже вполне может понадобиться разъяснять через printf, если человеку так легче.
I>>Потому что это будет обман будет.
R>В чем обман? Ну не знаком человек с шарпом, зато знает си, ну показал ты ему что
R>
string.Format("Output: {0}", a) = sprintf("Output: %s", a)
Это и есть обман. Слишком много деталей упускается из рассмотрения.
Здравствуйте, rameel, Вы писали:
I>>Вот тебе и сложность.
R>
Интерполяция строки позволяет автоматически подставить вместо переменной ее фактическое значение. (с) Кто-то другой
R>Это ведь так сложно понять
Что значит автоматически и что значит фактическое значение ?
Вот, например, в Format все прозрачно — кучка перегруженых методов, указывается строка, значения и представление этих значений.
Единственная сложность — спецификаторы формата, их помнить не нужно, это справочная информация.
Т.е. string.Format("something:{0}",a) означает
у класса String вызывается статический метод Format которому передается строка и параметр а
вот это следует явно из записи, а терминология — ООП.
Если нужно больше информации, человек, который глянет в хелп, увидит, что строка может указывать представление согласно которому доп. параметры будут преобразованы в строки и вставлены в нужные места.
Здравствуйте, IT, Вы писали:
IT>Думаю, что суть примера стала ясна всем с первого взгляда. В том числе и тебе. Но тебе же очень хочется поспорить, правда? Потролить чуток. Посамолюбоваться. Тут я бессилен.
Суть примера ясна, а вот возможности твоей первой строки не ясны даже Синклеру А в формате это ясно прямо из записи.
Здравствуйте, Sinclair, Вы писали:
IT>>>Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности. I>>Я на полном серьезе считаю, что второй вариант проще. Кода больше, но он и сообщает много больше. S>А я на полном серьезе считаю, что второй вариант очень сложный, но мощный. Я до сих пор путаюсь в format specifiers, но зато я могу, к примеру, точно выбрать формат вывода даты. S>Доллар-нотация мне не нравится потому, что я к ней не привык, и потому, что я не понимаю как, к примеру, указать необходимость выводить два знака после запятой. Хотя объяснять ее, несомненно, проще. S>Может, кто-нибудь из фанатов Nemerle покажет мне, как написать аналог вот этого:
Слушай, не понял идею, твой пост сводится к "Объясните мне вот ту простую фичу которую легко объяснять другим"
Здравствуйте, Sinclair, Вы писали:
VD>>Кто это придумал? S>Это очевидно. Дело не в отсутствии исходников макроса, а в объеме работы. Сколько тебе потребовалось "допилить", чтобы Nemerle поддержал Linq?
Видимо ты забыл о чем шла речь. Напомню контекст:
V>>Но с другой стороны возможен компромиссный вариант, когда мы делаем незначительное изменение генератора (например, всего лишь добавляем вызов partial метода) и получаем тем самым возможность сделать ручное изменение, которое не пропадёт после повторной генерации исходников.
S>Речь о том, что это не всегда возможно.
Кто это придумал?
Я отвечу на твой вопрос сразу после того как ты скажешь какое он имеет отношение к данному обсуждению?
S>На всякий случай подчеркну, что речь о предположении prVovik о том, что для решения частной проблемы можно "просто добавить в макрос вызов partial method", а не о всеобщей применимости макросов.
Лучше, на всякий случай, поясни какое отношение имеет вопрос объем каких-то там работ к возможности подправить макрос и вставить в него те же partial-ы которые позволят вручную что-то там подправить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Первый вариант тоже имеет право на жизнь и часто используется. У меня в конторе народ генерирует генератором Linq2SQL набор классов по БД, зачем вычищает оттуда весь мусор и уже далее поддерживает этот код вручную. В принципе, ничего плохого в этом нет. Небольшая автоматизации на начальном этапе.
Я бы за это руки отрывал. Намного проще создать качественный генератор.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IB, Вы писали:
IT>>У меня в конторе народ генерирует генератором Linq2SQL набор классов по БД, зачем вычищает оттуда весь мусор и уже далее поддерживает этот код вручную. В принципе, ничего плохого в этом нет. Небольшая автоматизации на начальном этапе. IB>Похоже большинство именно так и делает.. )
Ага. И по этому на него лучше не равняться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
AVK>>Нет, надо перечитывать, пока не поймешь смысл написанного.
I>Как же он поймет если ты не хочешь прояснять и пояснять свою позицию ?
А, мне кажется, что это и есть позиция — отсутствие желания пояснять свои общие фразы. Ведь с общими фразами не поспоришь. А начнешь домысливать и тебя тот час уличат в мозговедстве или еще чем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mihailik, Вы писали:
AVK>>А если в солюшене файлов с custom tool несколько сотен?
M>Тогда потрать 10 минут и напиши програмулинку, чтобы вызывало. Обычно все Custom Tool имеют программируемый API.
Есть способ лучше. Выкинуть их к чертям и пользоваться средствами больше подходящими для этих целей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VoidEx, Вы писали:
L>>>>Кстати, а как предполагается локализовывать подобного рода строки? VE>>>Можно я, можно я спрошу? А вы локализуемые строки прямо в исходниках пишете английским, да?
L>>Изначально — да. Когда нужно переводить — переносятся в ресурсы.
VE>1. Изменять английский можно, не трогая исходник?
Не понимаю, что имеется в виду.
VE>2. Добавить десять новых строк в исходник так, чтобы он не потёр изменённые [английские] ресурсы, а только добавил дописанные десять строк можно?
См. выше.
VE>3. Сделать обратную операцию — из ресурса в исходник — можно?
Зачем?
VE>4. Как генерируется ID (или что там?) у строчки? Если удалить рандомно 10 штук из исходника, текущий на данный момент ресурс останется валидным?
Какие-то странные у тебя вопросы. ID геренится руками. Зачем что-то удалять я не понимаю.
VE>п.с. я не с издёвкой, меня правда интересуют эти вопросы
Прочитай раздел msdn-а про локализацию приложений. Чего его тут персказывать-то?
Здравствуйте, Ikemefula, Вы писали:
IT>>Ну так ты изъясняйся яснее. Сам знаешь, неясность изложения свидетельствует о путанности в мыслях. Мне действительно трудно уловить твои притензии к МП в Немерле.
I>К самому Немерле вряд ли могут быть претензии.
Как видишь — есть. И, на мой взгляд, весьма не обоснованные и сумбурные.
I>Ну будет еще один Лисп, которым займется узкий круг лиц, ну и что ?
Лисп и Немерле совершенно разные языки. У лиспа нет синтаксиса. От того в нем легко делать макры, но тяжело писать и (особенно) читать код. Плюс Лисп динамически типизированный. В таком виде он может быть осилен только теми кто проникся силой макр.
Немерле же — это C# с человеческим лицом. На нем можно писать не написав ни одного макроса и писать значительно удобнее чем на C# и тем более чем на С++. А макросы — это просто мощная пушка позволяющая пробивать стены которые нельзя пробить без нее.
Посему как раз Немерле, будь в него вложены бабки, может спокойно стать новым лидером среди мэйнстрим-языков. Вот только те у кого есть деньги еще не доросли до него, боятся взять на себя ответственность или считают что их идеи куда лучше (т.е. считают его конкурентом которому как минимум не надо помогать).
В общем, люди делятся на три категории:
1. Те кто высказывает свой скепсис.
2. Те кто не может его использовать по объективным причинам (например, мешат отсутствие дотнета на поддерживаемых платформах).
3. И те кто потратил время и разобрался в нем.
Пока что не видел людей реально изучивших Немерле которые говорили бы что язык фиговый.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ага. И по этому на него лучше не равняться.
Ты о чем? На данный момент это единственный внятный способ работать с LINQ2SQL, если лень хранимки писать.
Здравствуйте, Ikemefula, Вы писали:
R>>Да ну А обоснования будут?
I>А надо ?
Надо.
I>Не мог бы ты еще больше текста скипать ?
Там все равно кроме откровенной чуши ничего не было. Я было хотел возразить, но потом понял, что ничего не получится объяснить. Хочешь знать почему? Прочти вот это: http://www.rsdn.ru/article/nemerle/Amplifier.xml
Что же в Lisp-е такого прекрасного? Если он такой замечательный, почему его не используют все? Казалось бы, риторические вопросы, но на самом деле на них есть прямые ответы. Lisp настолько хорош не тем, что в нем есть некое волшебное качество, видимое только его приверженцам, а тем, что он — самый мощный язык программирования из существующих.
И причина того, что все вокруг пишут не на Lisp'е, заключается в том, что выбор языка программирования — вопрос не только технологии, но также и привычки, а ничто не меняется так медленно, как привычки. Конечно, оба эти тезиса требуют разъяснений.
Я начну с шокирующего утверждения: языки программирования отличаются друг от друга своей мощностью.
По крайней мере, мало кто будет спорить, что высокоуровневые языки мощнее машинного языка (машинный код и ассемблеры – VladD2). Большинство программистов согласятся, что, как правило, программировать стоит не на машинном языке, а на каком-нибудь языке высокого уровня, переводя программу в машинный код с помощью компилятора. Сейчас эта идея получила даже аппаратное воплощение — с восьмидесятых годов команды процессоров разрабатываются скорее для компиляторов, чем для программистов.
Каждый знает, что писать всю программу вручную на машинном языке — ошибочно. Но гораздо реже понимают, что существует и более общий принцип: при наличии выбора из нескольких языков ошибочно программировать на чем-то, кроме самого мощного, если на выбор не влияют другие причины (VladD2: выделено мной, мне кажется эта мысль очень важна, ведь если, например, более мощный язык не обеспечивает приемлемой производительности, то его выбор также будет неоправданным).
Все языки одинаково мощны, если рассматривать их с точки зрения эквивалентности машине Тьюринга, но это не та мощь, которая важна программисту. (Никто ведь не хотел бы программировать машину Тьюринга). Мощь языка, в которой заинтересован программист, возможно, трудно определить формальными методами, однако одно из объяснений этого понятия заключается в свойствах, которые в менее мощном языке можно получить, только написав на нем интерпретатор для более мощного языка. Если в языке A есть оператор для удаления пробелов из строк, а в языке B его нет, это не делает A более мощным, чем B, так как в B можно написать процедуру, которая делала бы это.
Но, скажем, если язык A поддерживает рекурсию, а B — нет, это нечто, что нельзя исправить написанием библиотечных функций (VladD2: впрочем, бывает так, что средствами языка B в принципе можно решить проблему, но решение ее столь сложно, что решение это можно назвать чисто теоретическим).
Есть много исключений из этого правила. Если вы пишете программу, которая должна тесно взаимодействовать с программой, написанной на определенном языке, возможно, окажется разумным писать новую программу на том же языке.
Если вы пишете программу, которая должна делать что-то очень простое, вроде численной обработки больших массивов данных или манипуляций с битами, можно использовать язык не самого высокого уровня абстракции, тем более что программа будет слегка быстрее (VladD2: и то не факт).
Если вы пишете короткую программу, которую используете один раз и выбросите прочь, возможно, следует использовать тот язык, который имеет лучшие библиотечные функции для данной задачи.
Но в целом для программного обеспечения нужно использовать самый мощный (и приемлемо эффективный) язык из всех доступных. Отличный от этого выбор — это ошибка такого же рода, как программирование в машинных кодах, хотя и с меньшими негативными последствиями.
Понятно, что уровень машинного языка очень низок. А высокоуровневые языки часто рассматриваются как одинаковые, по крайней мере, так принято считать. Но это не так. Технический термин "язык программирования высокого уровня" не обозначает ничего определенного. Не существует четкой границы между множеством "машинных" языков с одной стороны, и множеством "высокоуровневых" – с другой. Языки распределены в континууме (возможно, не просто континууме, а некой структуре, уменьшающейся кверху; важна здесь не форма, а сама идея о том, что существует, по крайней мере, частичный порядок) абстрактности, начиная от самых мощных "языков высокого уровня" вниз к "машинным языкам", которые, в свою очередь, тоже отличаются друг от друга по мощности.
Возьмем Cobol. Cobol — язык высокого уровня, так как компилируется в машинный язык. Но станет ли кто-нибудь утверждать, что по мощности Cobol эквивалентен, скажем, Python-у? (VladD2: учитывая свой опыт общения на форумах RSDN скажу, что, несомненно, станет ) Возможно, он ближе к машинному языку, чем Python.
А как насчет Perl четвертой версии? В Perl 5 в язык были добавлены лексические замыкания (lexical closures). Большинство Perl-хакеров согласятся, что Perl 5 мощнее, чем Perl 4. Но раз вы это признали, вы признали, что один высокоуровневый язык может быть мощнее другого. Из этого неизбежно следует, что использовать нужно самый мощный язык.
Впрочем, из этого утверждения редко делается вывод. Программисты старше определенного возраста редко меняют язык по своей воле. Они будут считать достаточно хорошим тот язык, к которому привыкли.
Программисты очень привязываются к своим любимым языкам, а я не хочу оскорбить ничьи чувства, поэтому я объясню свою позицию, используя гипотетический язык с названием Блаб.
Блаб попадает в середину континуума абстрактности. Это не самый мощный язык, но он мощнее, чем Cobol или машинный язык.
И на самом деле, наш гипотетический программист на Блабе не будет использовать ни Cobol, ни машинный код. Для машинных кодов есть компиляторы. Что же касается Cobol-а, наш программист не знает, как на этом языке вообще что-то можно сделать. В Cobol-е ведь даже нет возможности X, присутствующей в Блабе!
Когда наш гипотетический Блаб-программист смотрит вниз на континуум мощности языков, он знает, что смотрит вниз. Менее мощные, чем Блаб, языки явно менее мощны, так как в них нет некой особенности, к которой привык программист. Но когда он смотрит в другом направлении, вверх, он не осознает, что смотрит вверх. То, что он видит, — это просто "странные" языки. Возможно, он считает их одинаковыми с Блабом по мощности, но со всяческими сложными штучками. Блаба для нашего программиста вполне достаточно, так как он думает на Блабе (VladD2: выделено мной).
Когда мы поменяем точку обзора программиста, используя любой язык программирования выше по континууму мощности, мы обнаружим, что теперь программист смотрит на Блаб сверху вниз. «Как же можно что-то сделать, используя Блаб? В нем отсутствует даже конструкция Y!»
Используя метод индукции, приходишь к выводу, что только те программисты, которые понимают самый мощный язык, в состоянии осознать полную картину разницы в мощности между различными языками (видимо, именно это имел в виду Эрик Реймонд, когда говорил о том, что Lisp сделает вас лучше как программиста). Следуя парадоксу Блаба, нельзя доверять мнению других: другие программисты довольны тем языком, который используют, потому что этот язык определяет способ их программистского мышления.
Я понял это на собственном опыте, когда учился в старших классах школы и писал программы на Бейсике. Этот язык не поддерживал даже рекурсию. Трудно представить написание программ без рекурсии, но в то время мне это было не нужно. Я думал на Бейсике. Я был спец. Мастер всего, что изучил.
Пять языков, которые советует хакерам Эрик Реймонд, находятся в разных точках континуума мощности, и то, где они находятся относительно друг друга, — тонкий вопрос. Я скажу, что Lisp находится на вершине континуума. И чтобы поддержать это утверждение, я скажу о том, чего мне не хватает, когда я смотрю на остальные пять языков. Как же можно что-то сделать с ними, думаю я, без свойства Z? И самое большое Z — это макросы. (VladD2: Рассматривать макросы как отдельное свойство — это немного неправильно. На практике их польза увеличивается такими свойствами Lisp'а, как лексические замыкания и частичная параметризация (rest parameters) – аналогичная возможность в Nemerle назевается «частичное применение (partial application)).
Во многих языках есть что-то, называющееся макросом. Но макросы в Lisp'е уникальны (VladD2: на сегодня это так, только если глядеть на другие языки с высоты Lisp-а, но об этом позже). То, что делают макросы, имеет отношение, верите вы или нет, к скобкам. Создатели Lisp'а добавили все эти скобки в язык не для того, чтобы отличаться от других. Скобки в Lisp'е имеют особый смысл, они — внешнее свидетельство фундаментальной разницы между Lisp'ом и другими языками.
Программа на Lisp'е состоит из данных. И не в том тривиальном значении, что исходные файлы содержат символы, а строки — один из типов данных, поддерживаемых языком. После прочтения программы парсером Lisp-код состоит из готового к использованию дерева структур данных.
Дело не в том, что в Lisp'е странный синтаксис, скорее, его нет вообще. Программы пишутся в синтаксических деревьях, которые в других языках генерируются парсером во время разбора исходного текста. Эти синтаксические деревья в Lisp'е полностью доступны вашим программам, и вы можете писать программы, которые изменяют эти деревья. В Lisp'е подобные программы называются макросами. Это программы, которые пишут программы.
Программы, которые пишут программы? И когда же такое может понадобиться?
Не очень часто, если вы думаете на Cobol'е. И постоянно, если вы думаете на Lisp'е. Было бы удобно, если бы я дал пример мощного макроса и сказал бы: "Вот! Смотрите!". Но если бы я и привел пример, для того, кто не знает Lisp, он выглядел бы как белиберда. Рамки данной статьи не позволяют изложить все необходимое для понимания подобного примера. В книге Ansi Common Lisp я старался излагать материал как можно быстрее, но даже так я не добрался до макросов раньше страницы 160.
Однако мне кажется, что я могу дать убедительный аргумент. Исходный текст редактора Viaweb на 20-25 процентов состоял из макросов. Макросы сложнее писать, чем обычные функции Lisp'а, и считается дурным тоном использовать их там, где можно без них обойтись. Поэтому каждый макрос в той программе был необходим. Это значит, что примерно 20-25 процентов кода в программе делают то, что нельзя просто сделать на других языках.
Как бы скептически ни относился Блаб-программист к моим заявлениям о таинственной мощи Lisp'а, это должно его заинтересовать. Мы не писали этот код для своего собственного развлечения. Мы были маленькой компанией, и программировали так, как только могли, чтобы возвести технологический барьер между нами и нашими конкурентами.
Пытливый читатель может задаться вопросом, а нет ли здесь взаимосвязи? Некоторая большая часть кода делала нечто, что очень сложно сделать на других языках. Получившееся в результате программное обеспечение делало то, что программное обеспечение наших соперников делать не могло. Возможно, между этими фактами есть связь. Я советую вам подумать в этом направлении. Возможно, это все не просто старческие бредни.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>90% людей с которыми я работал хотели изучать новое. Но далеко не у всех было время на изчение чего-то кардинально отличающегося от существующего.
I>Вот это точно обманка.
Какая обманка? Это реальные люди, которе реально изучают новые технологии.
Если вы не работаете с такими людьми, то это только ваши проблемы.
I>>>Посему никакой супермощный язык массы эти учить не станут, а именно на эти массы ориентируются все технологии, абсолютно все. G>>Если супермощный язык сильно не похож на существующий, то может и не станут. Но это не про Nemerle
I>Похож то он похож, но по любому его надо объяснять через существубщий, при чем требуется много выше уровень для понимания, ибо макросы эти очень, очень мощные.
Фигня. Не надо все новое объяснять через существующее. Я недавно соврешенно случайно выяснил что F# гораздо проще объяснить человеку, не знакомому глубоко с .NET и языками на этой платформе, чем людям хорощо знающим C# и С++.
Также еще давно выяснил что гораздо лучше изучают новые языки и технолгии, те кто знаком с разными языками, а не являющимися специалистами в одном языке\технологии.
Все новое в программировании вводит новые абстракции, а все что существует — конкретная реализация абстракций. Если вы пытаетесь объяснить новые абстракции через существующие реализации, то ничего у вас не выйдет. Для примера попробуйте объяснить замыкания тому кто на среднем уровне знает C\C++ и только его.
I>И я считаю по старинке — чем мощнее инструмент тем сложнее его осваивать.
А вам что надо, освоение инструмента или его эффективное использование?
Второе на самом деле горадо важнее. На практике получается что чем мощнее инструмент, тем легче его использовать. А затраты на освоение мощного инструмента до той степени чтобы можно было эффективно использовать не превышают затрат на освоение менее мощных инструментов.
I>>>С мега-языками и мега-технологиями обычно так — на стартапе гуру применяет оные, а дальше, за его уходом, серые массы выбрасывают код этого гуру как только там понадобится чего доделать ну или костылями будут подпирать. G>>Когда-то также говорили о C++, в последствии о Java и C#. А некоторые и сейчас так говорят.
I>Представь, с++ нормально знает единицы. Шаблоны на С++ есть давным давно, а знают их настолько мало людей, что просто страшно.
И это не мешает им писать программы.
G>>Обычно за время своего существования на проектке гуру успевает передать часть знаний другим участникам, чтобы они тоже могли пользоваться мега-языками и мега-технологиями. G>>Если передачи знаний не происходит, то вместе с гуру работают исключительно бараны. Но это не проблемы технологии или языка.
I>Передача то происходит, но важна скорость этой передачи, а то вот с лета занялся проектом, на котором состав разрабов сменился несколько раз. Реально страшно
Если у вас за полгода несколько раз меняется состав разработчиков проекта, то вам уже ничего не поможет.
Если нам не помогут, то мы тоже никого не пощадим.
Причем, что первую что вторую тоже вполне может понадобиться разъяснять через printf, если человеку так легче.
Мы уже победили, просто это еще не так заметно...
А обоснования будут?
