Как технарю из России стать программером в США за 150К

[RobinF]

Так в С++ тоже все работает...а то что другой memory manager может существенно повысить производительность это еще надо доказать.
Такой memory manager в JVM просто сглаживает падение производительности вызванное GC, и ни каких приимуществ по сравнению с С++ не дает.

С каким утверждением вы не согласны (предполагается комманда/один программист одинакового уровня)
1. Рабочее место кассира написанное на Яве будет иметь меньше проблем с утечками памяти, падениями по page fault и т.д.
2. Разработка на Яве займет меньше времени.

Зависит от уровня программиста. У нормального и C++ не будет иметь "проблем с утечками памяти, падениями по page fault и т.д.", и разработка будет быстрее за счет использования более мощных фич языка которых нет в Java. А у того кто не может написать код C++ без "проблем с утечками памяти, падениями по page fault и т.д." и программа на жабе будет иметь кучу проблем типа NullPointerException'ов (возникающих ровно там же где page fault), тормозов, дедлоков, утечек хендлов файлов, сокетов и просто багов в функциональности. Раз уж ему мозгов не хватило на элементарщину типа смарт-пойнтеров.

3. С точки зрения пользователя это приложение не будет работать медленнее. Может даже и быстрее будет казаться.

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

[crypto5]

Так в С++ тоже все работает...а то что другой memory manager может существенно повысить производительность это еще надо доказать.
Такой memory manager в JVM просто сглаживает падение производительности вызванное GC, и ни каких приимуществ по сравнению с С++ не дает.

С каким утверждением вы не согласны (предполагается комманда/один программист одинакового уровня)
1. Рабочее место кассира написанное на Яве будет иметь меньше проблем с утечками памяти, падениями по page fault и т.д.
2. Разработка на Яве займет меньше времени.

Зависит от уровня программиста. У нормального и C++ не будет иметь "проблем с утечками памяти, падениями по page fault и т.д.", и разработка будет быстрее. А у того кто не может написать код C++ без "проблем с утечками памяти, падениями по page fault и т.д." и программа на жабе будет иметь кучу проблем типа тормозов, дедлоков, утечек хендлов файлов, сокетов и просто багов в функциональности. Раз уж ему мозгов не хватило на элементарщину типа смарт-пойнтеров.

Тока когда появляутся смартпоинтеры может куда то дется производительность:
http://flyingfrogblog.blogspot.com/2011 ... -than.html

3. С точки зрения пользователя это приложение не будет работать медленнее. Может даже и быстрее будет казаться.

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

Замеряли?

[RobinF]

С++ конечно так себе но... If anything, язык его заменяющий должен быть в 10 раз сложнее в освоении, чтоб тест на знание языка сразу отсеивал "программистов". С++ отсеивает только 80% таковых.

C++0x решит наши проблемы

Да, лямбды - шаг в верном направлении.

[RobinF]

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

Замеряли?

Замеряли.

А про батарейку...

When asked about Android’s weak battery life at the Google Zeitgeist forum, Google co-founder Larry Page said that if anyone is not getting a full day’s worth of battery, there’s “something wrong.” Page then went on to suggest it’s probably user habits and third-party apps causing battery woes. “When there is software running in the background, that just sort of exhausts the battery quickly,” said Page.

В 2.3 наконец сделали JIT - только iOS приложения все равно то же самое делают в разы быстрее. И процессор может спокойно поспать.
Поэтому браузер (как и остальные большие части) в Android на C++ написан - на жабном браузере юзеры б не много набраузили.

[crypto5]

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

Замеряли?

Замеряли.

А про батарейку...

When asked about Android’s weak battery life at the Google Zeitgeist forum, Google co-founder Larry Page said that if anyone is not getting a full day’s worth of battery, there’s “something wrong.” Page then went on to suggest it’s probably user habits and third-party apps causing battery woes. “When there is software running in the background, that just sort of exhausts the battery quickly,” said Page.

В 2.3 наконец сделали JIT - только iOS приложения все равно то же самое делают в разы быстрее. И процессор может спокойно поспать.
Поэтому браузер (как и остальные большие части) в Android на C++ написан - на жабном браузере юзеры б не много набраузили.

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

[mr. Hide]

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

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

[crypto5]

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

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

Но это же не повод аргументировать гипотетические тормоза серверного кода проблемами мобил?

[mr. Hide]

В 2.3 наконец сделали JIT - только iOS приложения все равно то же самое делают в разы быстрее. И процессор может спокойно поспать.

Мне расскажите. Целый день в кроссплатформенном добре. Что там быстрее в разы?

[mr. Hide]

Но это же не повод аргументировать гипотетические тормоза серверного кода проблемами мобил?

Да, ваш серверный performance зависит от куда большего количества факторов, чем Решето Эрастофена.

[nightmare2]

