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

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

Ерунда. В умелых руках .NET может "такое же" как и C++. Винду я ещё не убивал, но студия у меня склеивала ласты неоднократно Вот только не занимаясь этим умышленно сделать такое практически невозможно. Так что аналогия не верна.

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

IT>>Я 12 лет был гениальным... я устал.

Ч>Дело не в гениальности конкретного человека а в том как компилятор оценивает программиста

Компилятор программиста? Мощно задвинул

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

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

IT>>>Я 12 лет был гениальным... я устал.

Ч>>Дело не в гениальности конкретного человека а в том как компилятор оценивает программиста

IT>Компилятор программиста? Мощно задвинул

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

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

Ну дык эта...

Раньше побеждал сильнейший но потом пришел полковник Кольт и все опошлил...

Вместо "шабли вострой" предлагается для нОски в этом сезоне
скалки и подушки...

Что самое интересное — вероятность увечья не уменьшается.

Сколько уж раз говоренно было — все имеет свою цену.

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

VD>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Позволю себе вмешаться. Синтаксическую ошибку в программе VladD2 компилятор нашел, но посчитал ее предупреждением. Не обращать внимание на предупреждения не стоит ни в С++, ни в С#. Как минимум, надо на них посмотреть и решить, стоит ли игнорировать, а лучше вообще убрать.

VD>Несомненно. Но вот если уж компилятор считает сообщение не важным, то ошибка ну, никак не должна приводить к разным AV/GPF. А именно такой случай мы имеем.

Компилятор ничего не считает. Он предоставляет это на мое усмотрение. Извини за обширное цитирование

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

/Wn, /WX, /Wall, /wnn, /wdn, /wen, /won (Warning Level)
/Wn
/WX
/Wall
/wnn
/wdn
/wen
/won
These options specify how the compiler generates warnings for a given compilation.

Option
/Wn Specifies the highest level of warning generated by the compiler. Valid warning levels for n range from 0 to 4:
Level 0 disables all warnings.
Level 1 displays severe warnings.
Level 2 displays all level 1 warnings and warnings less severe than level 1. Level 2 is the default warning level at the command line.
Level 3 displays all level 2 warnings and all other warnings recommended for production purposes.
Level 4 displays all level 3 warnings plus informational warnings, which in most cases can be safely ignored. This option should be used only to provide "lint" level warnings and is not recommended as your usual warning level setting.
For a new project, it may be best to use /W4 in all compilations. This will ensure the fewest possible hard-to-find code defects.

/Wall Enables all warnings, including those disabled by default. See Compiler Warnings That Are Off By Default.
/WX Treats all warnings as errors. For a new project, it may be best to use /WX in all compilations; resolving all warnings will ensure the fewest possible hard-to-find code defects.
/wnn Specifies the level for a particular warning. The first parameter sets the warning level (same as /Wn) and the second parameter is the actual warning number.

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Так что если я хочу, я могу считать серьезным любое предупреждение и блокировать в этом случае создание .obj и .exe (/WX). Или, наоборот, игнорировать все предупреждения и брать полностью ответственность на себя (/W0). Или промежуточно. Или конкретно по тому или иному предупреждению.

Кстати, когда я в своем пректе поставил Level4, на меня высыпали штук 20 предупреждений, абсолютно несущественных. Так что я немедленно вернулся к дефолтному Level 3.

Между прочим, аналогичное было всегда. По крайней мере, в BC 3.1 нечто подобное тоже было.

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

PD>Ко всем, кто принял участие в обсуждении этого вопроса.

PD>А не кажется ли Вам, господа, что сие есть глубокая философия на мелком месте? Как известно, можно сделать весьма глубокие философские выводы даже из наблюдения скорлупы разбитого яйца. А уж из программерской ошибки... ух!

PD>P.S. Убедительно прошу тему скорлупы и яйца (а равно и курицы) далее не развивать.

Действительно, не "Философия", а обмен колкостями.

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