Зато C# могут выучить все, а C++ только особо одаренные.

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

Понанимают таких - после чего кода становится в 10 раз больше чем нужно по цене 5x (потому что такие "программисты" делают кучу copy-and-paste и применяют кучу ненужных паттернов), с в 10 раз большим количеством багов и в 10 раз более дорогим сопровождением, не говоря уж про скорость и память...

С++ конечно так себе но... If anything, язык его заменяющий должен быть в 10 раз сложнее в освоении, чтоб тест на знание языка сразу отсеивал "программистов". С++ отсеивает только 80% таковых.

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

[Abappy]

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

хорошо Вам ... два часа ... да ещё и на кандидата на программерскую позицию ... мне бы так .

А конструктор из конструктора теоретически бывает и разумно вызывать (если второй конструктор принадлежит родителю)

[ddv]

А конструктор из конструктора теоретически бывает и разумно вызывать (если второй конструктор принадлежит родителю)

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

[Abappy]

А конструктор из конструктора теоретически бывает и разумно вызывать (если второй конструктор принадлежит родителю)

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

, а зачем ? (в смысле какое именно расположение звёзд может заставить держать нужную функциональность именно в конструкторе ? )

[ddv]

, а зачем ? (в смысле какое именно расположение звёзд может заставить держать нужную функциональность именно в конструкторе ? )

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

[nightmare2]

, а зачем ? (в смысле какое именно расположение звёзд может заставить держать нужную функциональность именно в конструкторе ? )

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

На шарпе так можно сделать.

Code: Select all

	class Program
	{
		static void Main(string[] args)
		{
			Test t1 = new Test(10, 20); // ABC
			t1.Print();
			Console.WriteLine(); 

			Test t2 = new Test(10, 20, 30); // ABCD
			t2.Print();

			Console.Read();
		}
	}

	class Test
	{
		public int x, y;

		private Test()
		{
			Console.Write("A");
		}

		private Test(int x) : this()
		{
			this.x = x;
			Console.Write("B");
		}

		public Test(int x, int y) : this(x)
		{
			this.y = y;
			Console.Write("C");
		}

		public Test(int x, int y, int z) : this(x*z, y*z)
		{
			Console.Write("D");
		}

		public void Print()
		{
			Console.Write(": x={0}, y={1}", x, y);
		}
 	}

Кстати, непонимание базовых концепций ООП весьма часто встречается.

[RobinF]

Зато C# могут выучить все, а C++ только особо одаренные.

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

Понанимают таких - после чего кода становится в 10 раз больше чем нужно по цене 5x (потому что такие "программисты" делают кучу copy-and-paste и применяют кучу ненужных паттернов), с в 10 раз большим количеством багов и в 10 раз более дорогим сопровождением, не говоря уж про скорость и память...

С++ конечно так себе но... If anything, язык его заменяющий должен быть в 10 раз сложнее в освоении, чтоб тест на знание языка сразу отсеивал "программистов". С++ отсеивает только 80% таковых.

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

Мне чего - повторить все написанное? Как Ваш "Гарбич коллектор" починит мозг "программистов" проводящий к сотням других ошибок помимо утечек памяти? И неспособность разобраться с пойнтерами - это не "так себе", это отсутсвие базовой квалификации АКА полная некомпетентность - в топку сразу.
Скупой платит дважды.

[Zombie416]

Аналогичного отимизатора у Java/C# просто не может быть.

Не полностью аналогичный, естессно, но сравнимый по производительности есть. C++/CLR тоже .NET, MSVC в молодости сначала генерил intermediate language ака PCode, который уже на финальном этапе превращался в машинный код.

У C# оптимизатор пока что довольно чахлый в сравнении с C++, именно на этапе преобразования source code->CLI, это да, и очень заметно сравнивая C++/CLR vs C#.

Перепишите это на Java или C# с использованием ArrayList... Код и цифры в студию.

Код и цифры выше по тексту. Как показали оные цифры, беглое изучение матчасти и соответствующих managed библиотек дает ускорение программы на C# приблизительно в 2000 раз

Естессно не надо сравнивать ArrayList и std::vector, а вот C#-овский List<T> и std::vector выдадут близкий результат если Edge - это struct. Ну и в конце концов на C# только лень и отсутствие надобности мешает провалиться до уровня C, и написать собственный malloc, разделяющий память, и жить в мире указателей.

Тест №2...

class -> struct, и никаких трех миллионов аллокаций не будет. На Java все это, вероятно, не так т.к. язык попроще. Ну дык она и постарше.

Было бы, короче говоря, желание, а сделать производительность managed кода сравнимой с native вполно можно, особенно в случае C#/.NET.

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

[Zombie416]

Как Ваш "Гарбич коллектор" починит мозг "программистов" проводящий к сотням других ошибок помимо утечек памяти? И неспособность разобраться с пойнтерами - это не "так себе", это отсутсвие базовой квалификации АКА полная некомпетентность - в топку сразу.Скупой платит дважды.

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

Managed code и "Гарбич коллектор" в частности позволяет работать в команде с, как минимум, одним некомпетентным товарищем и даже звать им написанные-исправленные библиотеки, без риска получить memory overrun / double free / etc. с вытекающими оттуда проблемами с отладкой и безопасностью в собственном коде. Ну и memory leaks тоже пропадают частично (зато resource leaks в полный рост).

[nightmare2]

Зато C# могут выучить все, а C++ только особо одаренные.

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

Понанимают таких - после чего кода становится в 10 раз больше чем нужно по цене 5x (потому что такие "программисты" делают кучу copy-and-paste и применяют кучу ненужных паттернов), с в 10 раз большим количеством багов и в 10 раз более дорогим сопровождением, не говоря уж про скорость и память...

С++ конечно так себе но... If anything, язык его заменяющий должен быть в 10 раз сложнее в освоении, чтоб тест на знание языка сразу отсеивал "программистов". С++ отсеивает только 80% таковых.

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

Мне чего - повторить все написанное? Как Ваш "Гарбич коллектор" починит мозг "программистов" проводящий к сотням других ошибок помимо утечек памяти? И неспособность разобраться с пойнтерами - это не "так себе", это отсутсвие базовой квалификации АКА полная некомпетентность - в топку сразу.
Скупой платит дважды.

Разобраться с указателями и эффективно (с умом) их использовать - это две большие разницы.
К тому же указатель совершенно не являеся необходимым в разработке приложений для бизнеса (рабочее место кассира).
В этой работе более важны другие способности.
И я не согласен, что сознательный отказ от работы с указателыми означает некомпетентност программиста.
И потом, как прикажете тестировать на знание указателей ASP.NET программиста, если он никогда не работал к C++?
Или брать только тех, кто якобы знает C++?
Тогда ко мне придут, в основном, одни неудавшиеся C++ ки.
От них точно только вред будет.

[Zombie416]

И потом, как прикажете тестировать на знание указателей ASP.NET программиста, если он никогда не работал к C++?

Может продемонстрировать навыки на C. Если не знает вообще ни C++, ни C, то с пребольшой вероятностью и ASP.NET код будет такой что живые позавидуют мертвым.

А так да, в "glue" приложениях, которые в основном склеивают системные-вебсервисные-базы-GUI примитивы в нечто удобоваримое никаких указателей не надо, и преобширнейшая некогда область виндомордописания на C++/MFC/ATL/WTL потихоньку убралась на задворки. Для подобных задач часто не то что C#/Java, какого-нибудь питона-пхп и прочего бейсика за глаза хватит.

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

[Abappy]

И потом, как прикажете тестировать на знание указателей ASP.NET программиста, если он никогда не работал к C++?

или альтернативный вопрос - как оценивать качество архитектора бизнес приложений если он никогда не работал с С#

[nightmare2]

Как Ваш "Гарбич коллектор" починит мозг "программистов" проводящий к сотням других ошибок помимо утечек памяти? И неспособность разобраться с пойнтерами - это не "так себе", это отсутсвие базовой квалификации АКА полная некомпетентность - в топку сразу.Скупой платит дважды.

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

Managed code и "Гарбич коллектор" в частности позволяет работать в команде с, как минимум, одним некомпетентным товарищем и даже звать им написанные-исправленные библиотеки, без риска получить memory overrun / double free / etc. с вытекающими оттуда проблемами с отладкой и безопасностью в собственном коде. Ну и memory leaks тоже пропадают частично (зато resource leaks в полный рост).

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

[nightmare2]

И потом, как прикажете тестировать на знание указателей ASP.NET программиста, если он никогда не работал к C++?

Может продемонстрировать навыки на C. Если не знает вообще ни C++, ни C, то с пребольшой вероятностью и ASP.NET код будет такой что живые позавидуют мертвым...

Для меня - это не очевидно.
Хотя конечно изучение такого монстра ка C/C++ должно хорошо прочищать мозги.
Но отвргать, программиста, только потому что он не знает C++ я бы не стал.

[nightmare2]

И потом, как прикажете тестировать на знание указателей ASP.NET программиста, если он никогда не работал к C++?

или альтернативный вопрос - как оценивать качество архитектора бизнес приложений если он никогда не работал с С#

У меня нет такого опыта.
Я даже не уверен, что понимаю кто это.

Вероятно подойдет знание любого обектного языка программирования (C++/Java/VB.NET/Pascal) и UML
Ну и конечно нужны аналитические способности.
Умение мыслить категориями бизнеса, умение просто объяснять сложные вещи ну и т.д.

Знание указателей - не требуется.

[Abappy]

Знание указателей - не требуется.

требуется знание об их существовании в природе