S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Я не буду смеяться, но вроде бы в Unix был когда-то tool , который отлавливал несоответсвия всякие в С программах еще когда С++ не было. В частности, несоответствия между описанием функции и ее вызовом (если помнишь, в версии С Кернигана-Ритчи прототипов не было, а вызывать неописанную функцию в С даже сейчас компилятор позволит, предупреждение, правда, будет. Не исключаю, что и для C++ такие тулзы либо есть, либо их можно написать. Но мне они не нужны.
S>Я тоже не исключаю возможности таких средств для C++. Хотя, конечно, писать их значительно труднее

int main()
{
    printf("%d", 1.2345);
    return 0;
}

Compiling: main.cpp
main.cpp: In function `int main()':
main.cpp:5: warning: int format, double arg (arg 2)

(с) GCC 3.4

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

E>>Может быть веб-сайт и является Типичным Современным Приложением (хотя, имхо, нужно было бы сказать, что только в одной области),
S>Просто в этой области выпускаются сотни приложений в день.

И?
Это будет Типичным Современным Приложением в области махоньких веб сайтов. Потому что крупные веб-порталы или Web-сайты крупных корпораций или торговых компаний будут разрабатываться совсем на других технологиях и совсем другими командами (хотя SQL и JavaScript, с большой вероятностью там будут присутствовать ).

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

E>>то вот "маахонький" -- это совершенно не пример. Команды в 1.5-2-3-3.25 человек -- они по своему живут, многие вещи там гораздо проще.
S>Какие вещи? Мы все еще говорим о лингвистических способностях или уже о чем?

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

Во-вторых, в маленьких командах все на виду. Очень легко получить помощь, совет, а иногда и по рукам за откровенные ляпы. Поэтому и процесс обучения новым языкам/технологиям в маленьких командах проходит быстрее и легче.

В-третьих, маленькой команде проще согласованно выбрать новый язык для конкретной задачи. Можно обсудить достоинства Python по отношению к Ruby, или Smalltalk по отношению к Python. Можно даже сесть за один компьютер и вместе поиграться в каком-нибудь Dolphin Smalltalk или RDE. И проще учесть мнение одного из членов команды. Например, если мне не нравится способ структурирования программ пробелами в Python, то это легко принять во внимание и сделать выбор в пользу Ruby. Если же в команде таких категорических мнений не одно-два, а пять-десять-пятнадцать, то выбор языка можно делать только волевым решением. Как результат -- наличие разработчиков, не довольных выбранным языком разработки.

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

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

Нет, не правильно.

Я считаю, что есть некоторый диапазон, в котором для проекта очень важно иметь минимальное количество использованных языков. Скажем, объем проекта от 200 до 500 тысяч строк и команда от 7 до 20 человек. Как раз по перечисленным мной ранее факторам (взаимозаменяемость членов команды, проблемы в интеграции разноязыковых компонент, сложность в одновременной работе на более чем 3-х языках). А уже как следствие этого -- данные проекты успешно могут решаться людьми, которые знают не более 2-х или 3-х языков. Вроде как собрать команду из 5-ти корифеев сложно, но возможно. Собрать команду из 15-ти корифеев, имхо, вообще не реально. А еще менее реально -- заставить их работать сообща

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

PS. Цифры по объемам команд/проектов взяты мной исходя из своего личного впечатления, никакой объективной статистикой не подкреплены.

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

E>И?
E>Это будет Типичным Современным Приложением в области махоньких веб сайтов. Потому что крупные веб-порталы или Web-сайты крупных корпораций или торговых компаний будут разрабатываться совсем на других технологиях и совсем другими командами (хотя SQL и JavaScript, с большой вероятностью там будут присутствовать )
А теперь давай сравним количество маленьких сайтов и крупных порталов.

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

E>В-третьих, маленькой команде проще согласованно выбрать новый язык для конкретной задачи.
Это уже никак не относится к способностям самих программистов.
E>В-четвертых, сама разработка в небольшой команде проще, чем в большой. Просто из-за отсутствия политики и лишних накладных расходов на общение.
Как и это.
E>Я считаю, что есть некоторый диапазон, в котором для проекта очень важно иметь минимальное количество использованных языков. Скажем, объем проекта от 200 до 500 тысяч строк и команда от 7 до 20 человек. Как раз по перечисленным мной ранее факторам (взаимозаменяемость членов команды, проблемы в интеграции разноязыковых компонент, сложность в одновременной работе на более чем 3-х языках).
Нет, погоди. Ты аргументируешь сложность работы на более чем трех языках наличием команд, сформированных под воздействием сложности работы на более чем трех языках.
E>А уже как следствие этого -- данные проекты успешно могут решаться людьми, которые знают не более 2-х или 3-х языков. Вроде как собрать команду из 5-ти корифеев сложно, но возможно. Собрать команду из 15-ти корифеев, имхо, вообще не реально. А еще менее реально -- заставить их работать сообща

Итак, мы имеем тысячи команд из двух-трех корифеев, и десятки команд из десятков, скажем так, не-корифеев.

E>Если проект больше то, имхо, он состоит из почти самостоятельных частей и команд, попадающих в указанный диапазон. И для каждого из таких продпроектов действуют те же самые правила.
А, ну то есть на самом деле у нас большой проект (в котором программеры патологически неспособны думать на трех языках) делится на маленькие команды, в которых программеры вполне способны думать на трех языках. Забавно.

E>PS. Цифры по объемам команд/проектов взяты мной исходя из своего личного впечатления, никакой объективной статистикой не подкреплены.

Ты вообще много знаешь команд с численностью в 20 человек? Да их во всем мире не так уж много. Практика показывает, что 2 языка осваивают чуть не 90% современных программеров. И не осваивают третий только потому, что не успевают. К тридцати годам избежать освоения трех языков можно только при помощи строгого поста, воздержания, и ежедневной молитвы. Такая уж у нас отрасль.

Оценить масштабы катастрофы можно исходя из здравого смысла. Найди мне хоть одного SQL девелопера, который не владеет еще одним языком. А всего SQL девелоперов — миллионы.

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

E>>И?
E>>Это будет Типичным Современным Приложением в области махоньких веб сайтов. Потому что крупные веб-порталы или Web-сайты крупных корпораций или торговых компаний будут разрабатываться совсем на других технологиях и совсем другими командами (хотя SQL и JavaScript, с большой вероятностью там будут присутствовать )
S>А теперь давай сравним количество маленьких сайтов и крупных порталов.

По количеству? Качеству? Стоимости? Прибыльности?

E>>А ведь есть еще и другие направления. Системный и околосистемный софт, офисные пакеты,
S>Системного и околосистемного софта пишется бесконечно мало.

Миллионы строк ядер операционных систем, серверов приложений, СУБД, веб-серверов, компиляторов и пр. тебе кажется бесконечно малой величиной?

E>>корпоративные информационные системы,
S>КИС тоже пишутся как минимум на двух языках; чаще — больше.
E>>встраиваемые системы, игры для различных платформ,
S>Даже игры применяют не менее двух языков — язык платформы (С/С++) и язык игровых скриптов. Плюс еще и местами ассемблер.
E>>телекоммуникации, оборонка, научные расчеты, и пр. и пр.
S>Телекоммуникаций, оборонки и научных расчетов пишется бесконечно мало.

Мне кажется, ты слишком увлечен веб-разработкой.

E>>И если они успешно справляются со своими проектами то, вероятно, эти способности повыше среднестатистических.
S>То есть ты хочешь сказать, что редкие, как золото, крупные команды по разработке масштабного софта дают основной вклад в эту среднюю статистику? Очень она у тебя странная, эта средняя статистика.

Под крупными командами ты что понимаешь? Команда в 10 разработчиков -- это редкость? А в 20-ть?
Извини меня, но над какими проектами ты работаешь?

Между тем команда из 10-ти человек уже в 5-ть раз больше команды из 2-х человек.

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

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

E>>Во-вторых, в маленьких командах все на виду. Очень легко получить помощь, совет, а иногда и по рукам за откровенные ляпы. Поэтому и процесс обучения новым языкам/технологиям в маленьких командах проходит быстрее и легче.

E>>В-третьих, маленькой команде проще согласованно выбрать новый язык для конкретной задачи.
S>Это уже никак не относится к способностям самих программистов.
E>>В-четвертых, сама разработка в небольшой команде проще, чем в большой. Просто из-за отсутствия политики и лишних накладных расходов на общение.
S>Как и это.

Тем не менее, это серьезно влияет на выбор языков для разработки ПО.

E>>Я считаю, что есть некоторый диапазон, в котором для проекта очень важно иметь минимальное количество использованных языков. Скажем, объем проекта от 200 до 500 тысяч строк и команда от 7 до 20 человек. Как раз по перечисленным мной ранее факторам (взаимозаменяемость членов команды, проблемы в интеграции разноязыковых компонент, сложность в одновременной работе на более чем 3-х языках).
S>Нет, погоди. Ты аргументируешь сложность работы на более чем трех языках наличием команд, сформированных под воздействием сложности работы на более чем трех языках.

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

E>>А уже как следствие этого -- данные проекты успешно могут решаться людьми, которые знают не более 2-х или 3-х языков. Вроде как собрать команду из 5-ти корифеев сложно, но возможно. Собрать команду из 15-ти корифеев, имхо, вообще не реально. А еще менее реально -- заставить их работать сообща

S>Итак, мы имеем тысячи команд из двух-трех корифеев, и десятки команд из десятков, скажем так, не-корифеев.

На счет тысяч команда из двух-трех корифеев -- это, наверное, есть только в мировом масштабе считать.
А то, что существуют сотни и тысячи команд, в которых большинство разработчиков обладают хорошим средним уровнем, но не Линусы, Столманы, не Грослинги, не Хайсельберги -- это факт. Даже в рамках СНГ.

E>>Если проект больше то, имхо, он состоит из почти самостоятельных частей и команд, попадающих в указанный диапазон. И для каждого из таких продпроектов действуют те же самые правила.
S>А, ну то есть на самом деле у нас большой проект (в котором программеры патологически неспособны думать на трех языках) делится на маленькие команды, в которых программеры вполне способны думать на трех языках. Забавно.

Ты не язви. Скажи с чем ты не согласен.

E>>PS. Цифры по объемам команд/проектов взяты мной исходя из своего личного впечатления, никакой объективной статистикой не подкреплены.

S>Ты вообще много знаешь команд с численностью в 20 человек?

У нас сейчас ~20 человек. Разбитые на подпроекты, но все подпроекты очень тесно переплетаются.
В нашем городе есть представительства крупных офшорных контор. Там гораздо больше народу работает.
Есть наши партнеры (друзья-соперники ), в Питере и в Магнитогорске, там вообще разработчиков сотни, а работают над линейками однотипных продуктов (банковский процессинг).

S> Да их во всем мире не так уж много. Практика показывает, что 2 языка осваивают чуть не 90% современных программеров. И не осваивают третий только потому, что не успевают. К тридцати годам избежать освоения трех языков можно только при помощи строгого поста, воздержания, и ежедневной молитвы. Такая уж у нас отрасль.

Я говорил не про возможность освоить, а возможность одновременно и эффективно программировать на более чем двух-трех языках (давай SQL сюда не включать, это не универсальный язык). Я вот и на Паскале когда-то программировал, и на С, и на Java программировал, а уж изучал много чего, только программировать не довелось. А реально сейчас я могу написать программу или на C++, или на Ruby. Вот так, с ходу, без остановок. А для всего остального нужно паузу брать, восстанавливать знания, или вообще заново учиться. Вот возьму, вспомню еще и Java. Но писать одновременно фрагменты на C++, на Ruby и на Java, имхо, будет не просто. И по крайней мере от одного языка я постараюсь поскорее избавиться.

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

E>Под крупными командами ты что понимаешь? Команда в 10 разработчиков -- это редкость? А в 20-ть?
Конечно редкость. Особенно если не считать туда же тестеров/дизайнеров/админов. Потому как им ЯП не нужны.
E>Извини меня, но над какими проектами ты работаешь?
Не имеет значения.
E>Интересная точка зрения. Может ты меня слишком буквально понимаешь?
E>Моя точка зрения в том, что объективно есть условия, когда более 3-х или 4-х языков применять сложно и опасно.
Разве? А несколько постов назад ты написал буквально следующее:

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

Вот я и не могу понять, откуда взялось такое убеждение. Это противоречит моему опыту. Я, напротив, утверждаю, что:
Большинство программистов могут эффективно работать на нескольких языках/платформах одновременно.

E>На счет тысяч команда из двух-трех корифеев -- это, наверное, есть только в мировом масштабе считать.
E>А то, что существуют сотни и тысячи команд, в которых большинство разработчиков обладают хорошим средним уровнем, но не Линусы, Столманы, не Грослинги, не Хайсельберги -- это факт. Даже в рамках СНГ.
Ага. И этого среднего уровня почему-то хватает с избытком на освоение двух-трех языков.

E>Ты не язви. Скажи с чем ты не согласен.
Я тебе уже пять постингов объясняю: я не согласен с тем, что эффективно писать на двух-трех языках — что-то сверхъестественное. Ничего в этом такого нет.


S>>Ты вообще много знаешь команд с численностью в 20 человек?
E>У нас сейчас ~20 человек. Разбитые на подпроекты, но все подпроекты очень тесно переплетаются.
E>В нашем городе есть представительства крупных офшорных контор. Там гораздо больше народу работает.
Не надо путать численность конторы и размер команды. В Новософте работало около 500 человек; при этом они были разбиты на команды типичной численностью около пяти человек. И состоящие из более-менее универсалов типа Java+SQL+HTML.
E>Есть наши партнеры (друзья-соперники ), в Питере и в Магнитогорске, там вообще разработчиков сотни, а работают над линейками однотипных продуктов (банковский процессинг).
Ок. Сколько этих партнеров? (Поверим на минуту, что у них действительно работают команды в несколько сот девелоперов, и все узкоспециализированные). А микрокоманд, где народу меньше 5, только у нас в районе под сотню наберется.

E>Я говорил не про возможность освоить, а возможность одновременно и эффективно программировать на более чем двух-трех языках (давай SQL сюда не включать, это не универсальный язык).
А какие языки ты собрался включать тогда? Нет, если вот так произвольно из рассмотрения выкидывать — то да, конечно. Там и одного языка на разработчика не наберется.
E>Я вот и на Паскале когда-то программировал, и на С, и на Java программировал, а уж изучал много чего, только программировать не довелось. А реально сейчас я могу написать программу или на C++, или на Ruby. Вот так, с ходу, без остановок.
Это от того, что тренировки мало.
E>А для всего остального нужно паузу брать, восстанавливать знания, или вообще заново учиться. Вот возьму, вспомню еще и Java. Но писать одновременно фрагменты на C++, на Ruby и на Java, имхо, будет не просто.
Это тебе кажется. Мне вот в свое время тяжко было печатать латиницей/кириллицей. Паузу надо было брать, переучиваться.
А в девятом/десятом классе я свободно тайпал и s QWERTY, и в ЙЦУКЕН, и в ужасной транскрипционной раскладке ямахи. Чуть-чуть ежедневной практики — и voila!
E>И по крайней мере от одного языка я постараюсь поскорее избавиться.

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

E>>Моя точка зрения в том, что объективно есть условия, когда более 3-х или 4-х языков применять сложно и опасно.
S>Разве? А несколько постов назад ты написал буквально следующее:
S>

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

S>Вот я и не могу понять, откуда взялось такое убеждение. Это противоречит моему опыту. Я, напротив, утверждаю, что:
S>Большинство программистов могут эффективно работать на нескольких языках/платформах одновременно.

Ok. Эта твоя вера. Не буду тебя разубеждать. Мне это не к чему, тебе, видимо, так же.

E>>Ты не язви. Скажи с чем ты не согласен.
S>Я тебе уже пять постингов объясняю: я не согласен с тем, что эффективно писать на двух-трех языках — что-то сверхъестественное. Ничего в этом такого нет.

Ok. Пусть у тебя будет так. Мне же не просто с C++ на Ruby переключаться, старею, наверное.

S>Не надо путать численность конторы и размер команды. В Новософте работало около 500 человек; при этом они были разбиты на команды типичной численностью около пяти человек. И состоящие из более-менее универсалов типа Java+SQL+HTML.

Java+SQL+HTML -- это универсализм? По мне, как это специализация.

E>>Я говорил не про возможность освоить, а возможность одновременно и эффективно программировать на более чем двух-трех языках (давай SQL сюда не включать, это не универсальный язык).
S>А какие языки ты собрался включать тогда?

С++
C#
Delphi
Java
Perl
Python
Ruby
VB

Универсальные языки программирования, на которых можно создавать standalone приложения. Хоть текстовые редакторы. Хоть САПР. Хоть архиваторы. Хоть компиляторы.

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

FR>

FR>int main()
FR>{
FR>    printf("%d", 1.2345);
FR>    return 0;
FR>}
FR>

FR>

FR>Compiling: main.cpp
FR>main.cpp: In function `int main()':
FR>main.cpp:5: warning: int format, double arg (arg 2)

FR>(с) GCC 3.4

VC новый тоже проверяет. Но вот уже CString::Format нет.

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

IT>Я 12 лет был гениальным... я устал.

Та же фгиня, но я сдался на 10-ом году.

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

Ч>Дело не в гениальности конкретного человека а в том как компилятор оценивает программиста

Это... где такую траву дают?

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


VD>VC новый тоже проверяет. Но вот уже CString::Format нет.

2005 beta ?

Может просто такой объемное на сегодня слово "программист" разделить на подклассы ?

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

P.S. с HTML сталкиваюсь очень редко ... хоть и бывает

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

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

IT>>Я 12 лет был гениальным... я устал.

VD>Та же фгиня, но я сдался на 10-ом году.
Везука, а я за 13 лет так и не поумнел. Пишу на том, за что платят.

С уважением, Gleb.
ЗЫ. единственное исключение VB4. Двух дней жесткого мазохизма хватило.

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

VD>VC новый тоже проверяет. Но вот уже CString::Format нет.

Да Вы что, господа, совсем уже до ручки дошли, что ли ? Или трудно понять, что форматная строка не обязательно константная!

char* pszFormat = "%d\n";
CString str;
str.Format(pszFormat, 123);

А теперь представьте себе. что эта pszFormat в рантайме вычисляется. Какую, к богу, Вы тут диагностику компилятора хотите ? Если он иногда проверяет — спасибо ему. А в общем случае нельзя здесь ничего проверить в compile-time. Ни на С++, ни на C#.

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

VD>>Та же фгиня, но я сдался на 10-ом году.
GZ>Везука, а я за 13 лет так и не поумнел. Пишу на том, за что платят.

А что за программирование не на С++ уже не платят? Или платят меньше?