Вопрос, которй меня волнует уже года 3, а внятного ответа еще не находил или хотя бы аргументов )
Итак С++ — мощная низкоуровневая пушка с кучей возможностей, на этом звере написано почти все крутое и самое сложное )
Код на С++ быстрее и эффективнее остальных, "С++ дает программисту свободу выбора, даже если это даст ему возможность выбирать неправильно."(Вики)
В общем требует четкого понимания что ты делаешь
к примеру:
ты должен знать почему второй вариант быстрее первого
1)void printArray(vector<int>)
2)void printArray(const vector<int>&)
ты должен знать что быстрее for(...;++iterator или iterator ++)
ты должен понимать почему в цикле нельзя определять переменные, а должен их выносить на уровень выше
и еще кучи всяких особенностей
+ контроль использования памяти
в твоих руках мощный механизм, которым нужно управлять только с умом
.. и в связи с этим обучение С++ программиста стоит дороже и есть сложнее, тогда
почему же на фоне .NET/Java у С++ ниже зп ??? ну где справедливость )
Маленькая статистика — но все же она везде практические в таком порядке,
с++ девелоперы стоят на одной линии с php кодерами
F>Маленькая статистика — но все же она везде практические в таком порядке, F>с++ девелоперы стоят на одной линии с php кодерами
Важна не ценность С++ девелопера самого по себе, а то, за сколько продается софт, который он производит. Если на Java создаются решения, которые продаются за большие деньги, то и стоимость программистов будет повыше.
Здравствуйте, fromegg, Вы писали:
F>Вопрос, которй меня волнует уже года 3, а внятного ответа еще не находил или хотя бы аргументов ) F>Итак С++ — мощная низкоуровневая пушка с кучей возможностей, на этом звере написано почти все крутое и самое сложное ) F>Код на С++ быстрее и эффективнее остальных, "С++ дает программисту свободу выбора, даже если это даст ему возможность выбирать неправильно."(Вики)
Всё это абсолютно нерелевантно стоимости работы программиста. Работодателю не важно, насколько крут инструмент, его интересует результат.
Каков процент проектов (или даже — какова их доля рынка), где мощь и крутотень С++ необходимы?
F>Маленькая статистика — но все же она везде практические в таком порядке, F>с++ девелоперы стоят на одной линии с php кодерами
"Невидимая рука рынка" (с)
Не претендую на истину, лишь выскажу предположение: многое из того, что раньше писалось на С++ стали писать на других языках =>
спрос на программистов С++ упал, а на программистов на этих "других языка" вырос.
F>ты должен знать почему второй вариант быстрее первого F>1)void printArray(vector<int>) F>2)void printArray(const vector<int>&)
F>ты должен знать что быстрее for(...;++iterator или iterator ++)
Мой фейспалм Вы наткнулись на список заблуждений про С++ ?
....
F>почему же на фоне .NET/Java у С++ ниже зп ??? ну где справедливость )
1. Нет справедливости , это из сказок. Или справедливость есть , но она другая.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Здравствуйте, fromegg, Вы писали:
F>>Маленькая статистика — но все же она везде практические в таком порядке, F>>с++ девелоперы стоят на одной линии с php кодерами
_O_>Важна не ценность С++ девелопера самого по себе, а то, за сколько продается софт, который он производит. Если на Java создаются решения, которые продаются за большие деньги, то и стоимость программистов будет повыше.
в голове только один образ
преподаватель в вузе:
Ребята мы не будем учить с++ и использовать следующие 4 семестра, зачем ломать себе мозг и платят то этим специалистам меньше чем другим,
осваивать будем к примеру питон и за 1 семестр, он прекрасен удобен и всемогущ
Дело вот в чем: крутизна языка С++ нужна в двух-трех процентах проектов.
И в этих проектах С++ только часть, притом не самая важная — рулит знание предметной области.
Другими словами, мощь языка нужна только для по настоящему нетривиальных программ.
Кто всё это освоил, получает от 150 тысяч.
Те — же, кто прочитал две книжки и думает все, обламывается.
Это не Java, где основная сложность в изучении туевой хучи фреймворков.
Здравствуйте, fromegg, Вы писали:
F>ты должен знать почему второй вариант быстрее первого F>1)void printArray(vector<int>) F>2)void printArray(const vector<int>&)
Просто из интереса, сколько раз надо обратиться к каждому элементу массива int, чтобы копирование стало дешевле косвенных обращений? Раз пять.
#include <tchar.h>
#include <windows.h>
#include <iostream>
#include <vector>
template<typename T>
int f(int count, T v)
{
int acc(0);
for (size_t i(0), size(v.size()); i != size; ++i)
for (int j(0); j != count; ++j)
acc ^= v[i];
return acc;
}
template<typename T>
LONGLONG time_f(size_t count)
{
std::vector<int> v(10000);
LARGE_INTEGER start, finish;
::QueryPerformanceCounter(&start);
f<T>(count, v);
::QueryPerformanceCounter(&finish);
return finish.QuadPart - start.QuadPart;
}
int _tmain(int argc, _TCHAR* argv[])
{
for (int i(0); i != 16; ++i)
{
int iterCount(100);
LONGLONG a(0), b(0);
for (int j(0); j != iterCount; ++j)
{
a += time_f<std::vector<int> >(i);
b += time_f<const std::vector<int> &>(i);
}
std::cout << i << ' ' << a/iterCount << ' ' << b/iterCount << '\n';
}
return 0;
}
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, fromegg, Вы писали:
F>>ты должен знать почему второй вариант быстрее первого F>>1)void printArray(vector<int>) F>>2)void printArray(const vector<int>&)
DR>Просто из интереса, сколько раз надо обратиться к каждому элементу массива int, чтобы копирование стало дешевле косвенных обращений? Раз пять.
DR>
DR>
DR>int _tmain(int argc, _TCHAR* argv[])
DR>{
DR> for (int i(0); i != 16; ++i)
DR> {
DR> int iterCount(100);
DR> LONGLONG a(0), b(0);
DR> for (int j(0); j != iterCount; ++j)
DR> {
DR> a += time_f<std::vector<int> >(i);
DR> b += time_f<const std::vector<int> &>(i);
DR> }
DR> std::cout << i << ' ' << a/*/iterCount*/ << ' ' << b/*/iterCount*/ << '\n';
DR> }
DR> return 0;
DR>}
DR>
Что я делаю не так, кроме того что a и b не делю на iterCount?
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, samius, Вы писали:
S>>Что я делаю не так, кроме того что a и b не делю на iterCount?
DR>Видимо, используешь более умный компилятор. Можно попробовать сделать acc глобальным или инициализировать v ненулевыми значениями.
да, с глобальным acc стало лучше
Еще изменил основной цикл в main
Здравствуйте, fromegg, Вы писали:
F>Вопрос, которй меня волнует уже года 3, а внятного ответа еще не находил или хотя бы аргументов ) F>Итак С++ — мощная низкоуровневая пушка с кучей возможностей, на этом звере написано почти все крутое и самое сложное )
это утверждение "россия — родина слонов". далеко не все крутое и сложное пишется на плюсах.
F>Код на С++ быстрее и эффективнее остальных, "С++ дает программисту свободу выбора, F>даже если это даст ему возможность выбирать неправильно."(Вики)
быстрота и эффективность кода нужна далеко не везде. скорость написания кода зачастую намного важнее. а свободу программиста работодатели предпочитают ограничивать.
F>В общем требует четкого понимания что ты делаешь
в общем случае так происходит всегда.
вы не поверите, но четкое понимание необходимо даже для работы с питоном.
например,
a = [-1,0,1];
c = a;
del c[1];
print a
печатает:
-1, 1
а вот:
a = [-1,0,1];
c = a[:];
del c[1];
print a
печатает:
-1, 0, 1
и без учета этой фичи (о которой не в каждом букваре, кстати, написано) можно получить очень неожиданный эффект, угробив чужие данные.
F> ты должен понимать почему в цикле нельзя определять переменные, а должен их выносить на уровень выше F> и еще кучи всяких особенностей
используйте профилировщик или смотрите в сгенерированный компилятором ассемблерный код.
F>в твоих руках мощный механизм, которым нужно управлять только с умом F>.. и в связи с этим обучение С++ программиста стоит дороже и есть сложнее, тогда F>почему же на фоне .NET/Java у С++ ниже зп ??? ну где справедливость )
наверное потому, что пытаются управлять этим сложным инструментом без ума. где расположены переменные программиста не должно парить и в первую очередь следует оптимизировать программу на уровне алгоритмов и структур данных. вообще есть хорошая поговорка -- покажи мне свои структуры данных и я скажу кто ты.
F>Маленькая статистика — но все же она везде практические в таком порядке, F>с++ девелоперы стоят на одной линии с php кодерами
а сколько получают пилоты истребителей? а их обучение обходится _намного_ дороже.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, fromegg, Вы писали:
0> Работодателю не важно, насколько крут инструмент, его интересует результат.
если "крутость" инструмента это "лучший результат за меньшее время", то работодателю это очень даже интересно. вот только си++ под это определение попадает с очень большими оговорками.
F>>Маленькая статистика — но все же она везде практические в таком порядке, F>>с++ девелоперы стоят на одной линии с php кодерами 0>"Невидимая рука рынка" (с)
...или статистика неправильная. если брать php, то мы увидим, что карьерный рост и максимальная планка зарплаты очень ограничены. с одной стороны стена, с другой -- пропасть. а вот у си/си++/java программистов в этом плане возможностей намного больше.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, fromegg, Вы писали:
F> Ребята мы не будем учить с++ и использовать следующие 4 семестра, зачем ломать себе мозг F> и платят то этим специалистам меньше чем другим, осваивать будем к примеру питон и F> за 1 семестр, он прекрасен удобен и всемогущ
не надо наезжать на питон. в качестве учебного языка питон очень даже ничего. во всяком случае в питоне общности, а в плюсах -- частности.
и потом, язык ни разу не уперся. самое сложное это алгоритмы, протоколы, стандарты... допустим, мы пишем дефрагментатор. системная составляющая это фигня. а вот задача как собрать мак. фрагментов за мин. перемещений -- это вам не баран чихнул.
или, например, антивирус. его быстродействие определяется не тем, где расположены переменные в цикле, а глубиной курений теории графов, конечных автоматов и прочей алгоритмизацией.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, fromegg, Вы писали:
F>Вопрос, которй меня волнует уже года 3, а внятного ответа еще не находил или хотя бы аргументов )
Фишка не столько в языке, сколько в предметной области.
Java — это практически всегда (по крайней мере если смотреть на валовый продукт) корпоративный софт, всякое банковское ПО и прочий аутсорс. Более или менее однородная и нормально оплачиваемая отрасль.
На плюсах же достаточно большой объем занимают:
1. Геймдев — где по неизвестным науке доширак! доширак! доширак! причинам платят мало при том что народ еще и овертаймит регулярно.
2. Embedded — где, по-видимому, есть определенное количество старичков на помоечку! на помоечку! на помоечку!, которые не успевают апгрейдить себя/место работы/скиллы в быстро изменяющемся мире.
Что такое "учить С++"? Вы что, текст стандарта наизусть заучиваете что ли? Что в С++ есть такого, что требовало бы больше месяца на изучение? Не парадигма ООП, не техники оптимизации, не архитектура ОС и WinAPI, не сторонние библиотеки, а именно сам язык С++.
F>Итак С++ — мощная низкоуровневая пушка с кучей возможностей, на этом звере написано почти все крутое и самое сложное )
Что, по вашему мнению, в С++ низкоуровнего и о какой куче возможностей, которых нет в других языках, идет речь?
F>Код на С++ быстрее и эффективнее остальных
Как вы понимаете "эффективнее" и чем это отличается от "быстрее"?
F>В общем требует четкого понимания что ты делаешь
А какая область человеческой деятельности не требует четкого понимания что ты делаешь? На каком языке можно писать программы в стиле "что-то как-то само собой получилось, не знаю даже как это вышло"?
F>ты должен знать почему второй вариант быстрее первого F>1)void printArray(vector<int>) F>2)void printArray(const vector<int>&)
Копирование занимает время. Это справедливо для любого языка и на первый взгляд не выглядит черной магией "невероятно, но один вариант почему-то быстрее другого, кааак они этого добились??"
F>ты должен знать что быстрее for(...;++iterator или iterator ++)
Вы удивитесь насколько у компилятора есть свое мнение по этому поводу.
F>ты должен понимать почему в цикле нельзя определять переменные, а должен их выносить на уровень выше
Любой современный компилятор сделает это за вас.
F>и еще кучи всяких особенностей
Приведенное выше — это особенности? И, видимо, наиболее сложные в плане изучения?
F>+ контроль использования памяти
Сделал new — сделай delete. Что в этом эзотерического, переводящего С++ в разряд чего-то элитарного?
F>почему же на фоне .NET/Java у С++ ниже зп ??? ну где справедливость )
Потому что, несмотря на кажущуюся простоту этих языков, на них решают более сложные и денежные задачи.
В университетах нормальных стран не учат С++, там учат концепциям программирования. А потом дают домашнее задание "реализовать учебный проект на языке Х" и сам язык изучается как нечто фоновое и чисто утилитарное.
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, 0x7be, Вы писали:
0>>Здравствуйте, fromegg, Вы писали:
0>> Работодателю не важно, насколько крут инструмент, его интересует результат. М>если "крутость" инструмента это "лучший результат за меньшее время", то работодателю это очень даже интересно. вот только си++ под это определение попадает с очень большими оговорками.
В том-то и дело, что тут под крутизной понимается нечто иное, чем "лучший результат за меньшее время".
Некогда одна эпическая личность писала "умение героически выстрелить себе в ногу с помощью своего же инструмента, центися разве что у прыщавых сосок, но никак не работадателем".
Вот и все.
Здравствуйте, fromegg, Вы писали:
F>преподаватель в вузе:
F>Ребята мы не будем учить с++ и использовать следующие 4 семестра, зачем ломать себе мозг и платят то этим специалистам меньше чем другим, F>осваивать будем к примеру питон и за 1 семестр, он прекрасен удобен и всемогущ F>
Хреновый преподаватель, который строит курс на изучении конкретного языка. Язык студент освоить и сам может, надо ориентироваться на суть программирования — алгоритмы, структуры данных, методологии и прочее. А на чем их демонстрировать — дело десятое. Python тут вполне себе неплох.
Здравствуйте, fromegg, Вы писали:
F>Учить С++ сложно и трудно, а платят меньше
А я вот не понимаю, зачем вообще искать ответы на такие вопросы.
Это все равно, что убиваться по поводу чьей-то машины, более крутой и дорогой, чем своя.
Проку от этого ровным счетом ноль.
C/C++ — это десктоп, системные разработки, либо геймдев, либо embedded.
А сейчас большинство проектов так или иначе связано с вебом, где правят Java/.NET.
Эти языки активно развиваются и продвигаются соответствующими компаниями, а у C++
такой компании, сопоставимой по уровню поддержки, просто не существует.
Добавьте сюда молодость Java/.NET, обилие "вкусностей" и относительно невысокий
порог вхождения — получите вполне закономерный спрос, который и наблюдается в
настоящее время. При том, что эти языки были спроектированы уже с оглядкой на
известные ошибки прошлого. Хотя я лично не могу признать, что Java/.NET ушли в
какой-то невероятный отрыв и по-прежнему навалом задач, которые решаются
исключительно низкоуровнывыми средствами C/C++, а это в первую очередь системные
разработки, плюс львиная доля десктопного софта.
И, как тут уже заметили, программисту платят за решение проблем, а не за знания.
Учитывая вышенаписанное, вполне резонно, что в среднем программист Java/.NET при
таком раскладе будет получать больше среднего плюсовика.
Вот если было бы наоборот, я бы удивился даже.
Надо поддерживать здоровый дух профессии.
Если что-то не нравится, вызывает зависть или чувство несправедливости,
профессию пора менять, или менять что-то в себе, или в окружающем мире.
Здравствуйте, fromegg, Вы писали:
F>Вопрос, которй меня волнует уже года 3, а внятного ответа еще не находил или хотя бы аргументов )
Щас объясню как "для идиотов".
F>Итак С++ — мощная низкоуровневая пушка с кучей возможностей, на этом звере написано почти все крутое и самое сложное ) F>Код на С++ быстрее и эффективнее остальных, "С++ дает программисту свободу выбора, даже если это даст ему возможность выбирать неправильно."(Вики)
Многолетняя практика показала, что это на практике не нужно. А вот что нужно, чтобы код был простой, понятный даже младенцу, чтобы стоимость его поддержки получалась низкой.
F>В общем требует четкого понимания что ты делаешь F>ты должен знать почему второй вариант быстрее первого F>ты должен понимать почему в цикле нельзя определять переменные, а должен их выносить на уровень выше F>и еще кучи всяких особенностей F>+ контроль использования памяти F>в твоих руках мощный механизм, которым нужно управлять только с умом F>.. и в связи с этим обучение С++ программиста стоит дороже и есть сложнее, тогда
Этот список имеет своим результатом:
— Очень тяжело и долго изучать, минимальный набор знаний для безопасного программирования крайне тяжело набрать, соответственно, средний программист с улицы будет писать опасный код
— код получается опасный и с минами замедленного действия, это прямой убыток для компании
— если код вдруг хороший, то новый программист с улицы может его сломать, если он не сам Страуструп
Слышал такой термин, как RAD? Rapid Application Development, по-русски?
Так вот, в этой концепции нет места для технологий, которые задерживают работу и расставляют мины.
Тенденция уже 10 лет идет, не меньше.
F>почему же на фоне .NET/Java у С++ ниже зп ??? ну где справедливость )
Справедливость очевидна.
На .NET/Java можно быстро создавать крупные и надежные продукты, предлагать их клиентам, удовлетворять их потребности и зарабатывать деньги. Это стоит денег.
На С++ можно очень долго и очень тяжело кодить, если очень повезет, закончить в текущем десятилетии и получить код, который не падает постоянно. Везет редко, потому как даже продукты монстров индустрии вроде Visual Studio и Photoshop таки умеют падать, хотя им второй десяток лет уже пошел. Это денег не стоит.
F>Маленькая статистика — но все же она везде практические в таком порядке, F>с++ девелоперы стоят на одной линии с php кодерами
Стоимость разработки выше. Риск намного выше. За что платить-то?
Здравствуйте, DorfDepp, Вы писали:
DD>Здравствуйте, fromegg, Вы писали:
F>>Вопрос, которй меня волнует уже года 3, а внятного ответа еще не находил или хотя бы аргументов ) DD>Справедливость очевидна. DD>На .NET/Java можно быстро создавать крупные и надежные продукты, предлагать их клиентам, удовлетворять их потребности и зарабатывать деньги. Это стоит денег.
Это не верно.
DD>На С++ можно очень долго и очень тяжело кодить, если очень повезет, закончить в текущем десятилетии и получить код, который не падает постоянно. Везет редко, потому как даже продукты монстров индустрии вроде Visual Studio и Photoshop таки умеют падать, хотя им второй десяток лет уже пошел. Это денег не стоит.
Это тоже не верно.
Здравствуйте, DorfDepp, Вы писали:
DD>Стоимость разработки выше. Риск намного выше. За что платить-то?
Был когда то C++Builder на нем разрабатывали desktop app быстрее чем на C#, если поддерживать модульность то падения можна свести к минимуму довольно быстро, с переносимостью на клиентские машины особых проблем также не было. С# имеет только преимущество для работы в/c вебом.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Язык студент освоить и сам может, надо ориентироваться на суть программирования — алгоритмы, структуры данных, методологии и прочее.
Таких студентов — единицы, а экзамен сдавать должны все. Так что выбор конкретного языка для изучения вполне оправдан
On 29.12.2011 12:57, Kernan wrote:
> DD>На .NET/Java можно быстро создавать крупные и *надежные продукты*, > предлагать их клиентам, удовлетворять их потребности и зарабатывать > деньги. Это стоит денег. > Это не верно.
Троллинг это конечно арт, но не стоит тешить себя необоснованными
иллюзиями. Это верно в практическом смысле — на .NET/Java _можно_ быстро
создавать крупные и *надежные продукты*, если конечно при этом
"надёжность" рассматривается не как философская категория, а как простое
желание кастомера чтобы оно "летало и не падало".
On 29.12.2011 13:02, UA wrote:
> DD>Стоимость разработки выше. Риск намного выше. За что платить-то? > > Был когда то C++Builder на нем разрабатывали desktop app быстрее чем на > C#, если поддерживать модульность то падения можна свести к минимуму > довольно быстро, с переносимостью на клиентские машины особых проблем > также не было.
Здравствуйте, UA, Вы писали:
UA>Здравствуйте, anonymouss, Вы писали:
A>>High Frequency C++ Software Engineer — $200,000 A>>
UA>Эта вакансия *только* для Бьерна.
Здравствуйте, fromegg, Вы писали:
F>в твоих руках мощный механизм, которым нужно управлять только с умом F>.. и в связи с этим обучение С++ программиста стоит дороже и есть сложнее, тогда F>почему же на фоне .NET/Java у С++ ниже зп ??? ну где справедливость )
Здравствуйте, hrensgory, Вы писали:
H>On 29.12.2011 12:57, Kernan wrote:
H>Троллинг это конечно арт, но не стоит тешить себя необоснованными
Я и не тешу. Кто писал да Java и C# знает, что говнокдить на этих языках можно так же как и на других и точно так же ты будешь ловить MemoryException, натыкаться на залоблоченные ресурсы и прочее, прочее, прочее. H>иллюзиями. Это верно в практическом смысле — на .NET/Java _можно_ быстро H>создавать крупные и *надежные продукты*, если конечно при этом H>"надёжность" рассматривается не как философская категория, а как простое H>желание кастомера чтобы оно "летало и не падало". H>"крупные", "надежные продукты", "летало"
Предлагаю тебе убрать один лишний пункт.
Чтобы на выходе получить быстрое, масштабируемое и надёжное ПО надо просто владеть техниками и знать принципы построения такого ПО.
Здравствуйте, anonymouss, Вы писали:
A>Здравствуйте, UA, Вы писали:
UA>>Здравствуйте, anonymouss, Вы писали:
A>>>High Frequency C++ Software Engineer — $200,000 A>>>
UA>>Эта вакансия *только* для Бьерна.
A>Тогда бы они ему и написали, напрямую
Некоторые конторы не пишут напрямую чтобы не упасть в глазах соискателя. А так когда он сам придет то компания сделает ему одолжение приняв на работу, после прохождения тестов с брайнбенча естественно.
On 29.12.2011 13:57, Kernan wrote: > H>иллюзиями. Это верно в практическом смысле — на .NET/Java _можно_ быстро > H>создавать крупные и *надежные продукты*, если конечно при этом > H>"надёжность" рассматривается не как философская категория, а как простое > H>желание кастомера чтобы оно "летало и не падало". > H>*"крупные", "надежные продукты", "летало"* > Предлагаю тебе убрать один лишний пункт. > Чтобы на выходе получить быстрое, масштабируемое и надёжное ПО надо > просто владеть техниками и знать принципы построения такого ПО.
Да ладно, правда что ли? Я то думал что достаточно просто его на Java
писать и всё. А тут вон оно как, принципы какие-то, техники, архитектура
По сути — на java/.net "быстрое, масштабируемое и надёжное ПО" тупо
ДЕШЕВЛЕ писать. Даже с учётом дефицита и высокой стоимости действительно
грамотных спецов в этих отраслях (поиск которых более труден т.к. порог
вхождения ниже и поток "яужетримесяцакаквсёзнаюиумеюдайтемне120тыщ"
больше чем в том же С/С++). Всё равно в итоге — ДЕШЕВЛЕ. И быстрее.
Здравствуйте, hrensgory, Вы писали:
H>On 29.12.2011 13:57, Kernan wrote: >> H>иллюзиями. Это верно в практическом смысле — на .NET/Java _можно_ быстро >> H>создавать крупные и *надежные продукты*, если конечно при этом >> H>"надёжность" рассматривается не как философская категория, а как простое >> H>желание кастомера чтобы оно "летало и не падало". >> H>*"крупные", "надежные продукты", "летало"* >> Предлагаю тебе убрать один лишний пункт. >> Чтобы на выходе получить быстрое, масштабируемое и надёжное ПО надо >> просто владеть техниками и знать принципы построения такого ПО.
H>Да ладно, правда что ли? Я то думал что достаточно просто его на Java H>писать и всё. А тут вон оно как, принципы какие-то, техники, архитектура H>
А без этого ты и на Java ничего путного не напишешь.
H>По сути — на java/.net "быстрое, масштабируемое и надёжное ПО" тупо H>ДЕШЕВЛЕ писать. Даже с учётом дефицита и высокой стоимости действительно H>грамотных спецов в этих отраслях (поиск которых более труден т.к. порог H>вхождения ниже и поток "яужетримесяцакаквсёзнаюиумеюдайтемне120тыщ" H>больше чем в том же С/С++). Всё равно в итоге — ДЕШЕВЛЕ. И быстрее.
Ты считал? Садился с калькулятором и требованиями к софту и считал? Если не затруднит, приведи расчёты.
Кстати, сколько продуктов ты разработал на С++, Java, C#? Что будет, если я напишу в гугле "<you product name> sucks[crap]"?
On 29.12.2011 15:13, Kernan wrote: > From: *Kernan* </Users/34898.aspx> > H>Да ладно, правда что ли? Я то думал что достаточно просто его на Java > H>писать и всё. А тут вон оно как, принципы какие-то, техники, архитектура > H> > А без этого ты и на Java ничего путного не напишешь.
Что за день, просто отличный день! Сюрприз за сюрпризом
> H>По сути — на java/.net "быстрое, масштабируемое и надёжное ПО" тупо > H>ДЕШЕВЛЕ писать. Даже с учётом дефицита и высокой стоимости действительно > H>грамотных спецов в этих отраслях (поиск которых более труден т.к. порог > H>вхождения ниже и поток "яужетримесяцакаквсёзнаюиумеюдайтемне120тыщ" > H>больше чем в том же С/С++). Всё равно в итоге — ДЕШЕВЛЕ. И быстрее. > Ты считал? Садился с калькулятором и требованиями к софту и считал? Если > не затруднит, приведи расчёты.
Мне по роду службы приходится иногда принимать такие решения. При их
принятии я руководствуюсь не только классовым чутьём. При разработке
типичного интранет-приложения у плюсов нет шансов, вообще 0. Разумеется
при разработке драйвера или там 3D-редактора ситуация будет обратной (я
их не разрабатываю, но имею основания так думать). И чтоб два раза не
вставать — портировать уже написанное и работающее на C++/Delphi на
java/.net тоже вряд ли кто будет.
> Кстати, сколько продуктов ты разработал на С++, Java, C#? Что будет, > если я напишу в гугле "<you product name> sucks[crap]"? > Trolling is a Art
Здравствуйте, kpcb, Вы писали:
_O_>>Язык студент освоить и сам может, надо ориентироваться на суть программирования — алгоритмы, структуры данных, методологии и прочее. K>Таких студентов — единицы, а экзамен сдавать должны все. Так что выбор конкретного языка для изучения вполне оправдан
Вопрос сути курса. Если курс называется "язык С++", то давать примеры на Питоне — неправильно. Если курс называется "алгоритмы и структуры данных", то примеры на Питоне — нормальны. Если студенты что-то не могут изучить из программы ВУЗа, то, возможно, этот ВУЗ не для них.
Здравствуйте, hrensgory, Вы писали:
H>On 29.12.2011 15:13, Kernan wrote: >> From: *Kernan* </Users/34898.aspx> >> H>Да ладно, правда что ли? Я то думал что достаточно просто его на Java >> H>писать и всё. А тут вон оно как, принципы какие-то, техники, архитектура >> H> >> А без этого ты и на Java ничего путного не напишешь.
H>Что за день, просто отличный день! Сюрприз за сюрпризом
Ага. Но всё же, на сколько крупные приложения ты писал, чтобы говорить о том, что на джаве нельзя наговнокодить так, что вас проклянут кастомеры/мэйнтейнеры/интеграторы?
>> Кстати, сколько продуктов ты разработал на С++, Java, C#? Что будет, >> если я напишу в гугле "<you product name> sucks[crap]"? H>Go class and study it.
Если нет ответов по существу, придерись к орфографии. Где-то у меня была картинка с пирамидой аргументации, но я никак не могу её найти!
>> Trolling is a Art
Я тебя затроллел.
Здравствуйте, UA, Вы писали:
UA>Здравствуйте, anonymouss, Вы писали:
A>>Здравствуйте, UA, Вы писали:
UA>>>Здравствуйте, anonymouss, Вы писали:
A>>>>High Frequency C++ Software Engineer — $200,000 A>>>>
UA>>>Эта вакансия *только* для Бьерна.
A>>Тогда бы они ему и написали, напрямую
UA>Некоторые конторы не пишут напрямую чтобы не упасть в глазах соискателя. А так когда он сам придет то компания сделает ему одолжение приняв на работу, после прохождения тестов с брайнбенча естественно.
забыл, там еще бонусы бывают
а вообще в этой области обычно 150К. осталось понять, как туда попасть
On 29.12.2011 15:48, Kernan wrote:
> H>Что за день, просто отличный день! Сюрприз за сюрпризом > Ага. Но всё же, на сколько крупные приложения ты писал, чтобы говорить о > том, что на джаве нельзя наговнокодить так, что вас проклянут > кастомеры/мэйнтейнеры/интеграторы?
Не стоит писать мне сообщения, адресованные персонажам в твоей голове —
я всё равно не смогу доставить их по адресу
F>Вопрос сути курса. Если курс называется "язык С++", то давать примеры на Питоне — неправильно. Если курс называется "алгоритмы и структуры данных", то примеры на Питоне — нормальны. Если студенты что-то не могут изучить из программы ВУЗа, то, возможно, этот ВУЗ не для них.
Не нужны курсы по конкретным языкам. Максимум обзорный спецкурс по не мэйнстримовым языкам в духе Erlang-а, Хаскеля, Немерле и т.п. Это будет полезно.
А так я не вижу смысла в том, что студент будет зубрить стандарт какого-то языка. Студент должен учиться решать задачи.
Здравствуйте, fromegg, Вы писали:
F>почему же на фоне .NET/Java у С++ ниже зп ??? ну где справедливость )
C++ — довольно таки примитивное, но монстровое поделие, полное исторически сложившихся нелепых нагромождений. Человек, который хорошо в нем ориентируется — это хорошее зубрилко а не хороший программист. Умение героически преодолевать трудности, которые создает твой собственный инструмент, вместо того, чтобы решать непосредственно прикладную задачу, в современно мире ценится разве что только среди прыщавых сосок. Работодатель же это сомнительное умение не ценит, и совершенно справедливо.
Здравствуйте, hrensgory, Вы писали:
H>Ключевое слово — "был".
Borland играл на чужом поле по чужим правилам, поэтому результат был предсказуем. Но тем не менее они сэкономили много времени и нервов потому как использовать MFC с такой же эффективностью было нереально.
Здравствуйте, _Obelisk_, Вы писали:
_O_>на суть программирования — алгоритмы, структуры данных, методологии и прочее.
Алгоритмы и структуры данных — нифига на суть программирования. Большинство алгоритмистов пишут жуткий быдлокод и горе тем, кому непосчастливилось работать в среде людей, думающих, что программирование — это алгоритмы и структуры данных.
Здравствуйте, hrensgory, Вы писали:
h> On 29.12.2011 13:02, UA wrote:
h> > DD>Стоимость разработки выше. Риск намного выше. За что платить-то?
h> > h> > Был когда то C++Builder на нем разрабатывали desktop app быстрее чем на h> > C#, если поддерживать модульность то падения можна свести к минимуму h> > довольно быстро, с переносимостью на клиентские машины особых проблем h> > также не было.
h> Ключевое слово — "был".
Да он и сейчас есть, и даже чего-то там из нового стандарта поддерживает.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>C++ — довольно таки примитивное, но монстровое поделие, полное исторически сложившихся нелепых нагромождений. Человек, который хорошо в нем ориентируется — это хорошее зубрилко а не хороший программист. Умение героически преодолевать трудности, которые создает твой собственный инструмент, вместо того, чтобы решать непосредственно прикладную задачу, в современно мире ценится разве что только среди прыщавых сосок. Работодатель же это сомнительное умение не ценит, и совершенно справедливо.
Странно.
Пишу на C++ и никаких трудностей не испытываю. Работодатель доволен.
Что я делаю не так ?
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Здравствуйте, _Obelisk_, Вы писали:
_O_>>на суть программирования — алгоритмы, структуры данных, методологии и прочее.
ПМ>Алгоритмы и структуры данных — нифига на суть программирования.
+100. Прикладное практическое программирование структур данных и алгоритмов почти никогда не касается. В моей практике только один раз случилось, да и то весьма условно. У многих людей за 15-20 лет не было ни единого соприкосновения, хотя они прошли весь путь от программиста до начальника департамента.
ПМ>Большинство алгоритмистов пишут жуткий быдлокод и горе тем, кому непосчастливилось работать в среде людей, думающих, что программирование — это алгоритмы и структуры данных.
Русские программисты почти все так думают.
Получается, русские программисты в массе своей пишут плохой код? Не удивлюсь, если так.
обсуждение доставило тчк новогодний фейерверк тчк такого не встречал 2003-го тчк автор жжот зпт бис всклзн
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, abibok, Вы писали:
A>Что такое "учить С++"? Вы что, текст стандарта наизусть заучиваете что ли? Что в С++ есть такого, что требовало бы больше месяца на изучение? Не парадигма ООП, не техники оптимизации, не архитектура ОС и WinAPI, не сторонние библиотеки, а именно сам язык С++.
Хех. Хехехехехехе.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Не нужны курсы по конкретным языкам. Максимум обзорный спецкурс по не мэйнстримовым языкам в духе Erlang-а, Хаскеля, Немерле и т.п. Это будет полезно.
Начерта эти "мэйнстримовые" языки студентам? Ни разу ещё не встречал вакансий программиста на Немерле или Хаскеле.
Здравствуйте, QrystaL, Вы писали:
QL>Здравствуйте, _Obelisk_, Вы писали: _O_>>Студент должен учиться решать задачи.
QL>Задачи все равно придется решать на конкретном языке. А еще лучше, чтобы студент придя на работу, знал язык, на котором придется писать.
Самообразование никто не отменял. ВУЗ дает фундамент, основу а конкретные практические навыки студент должен нарабатывать сам.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Алгоритмы и структуры данных — нифига на суть программирования. Большинство алгоритмистов пишут жуткий быдлокод и горе тем, кому непосчастливилось работать в среде людей, думающих, что программирование — это алгоритмы и структуры данных.
А это потому, что большинство программистов прошли мимо и структур данных и алгоритмов. Иначе бы не было столько вопросов по алгоритмам, структурам данных и т.п.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>C++ — довольно таки примитивное, но монстровое поделие, полное исторически сложившихся нелепых нагромождений.
Сферическая демагогия в вакууме
ПМ>Человек, который хорошо в нем ориентируется — это хорошее зубрилко а не хороший программист. Умение героически преодолевать трудности, ПМ>которые создает твой собственный инструмент, вместо того, чтобы решать непосредственно прикладную задачу, в современно мире ценится разве ПМ>что только среди прыщавых сосок.
Человек, который хорошо в нем ориентируется — это профессионал. Если понимаешь как всё работает — то никаких трудностей не возникает.
ПМ>Работодатель же это сомнительное умение не ценит, и совершенно справедливо.
Работодатели имеют на этот счёт другую точку зрения.
Здравствуйте, DorfDepp, Вы писали:
DD>+100. Прикладное практическое программирование структур данных и алгоритмов почти никогда не касается. В моей практике только один раз случилось, да и то весьма условно. У многих людей за 15-20 лет не было ни единого соприкосновения, хотя они прошли весь путь от программиста до начальника департамента.
За 15-20 лет никто не использовал сортировку, массивы, множества, деревья и прочего ? Не верю. Я не говорю, что программист должен изобретать свои структуры данных или алгоритмы. Он должен уметь пользоваться готовыми. А с этим тоже большой напряг, судя по вопросам в профильных форумах.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Для расширения кругозора.
Вы наверно очень давно учились в университете. А я вот ещё не совсем давно, ещё помню — чему нас только не учили (видимо из тех же соображений расширения кругозора): политология, психология, педагогика, экология. Даже программированию на прологе учили.
Среднестатистический студент забивает на это дело болт, и правильно делает, ибо после сдачи зачёта никаких полезных знаний не остаётся. По
этому тратить на них время смысла нет.
_O_>Роберт Хайнлайн: _O_>...
Да мало ли что сказал Роберт Хайнлайн. Кто он вообще такой?
У меня тоже есть вопрос который занимает меня уже несколько последних лет, не рискую создавать отдельно треда, но тут позволю себе спрость, интересно, почему на вакансии типа "инженер, программист ембеддед" так мало предлагают, по моим наблюдениям потолок 60. Как мне кажется область знаний должна включать в себя следующее: нужно разбираться в железе, математике, нужно хорошо знать устройство линуха и C/C++ + асм конкретного проца. За PHP/ASP/Java/C# предлагают обычно больше.
Платят не за твои скилы, а за умение быстро и качество создавать софт. Я знаю все из перечисленных технологий и программирую на смеси из них. Мне вообще все равно до языка программирования, ибо за 12 лет опыта я уже давно понял, что языки ни чем не отличаются друг от друга — только синтаксис и семантика... Вопрос в применении тех или иных технологий...
Здравствуйте, savitar, Вы писали:
S>Здравствуйте, fromegg, Вы писали:
S>У меня тоже есть вопрос который занимает меня уже несколько последних лет, не рискую создавать отдельно треда, но тут позволю себе спрость, интересно, почему на вакансии типа "инженер, программист ембеддед" так мало предлагают, по моим наблюдениям потолок 60. Как мне кажется область знаний должна включать в себя следующее: нужно разбираться в железе, математике, нужно хорошо знать устройство линуха и C/C++ + асм конкретного проца. За PHP/ASP/Java/C# предлагают обычно больше.
С очень большим трудом представляю задачу в эмбеде, которая пишется на C++ под Linux c применением серьёзной математики.
Какие-то взаимоисключающие понятия. Если там какая-то сложная модель данных, требующая ООП, то это выходит не особенно эмбед и асм тут идёт побоку. Если там критичные к эффективности вычисления, выполняющиеся в эмбеде, причём здесь линукс и плюсы? Если это тупо системное ПО под линукс, причём здесь математика? Кстати, а C/C++ — это что за язык такой?
Здравствуйте, savitar, Вы писали:
S>Здравствуйте, fromegg, Вы писали:
S>У меня тоже есть вопрос который занимает меня уже несколько последних лет, не рискую создавать отдельно треда, но тут позволю себе спрость, интересно, почему на вакансии типа "инженер, программист ембеддед" так мало предлагают, по моим наблюдениям потолок 60. Как мне кажется область знаний должна включать в себя следующее: нужно разбираться в железе, математике, нужно хорошо знать устройство линуха и C/C++ + асм конкретного проца. За PHP/ASP/Java/C# предлагают обычно больше.
Таким видом работ занимаются немногие. Количество вакансий будет невелико. Конкуренцию друг другу будут создавать минимальную. Поэтому и битвы за кандидатов не будет. Обычный рынок.
Получается так: зарплату определяет не сложность технологии, а структура спроса и предложения.
Вот на Коболе программистов почти не осталось, а они все еще нужны банкам, тем приходится залезать поглубже в карман. А сложен ли этот Кобол или нет, значения не имеет.
Здравствуйте, _Obelisk_, Вы писали: _O_>ВУЗ дает фундамент, основу
И в каком виде это фундамент дается? Псевдокод и блок-схемы?
Все теоретические знания надо закреплять на практике. Так почему бы сразу не давать практические задания на одном из мейнстримовых языков? (С++/C#/Java etc)
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>C++ — довольно таки примитивное, но монстровое поделие, полное исторически сложившихся нелепых нагромождений. Человек, который хорошо в нем ориентируется — это хорошее зубрилко а не хороший программист. Умение героически преодолевать трудности, которые создает твой собственный инструмент, вместо того, чтобы решать непосредственно прикладную задачу, в современно мире ценится разве что только среди прыщавых сосок. Работодатель же это сомнительное умение не ценит, и совершенно справедливо.
Великую попаболь в тебе я ощущаю, юный падаван.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>обсуждение доставило тчк новогодний фейерверк тчк такого не встречал 2003-го тчк автор жжот зпт бис всклзн
Не могу с вами согласиться, коллега. Не тот уже нынче тролль пошёл, растолстел совсем.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, b-3, Вы писали:
b-3>С очень большим трудом представляю задачу в эмбеде, которая пишется на C++ под Linux c применением серьёзной математики.
b-3>Какие-то взаимоисключающие понятия. Если там какая-то сложная модель данных, требующая ООП, то это выходит не особенно эмбед и асм тут идёт побоку. Если там критичные к эффективности вычисления, выполняющиеся в эмбеде, причём здесь линукс и плюсы? Если это тупо системное ПО под линукс, причём здесь математика? Кстати, а C/C++ — это что за язык такой?
В современном ембеддед с двумя ядрами на частоте 1ГЦ Linux, C++ и сложная модель данных вполне себе применима и востребована, математика нужна для таких вещей как: гео, кодеки, 3D... Асм нужен чтобы все это быстро работало. Все это работает обычно под Linux. Нужно хорошо знасть и голый C, так как ядро, модули и множество либ на нем, и C++, так как на нем быстрее и эффективнее решать задачи.
Здравствуйте, Banned by IT, Вы писали:
ГВ>>обсуждение доставило тчк новогодний фейерверк тчк такого не встречал 2003-го тчк автор жжот зпт бис всклзн BBI>Не могу с вами согласиться, коллега. Не тот уже нынче тролль пошёл, растолстел совсем.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DorfDepp, Вы писали:
DD> Получается так: зарплату определяет не сложность технологии, а структура спроса и предложения. DD> Вот на Коболе программистов почти не осталось, а они все еще нужны банкам, тем приходится DD> залезать поглубже в карман. А сложен ли этот Кобол или нет, значения не имеет.
интересно, а кто учит кобол в наши дни? по долгу службы, сидя на окладе, это я еще понимаю. а вот с какого бодуна учат плюсы?
известно ведь, что:
1) не самый востребованный язык (уже жаловались, что вакансий на java больше);
2) язык далеко не самый быстрый, доступный и легкий в плане обучения;
3) средние зарплаты программиста на плюсах не самые высокие;
вывод -- учить плюсы, чтобы заработать много денег -- смысла нет. что же тогда толкает на его изучение?
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Cyberax, Вы писали:
C>Учитывая, что Андроид существует в публичном виде менее 6 лет, то график слегка веселит.
Ну там же на графике выделено слово: общий опыт работы, а не опыт работы с этой технологией или в конкретной отрасли.
К этому моменту у меня внутри 0.5, 0.7, 0.33 (с) НС
Здравствуйте, anonymouss, Вы писали:
A>Здравствуйте, UA, Вы писали:
UA>>Здравствуйте, anonymouss, Вы писали:
A>>>High Frequency C++ Software Engineer — $200,000 A>>>
UA>>Эта вакансия *только* для Бьерна.
A>Тогда бы они ему и написали, напрямую
Так обычно и пишут напрямую.
Вакансии в таких нишевых областях редко заполняются публичным поиском кандидатов, сначала ищут по проверенным знакомым и уже только после выходят на открытый рынок труда.
Здравствуйте, UA, Вы писали:
UA>Здравствуйте, anonymouss, Вы писали:
A>>High Frequency C++ Software Engineer — $200,000 A>>
UA>Эта вакансия *только* для Бьерна.
Я так понимаю, имелся в виду High Frequency Trading? Ну так таких вакансий много больше чем одна на Бьярне.
Здравствуйте, QrystaL, Вы писали:
QL>Здравствуйте, _Obelisk_, Вы писали: _O_>>ВУЗ дает фундамент, основу QL>И в каком виде это фундамент дается? Псевдокод и блок-схемы? QL>Все теоретические знания надо закреплять на практике. Так почему бы QL>сразу не давать практические задания на одном из мейнстримовых языков? QL>(С++/C#/Java etc)
чем питон не устраивает? c# по сравнению с питоном это частность. вот пришел я на лекцию с мак-буком и что мне с вашим шарпом делать? java немного получше, но для небольших программ, иллюстрирующих, например, принцип действия конечного автомата, java сильно избыточна и мы погрязнем в деталях. плюсы на маленьких проектах вообще не дают ошутимого выигрыша, а на студенческих программах -- так и подавно. и опять мы скатываемся в детали, объясняя различие между разными типами переменных.
питон юзают по многих универах мира потому что он простой и мощный одновременно.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, savitar, Вы писали:
S>Здравствуйте, fromegg, Вы писали:
S>У меня тоже есть вопрос который занимает меня уже несколько последних лет, не рискую создавать отдельно треда, но тут позволю себе спрость, интересно, почему на вакансии типа "инженер, программист ембеддед" так мало предлагают
ИМХО рынок зарплат здесь ощущает большое давление вниз из-за того что на нем присутствует большое количество эмбедерщиков из различных государственных, полугосударственных и бывших государственных контор типа КБ, НИИ, околоуниверститеских лабароторий, различных производственных АСУшников, ВПК-шников и т. п., где традиционно мало платят.
Re[11]: Учить С++ сложно и трудно, а платят меньше
Здравствуйте, мыщъх, Вы писали:
М>вывод -- учить плюсы, чтобы заработать много денег -- смысла нет. что же тогда толкает на его изучение?
Его практически повсеместно дают в вузах и техникумах.
Т.е. и получается, что в нем много тех людей, которые поплыли по течению
(вместо того, чтобы из жажды денег осваивать ещё что-то самостоятельно).
Здравствуйте, savitar, Вы писали:
S>Здравствуйте, fromegg, Вы писали:
S>У меня тоже есть вопрос который занимает меня уже несколько последних лет, не рискую создавать отдельно треда, но тут позволю себе спрость, интересно, почему на вакансии типа "инженер, программист ембеддед" так мало предлагают, по моим наблюдениям потолок 60. Как мне кажется область знаний должна включать в себя следующее: нужно разбираться в железе, математике, нужно хорошо знать устройство линуха и C/C++ + асм конкретного проца. За PHP/ASP/Java/C# предлагают обычно больше.
Долго вводить человека в работу (пока он въедет в специфическое оборудование, где и для чего оно применяется, аппаратную архитектуру и т.п.), околонулевой приток людей с публичных вакансий (рост заявленных зарплат качества не увеличивает, наоборот начинают лезть люди без представления о железе, занимавшиеся PHP/ASP/Java/C#).
У людей которые реально работают, потолок — раза в 2,5 выше (не Москва), хотя из студентов до этого придется пахать годами,
и на работу нанимают людей знакомых по вузу или другим проектам.
Здравствуйте, mtnl, Вы писали:
M>Его практически повсеместно дают в вузах и техникумах. M>Т.е. и получается, что в нем много тех людей, которые поплыли по течению M>(вместо того, чтобы из жажды денег осваивать ещё что-то самостоятельно).
Язык собственно в жажде денег (работая программистом) просто мелкая разменная монета. Сам по себе значит очень мало, только первая ступенька, не самая большая, даже в случае С++. Зато после С++ другие императивные языки осваиваются за несущественное время (но, говорят, не наоборот).
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, anonymouss, Вы писали:
A>>Здравствуйте, UA, Вы писали:
UA>>>Здравствуйте, anonymouss, Вы писали:
A>>>>High Frequency C++ Software Engineer — $200,000 A>>>>
UA>>>Эта вакансия *только* для Бьерна.
A>>Тогда бы они ему и написали, напрямую
J>Так обычно и пишут напрямую. J>Вакансии в таких нишевых областях редко заполняются публичным поиском кандидатов, сначала ищут по проверенным знакомым и уже только после выходят на открытый рынок труда.
Да не важно что они там думали до того, как вышли на рынок. Главное, что такие вакансии на рынке появляются. Но в них программирование, как правило, вторично. Первично — знание некоторой хорошо оплачиваемой предметной области. Но С++ приходится учить. Еще и VBA частенько
Здравствуйте, fromegg, Вы писали: F>Вопрос, которй меня волнует уже года 3, а внятного ответа еще не находил или хотя бы аргументов )
ответ простой — мир несправедлив.
есть многие вещи, которые сделать сложно, но тебе за них никто не заплатит.
например, пальцем написать на земле Миру Мир десятиметровыми буквами — сложно, сьесть за 1 присест 5 кило мяса — сложно. подтянуться 100 раз — сложно. но за это не заплатят. не нужно думать, что все, что сложно, за это платят. работа директора отделения крупной компании намного проще работы программиста С++, но они обладают разными навыками и зарплатами. программист не идет в директора потому что это просто не интересно, а не потому что он не может. программирование на С++ это и есть соб-но программирование, другие языки — лишь попытки упрощения некоторых достаточно узких областей. я не занимаюсь вебом не потому, что за него платят меньше, а потому что меня от него тошнит, например. меня просто вырвет, если я попробую написать что-то на Actionscript или написать длинный sql запрос.
Здравствуйте, __kot2, Вы писали:
> работа директора отделения крупной компании намного проще работы программиста С++,
а директор об этом знает? расскажите ему, а то так и помрет неучем. а ничего, что многие директора в прошлом сильные и успешные программисты? в том числе и на плюсах?
> программист не идет в директора потому что это просто не интересно, а не потому что он не может.
жена в курсе? дайте телефон жены и она вас запилит.
> программирование на С++ это и есть соб-но программирование, > другие языки — лишь попытки упрощения некоторых достаточно узких областей.
другие языки в курсе? а что по этому поводу думает дохлый страус? он в курсе, что плюсы усложняют широкую область? кстати, а что плохого в упрощении и специализации?
> я не занимаюсь вебом не потому, что за него платят меньше, а потому > что меня от него тошнит, например. меня просто вырвет,
если вы им не занимаетесь, то откуда вы знаете?
> если я попробую написать что-то на Actionscript
чем вам не угодил AS?
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Не нужны курсы по конкретным языкам. Максимум обзорный спецкурс по не мэйнстримовым языкам в духе Erlang-а, Хаскеля, Немерле и т.п. Это будет полезно. _O_>А так я не вижу смысла в том, что студент будет зубрить стандарт какого-то языка. Студент должен учиться решать задачи.
Нужно учить студентов больше, чем решать задачи. Их нужно учить software engineering. Туда должно входить гораздо больше, чем просто умение решать задачи. Так же туда должно входить хорошее владение хотя бы одним широко распостраненным языком программирования. Иначе будут продолжать приходить вчерашние студенты и писать в production код свои собственные сортировки (с багами), свои алгоритмы и структуры данных, которые уже существуют в языке или библиотеке.
У меня был один коллега, который признался, что за время обучения в университете ничего больше паскаля и основ С не знал. Он прекрасно решал задачи. Урывками подхватив что-то где-то про C++, он писал горы кода (очень способный человек), которые потом приходилось с разгребать. Вот вам и умение решать задачи в сочетании с полным незнанием своего профессионального инструментария.
В распостраненных (не игрушечных) языках программирования, кстати, очень много отражено из проблемных областей, в которых эти языки применяются. Так же как и в естественных языках очень много отражено из реальной жизни людей, которые этот язык используют. Поэтому неправильно говорить, что языки программирования не важны. Они важны, и их надо изучать.
Здравствуйте, мыщъх, Вы писали: >> работа директора отделения крупной компании намного проще работы программиста С++, М>а директор об этом знает? расскажите ему, а то так и помрет неучем. а ничего, что многие директора в прошлом сильные и успешные программисты? в том числе и на плюсах?
текущие задачи которые приходится решать программисту требуют большего времени обучению и имеют большую собственную и исследовательскую сложность, чем работа директора.
в среднем. если фирма на гране краха и директор реально ее вытягивает — тут да, поседеть можно. а если в проекте все спокойно и ведется тупой саппорт, то нет ничего проще, чем работать программистом — можно ничего не делать вообще.
>> программист не идет в директора потому что это просто не интересно, а не потому что он не может. М>жена в курсе? дайте телефон жены и она вас запилит.
жена в курсе. но каждый должен заниматься тем, что ему нравится.
>> программирование на С++ это и есть соб-но программирование, >> другие языки — лишь попытки упрощения некоторых достаточно узких областей. М>другие языки в курсе? а что по этому поводу думает дохлый страус? он в курсе, что плюсы усложняют широкую область? кстати, а что плохого в упрощении и специализации?
ничего плохого в этом нет. просто одно дело доктор. другое дело специалист по левой ноздре. и только по ее очистке. ничего другого не может, в правой ноздре не разбирается, но чистит ее изумительно быстро и качественно.
>> я не занимаюсь вебом не потому, что за него платят меньше, а потому >> что меня от него тошнит, например. меня просто вырвет, М>если вы им не занимаетесь, то откуда вы знаете?
обзорные знания по многим областям у меня есть. когда появляется что-то, про что многие говорят, грех не разобраться, почитать
>> если я попробую написать что-то на Actionscript М>чем вам не угодил AS?
гавно всегда многогранно
Здравствуйте, DorfDepp, Вы писали:
DD>Здравствуйте, Паблик Морозов, Вы писали:
ПМ>>Здравствуйте, _Obelisk_, Вы писали:
_O_>>>на суть программирования — алгоритмы, структуры данных, методологии и прочее.
ПМ>>Алгоритмы и структуры данных — нифига на суть программирования.
DD>+100. Прикладное практическое программирование структур данных и алгоритмов почти никогда не касается. В моей практике только один раз случилось, да и то весьма условно. У многих людей за 15-20 лет не было ни единого соприкосновения, хотя они прошли весь путь от программиста до начальника департамента.
это просто проекты были совсем уж простые (прочитали из базы отобразили, распечатали), в нормальных проектах и алгоритмы и структуры данных появляются в полный рост
Здравствуйте, мыщъх, Вы писали:
М>интересно, а кто учит кобол в наши дни? по долгу службы, сидя на окладе, это я еще понимаю. а вот с какого бодуна учат плюсы?
Поэтому вывод: не надо учить С++, товарищи, не надо! Больше будут ценится те, кто уже знает С++.
Кстати, я мне как-то один рекрутер сказал, что компании, которые используют Java, все равно очень хотят нанять С++-ников, потому что они считают, что человек, хорошо разбирающийся в С++, достаточно легко перейдет на Java. А его сопутствующие системные знания будут очень большим приемуществом перед тем, кто разбирается только в Java.
Здравствуйте, __kot2, Вы писали:
__> работа директора отделения крупной компании намного проще работы программиста С++, но они обладают разными навыками и зарплатами. программист не идет в директора потому что это просто не интересно, а не потому что он не может.
скорее это только впечатление, которое складывается у неопытного человека, который понимает суть и сложность своей деятельности (преувеличивает важность и сложность), но не понимает суть и сложность деятельности других людей (преуменьшает важность и сложность)
явление, достаточно широко описанное в литературе
а не идет он туда потому, что его туда тупо не зовут, т.к. деятельность требует принципиально других навыков, другого круга общения, даже другого взгляда на жизнь
Идти работать программистом, чтобы заработать денег — наиглупейшая затея. Есть пути куда проще и быстрее. И я не про убий и укради. У меня друг в москоу, учился на асушника. прогу (С++) на диплом (крансый) ему написали за бабло, т.к. сам в программировании ни бум-бум. После окончания вуза подался в торговлю металлом. Итог: уже себе вполне обеспеченный с хатой в столице.
М>вывод -- учить плюсы, чтобы заработать много денег -- смысла нет. что же тогда толкает на его изучение?
Здравствуйте, savitar, Вы писали:
S>Здравствуйте, b-3, Вы писали:
b-3>>С очень большим трудом представляю задачу в эмбеде, которая пишется на C++ под Linux c применением серьёзной математики.
b-3>>Какие-то взаимоисключающие понятия. Если там какая-то сложная модель данных, требующая ООП, то это выходит не особенно эмбед и асм тут идёт побоку. Если там критичные к эффективности вычисления, выполняющиеся в эмбеде, причём здесь линукс и плюсы? Если это тупо системное ПО под линукс, причём здесь математика? Кстати, а C/C++ — это что за язык такой?
S>В современном ембеддед с двумя ядрами на частоте 1ГЦ Linux, C++ и сложная модель данных вполне себе применима и востребована, математика нужна для таких вещей как: гео, кодеки, 3D... Асм нужен чтобы все это быстро работало. Все это работает обычно под Linux. Нужно хорошо знасть и голый C, так как ядро, модули и множество либ на нем, и C++, так как на нем быстрее и эффективнее решать задачи.
Так это называется Linux Workstation. То, что вы продаёте (вероятно) готовый программно-аппаратный комплекс, не делает это эмбед-разработкой. Или, к примеру, четырёхпроцессорный IBM-сервер, настроенный "под ключ" и проданный заказазчику — это тоже эмбед?
Это полномасштабная разработка прикладного ПО, пусть не под Windows. И никто не мешает делать не на плюсах, ловя глюки и падения, а на managed-языке, с нормальным тестированием и современным инструментарием, вынося узкие места в сишные либы. Могут мешать только разработчики, которые не знают ни Cи, ни Python, ни .NET, ни Java, ни С++, а вместо этого быдлокодят на неизвестном науке языке СиСиПлюсПлюс огромного монстра с 3d, кодеками и GPS
Здравствуйте, mtnl, Вы писали: M>скорее это только впечатление, которое складывается у неопытного человека, который понимает суть и сложность своей деятельности (преувеличивает важность и сложность), но не понимает суть и сложность деятельности других людей (преуменьшает важность и сложность)
ну конечно же проще всего сказать что я не знаю, о чем говорю, сижу тут завидую директору, который только штаны протирает, а я горбачусь.
но дело в том, что занимался и руководством проектов и вообще руководством своей компанией и могу сказать что это гораздо проще, чем программирование. конечно же это требует навыков и взгляда на жизнь, но определенных навыков для того чтобы начать программировать надо гораздо больше, чем для того, чтобы начать руководить. предметная область у программиста гораздо сложнее. и задачи гораздо более головоломные возникают. грубо говоря программирование это шахматы, а руководство, это крестики-нолики.
M>явление, достаточно широко описанное в литературе
а вы наверняка из руководства. потому что инженер имеет аналитический склад ума, никому по дефолту не доверяет и не будет ссылаться на мнение в стиле "все знают, что"
M>а не идет он туда потому, что его туда тупо не зовут, т.к. деятельность требует принципиально других навыков, другого круга общения, даже другого взгляда на жизнь
и не зовут тоже, конечно.
On 29.12.2011 19:26, UA wrote:
> H>Ключевое слово — "был". > > Borland играл на чужом поле по чужим правилам, поэтому результат был > предсказуем. Но тем не менее они сэкономили много времени и нервов > потому как использовать MFC с такой же эффективностью было нереально.
Полностью согласен. Но та же Дельфи получила не в пример большее
распространение и, насколько я знаю, в каком-то виде до сих пор жива.
Здравствуйте, __kot2, Вы писали:
M>>явление, достаточно широко описанное в литературе __>а вы наверняка из руководства. потому что инженер имеет аналитический склад ума, никому по дефолту не доверяет и не будет ссылаться на мнение в стиле "все знают, что"
Если инженера заинтересуют конкретные источники —
Ariely, Dan (2010), The Upside of Irrationality, HarperCollins, pp. 352, ISBN 9780061995033
(там про явление, проведенные эксперименты, методику, русский перевод книжки вроде бы тоже существует).
DR>Учить С++ сложно и трудно, следовательно при программируют на нём хуже. F>>ты должен знать что быстрее for(...;++iterator или iterator ++) DR>Без разницы.
Я бы так не утверждал.
int wmain(int argc, wchar_t* argv[])
{
struct Ints : std::set<int> {} il;
for (int n = 0; n<200000; ++n) il.insert(n);
DWORD ticks = GetTickCount();
for (int n = 0; n<1000; ++n)
{
for (Ints::iterator i = il.begin(); i!=il.end(); i++);
}
printf("time: %u msec\n", GetTickCount() - ticks);
return 0;
}
Релиз, VS2005 с выключенной оптимизацией (/Od) на q8400:
i++ — 6640..6680 msec
++i — 6530..6540 msec
с включенной оптимизаций по размеру (/O1):
i++ — 5700..5720 msec
++i — 5590..5625 msec
с включенной оптимизаций по скорости (/O2) и /Ox действительно пофиг ++i или i++ — оба варианта ~3270 msec
а оптимизация дело такое — ее ведь может не быть такой как у MS на target платформе/компиляторе...
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали: O>Релиз, VS2005 с выключенной оптимизацией (/Od) на q8400:
это все-таки не дефолтная оптимизация, а ее полный запрет — дебаг. на низком уровне для базовых типов ++i — инкремент, i++ — копирование в другой регистр и там уже инкремент, чтобы иметь одновременно значения i и i++. но так как значение i нафиг никому не нужно, то убирание этой пересылки это наипримитивнейшая оптимизация, с которой справиться любой думаю абсолютно компилятор имеющий оптимизацию вообще. я лично пишу i++ потому что там красивее
O>>Релиз, VS2005 с выключенной оптимизацией (/Od) на q8400: __>это все-таки не дефолтная оптимизация, а ее полный запрет — дебаг. на низком уровне для базовых типов ++i — инкремент, i++ — копирование в другой регистр и там уже инкремент, чтобы иметь одновременно значения i и i++. но так как значение i нафиг никому не нужно, то убирание этой пересылки это наипримитивнейшая оптимизация, с которой справиться любой думаю абсолютно компилятор имеющий оптимизацию вообще. я лично пишу i++ потому что там красивее
Эот очень субъективно и вообще дело привычки. Раньше мне тоже i++ больше нравилось, а теперь наоборот, и ваще меня коробит и я переделываю в префиксный инкремент везде где под руку подворачивается
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали: O>Эот очень субъективно и вообще дело привычки. Раньше мне тоже i++ больше нравилось, а теперь наоборот, и ваще меня коробит и я переделываю в префиксный инкремент везде где под руку подворачивается
не, ну меня тоже многие вещи коробят, например в приведенном коде конкретно DWORD, printf, в меньшей степени wmain и wchar_t, но я терпимо отношусь к любым рабочим решениям в принципе.
Здравствуйте, alexeiz, Вы писали:
A>Нужно учить студентов больше, чем решать задачи. Их нужно учить software engineering. Туда должно входить гораздо больше, чем просто умение решать задачи. Так же туда должно входить хорошее владение хотя бы одним широко распостраненным языком программирования. Иначе будут продолжать приходить вчерашние студенты и писать в production код свои собственные сортировки (с багами), свои алгоритмы и структуры данных, которые уже существуют в языке или библиотеке.
Это скорей из области психологии. Логика подсказывает, что стоит вначале поискать готовые решения. Либо свести задачу к комбинации известных решений.
Изобретать свой велосипед — это особенности психики конкретного программиста. То, почему среди программистов попадается много подобных субъектов, опять же вопрос к психологам.
Здравствуйте, __kot2, Вы писали:
__>а вы наверняка из руководства. потому что инженер имеет аналитический склад ума, никому по дефолту не доверяет и не будет ссылаться на мнение в стиле "все знают, что"
Все знают, что программисты не будут ссылаться на мнение в стиле "все знают, что". Рекурсия, брат!
Здравствуйте, minorlogic, Вы писали:
M>На питоне тяжело базовые алгоритмы изучать , контролировать расход памяти. Адресная арифметика и т.п.
Напротив, по моему опыту, с тех пор как я начал серьезно применять питон (и перл, кстати), то я сразу заметил, что мой код на питоне имеет приемущественно алгоритмический характер. Очень хорошо на нем алгоритмы описываются, чисто я бы даже сказал.
Ну, а от явного выделения памяти и адресной арифметики я и в С++ уже давно отошел. Так что, какое это имеет отношение к алгоритмам?
Кстати есть такая книжка Python Algorithms. Рекомендую почитать.
Здравствуйте, __kot2, Вы писали:
__>меня просто вырвет, если я попробую написать что-то на Actionscript или написать длинный sql запрос.
Умница, хоть кто-то тут есть здоровый на голову.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, ononim, Вы писали: O>>Эот очень субъективно и вообще дело привычки. Раньше мне тоже i++ больше нравилось, а теперь наоборот, и ваще меня коробит и я переделываю в префиксный инкремент везде где под руку подворачивается __>не, ну меня тоже многие вещи коробят, например в приведенном коде конкретно DWORD, printf, в меньшей степени wmain и wchar_t, но я терпимо отношусь к любым рабочим решениям в принципе.
DWORD, printf, etc в данном коде есть мелочи по сравнению с алгоритмическим идиотизмом. Например с использованием set. Кстати, любой приличный оптимизатор выкинет из релиз код вложеный "пустой" цикл. И на сравнени "релиз" и "дебаг" мы получим не очень адекватные циферки — алгоритм поменялся.
E>DWORD, printf, etc в данном коде есть мелочи по сравнению с алгоритмическим идиотизмом. Например с использованием set. Кстати, любой приличный оптимизатор выкинет из релиз код вложеный "пустой" цикл. И на сравнени "релиз" и "дебаг" мы получим не очень адекватные циферки — алгоритм поменялся.
Алгоритм — не вещь в себе, а в данном случае он здесь — лишь средство демонстрации _возможности_наличия_ разницы. Отсюда и DWORD — потому что GetTickCount имеет меньше накладных расходов чем CRTшный clock. А printf — ну я немного старомоден
set здесь как раз таки потому что у него итератор надеюсь тяжелее чем у вектора. Вообще итераторы бывают самописные, а не только у стандартных контейнеров, и может так оказаться, что они будут намного толще и с побочками, изза которых оптимизатор не выкинет лишнюю копию итератора от постфиксного инкремента.
Цикл оптимизатор не выкинул — спасибо ему на этом, а то пришлось бы вставлять вычитывание элементов в volatile переменную.
Оптимизаторы работают не одинаково на всех платформах. Более того — оптимизация MSVC по размеру (а это — не дебаг) оставила разницу.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, мыщъх, Вы писали:
М>известно ведь, что:
М>1) не самый востребованный язык (уже жаловались, что вакансий на java больше); М>2) язык далеко не самый быстрый, доступный и легкий в плане обучения; М>3) средние зарплаты программиста на плюсах не самые высокие;
М>вывод -- учить плюсы, чтобы заработать много денег -- смысла нет. что же тогда толкает на его изучение?
+100 к ЧСВ, и сразу на форум — меряться, у кого оно больше
Здравствуйте, ononim, Вы писали:
O>Алгоритм — не вещь в себе, а в данном случае он здесь — лишь средство демонстрации _возможности_наличия_ разницы. Отсюда и DWORD — потому что GetTickCount имеет меньше накладных расходов чем CRTшный clock. А printf — ну я немного старомоден
Вы не внимательно читаете. Как я уже говорил DWORD, printf, wmain — это мелочи, которые относятся к стилю написания. А вот GetTickCount имеет меньше накладных расходов чем CRTшный clock — это уже серьезные пробелы в алгоритмической части. В данном случае скорость выполнения этой функции нам вообще не важна — ибо временные затраты k на вызов и выполнение вносят всего лиш ~2*k, где k/(n*T) -> 0 при большом числе n итераций (T — это период выполнения итерации). Т.е., фактически, при любом значение k мы можем выбрать такое число тестовых итераций, что величина k/(n*T) будет сильно меньше погрешности измерения времени. Плюс, выбор GetTickCount очень плох — у нее очень большая погрешность (гораздо больше 1мс), обычно ее значение растет шагами по 200-300мс — это очень много. Соответсвенно число шагов в несколько тысяч недостаточно для уверенной оценки.
O>set здесь как раз таки потому что у него итератор надеюсь тяжелее чем у вектора. Вообще итераторы бывают самописные, а не только у стандартных контейнеров, и может так оказаться, что они будут намного толще и с побочками, изза которых оптимизатор не выкинет лишнюю копию итератора от постфиксного инкремента.
Мерять надо не абсолютную величину, а разницу для цикла с префиксным и постфиксным оператором, внутри одного и того же исполняемого образа. То что вы меряли — подправим соберем и померим, потом опять подправим цикл соберем и померяем уже само по себе может дать далекие от реальности цифры (например ОС начала при повторном измерении свопится), либо оптимизатор полностью переделал скелет программы.
O>Оптимизаторы работают не одинаково на всех платформах. Более того — оптимизация MSVC по размеру (а это — не дебаг) оставила разницу.
Оптимизация по размеру (точнее ее выключение) скорее всего развернула цикл, в результате разница получилась за счет отсутсвия джампов. Кстати да, обычно пр тестах, чтобы минимизировать влияние джампов, вручную раскатывают циклы. Плюс к этому, как я уже говорил, меряют разницу а не абсолютные значения.
O>>Алгоритм — не вещь в себе, а в данном случае он здесь — лишь средство демонстрации _возможности_наличия_ разницы. Отсюда и DWORD — потому что GetTickCount имеет меньше накладных расходов чем CRTшный clock. А printf — ну я немного старомоден E>Вы не внимательно читаете. Как я уже говорил DWORD, printf, wmain — это мелочи, которые относятся к стилю написания. А вот GetTickCount имеет меньше накладных расходов чем CRTшный clock — это уже серьезные пробелы в алгоритмической части. В данном случае скорость выполнения этой функции нам вообще не важна — ибо временные затраты k на вызов и выполнение вносят всего лиш ~2*k, где k/(n*T) -> 0 при большом числе n итераций (T — это период выполнения итерации). Т.е., фактически, при любом значение k мы можем выбрать такое число тестовых итераций, что величина k/(n*T) будет сильно меньше погрешности измерения времени. Плюс, выбор GetTickCount очень плох — у нее очень большая погрешность (гораздо больше 1мс), обычно ее значение растет шагами по 200-300мс — это очень много. Соответсвенно число шагов в несколько тысяч недостаточно для уверенной оценки.
Во клонит вас в сухие алгоритмы, а я смотрю на вещи со стороны жизни
100 мсек — это почти минимальная разница которую имеет смысл намерять, ввиду того что в винде размер time slice'а выделяемого консольным процессам — 90 мсек.
А для 100 мсек мне пришлось ждать уже 6 секунд на эксперимент, что меня уже немного утомляло.
Внесение дополнительной погрешности в мерялку возможно повлекло бы за собой необходимость увеличения времени эксперимента, что меня бы утомляло еще больше. А может и не повлекло бы, но я изначально писал код чтобы минимизировать последующее время его юзания, которое включает в себя его запуск и модификацию, если вдруг оказалось бы что нуна чтото менять. Потому я сразу взял максимально тяжелый контейнер и максимально быструю мерялку. А на алгоритм, как вещь в себе — мне пофиг с большего Возможно с помощью этого минимального кода я бы не намерял разницу — тогда бы я написал свой контейнер с итератором который в конструкторе/деструкторе делает Sleep, для эмуляции толстого итератора, но слава оптимизатору, не пришлось — обошлось минимальным примером, использующим максимальные граничные предположения о стандартных контейнерах и функциях.
O>>set здесь как раз таки потому что у него итератор надеюсь тяжелее чем у вектора. Вообще итераторы бывают самописные, а не только у стандартных контейнеров, и может так оказаться, что они будут намного толще и с побочками, изза которых оптимизатор не выкинет лишнюю копию итератора от постфиксного инкремента. E>Мерять надо не абсолютную величину, а разницу для цикла с префиксным и постфиксным оператором, внутри одного и того же исполняемого образа. То что вы меряли — подправим соберем и померим, потом опять подправим цикл соберем и померяем уже само по себе может дать далекие от реальности цифры (например ОС начала при повторном измерении свопится), либо оптимизатор полностью переделал скелет программы. O>>Оптимизаторы работают не одинаково на всех платформах. Более того — оптимизация MSVC по размеру (а это — не дебаг) оставила разницу. E>Оптимизация по размеру (точнее ее выключение) скорее всего развернула цикл, в результате разница получилась за счет отсутсвия джампов. Кстати да, обычно пр тестах, чтобы минимизировать влияние джампов, вручную раскатывают циклы. Плюс к этому, как я уже говорил, меряют разницу а не абсолютные значения.
Фишка в том что пофиг ПОЧЕМУ разница. Главное что РАЗНИЦА ЕСТЬ И раз она есть — значит она МОЖЕТ БЫТЬ. ЧТД.
Как много веселых ребят, и все делают велосипед...
Re[10]: Учить С++ сложно и трудно, а платят меньше
O>Возможно с помощью этого минимального кода я бы не намерял разницу — тогда бы я написал свой контейнер с итератором который в конструкторе/деструкторе делает Sleep, для эмуляции толстого итератора,
Вот, взял и написал, вернее благодаря своей природной лени кодить (лень — необходимейшая черта любого программера ИМХО ) переделал пример с кодепрожекта, добавив Sleep(100) в деструктор итератора: http://zalil.ru/32416421
Разница на итерировании по 10 элементам — 400msec vs 2400msec. Даже больше и совсем не так, как я ожидал, но да фиг с ним.
На маячащий на горизонте вопрос "А откуда в иераторее Sleep?) предложу потенциальную возможность существования итераторов по файлам/БД, создающих отдельный хэндл/конекшн на инстанс самого итератора. Вопрос эффективности таких итераторов оставим за скобками, факт что они могут быть. + факт того что при некоторых настройках оптимизации на некоторых платформах имеется разница в стандартных контейнерах — то какой смысл спрашивается писать i++, а не ++i, просто потому что "так привык"? Неправильно вы привыкли, фигли
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, MescalitoPeyot, Вы писали:
C>Учитывая, что Андроид существует в публичном виде менее 6 лет, то график слегка веселит.
Не менее веселит то, что, судя по графику, после 7 лет опыта в embedded начинают платить меньше
-----
Любимая фраза физика-теоретика: "Вот видите, мы ошиблись всего лишь на порядок".
Здравствуйте, __kot2, Вы писали:
__>программирование на С++ это и есть соб-но программирование, другие языки — лишь попытки упрощения некоторых достаточно узких областей.
Странное заявление. Не затруднит ли аргументировать?
Здравствуйте, 0x7be, Вы писали: 0>Здравствуйте, __kot2, Вы писали: __>>программирование на С++ это и есть соб-но программирование, другие языки — лишь попытки упрощения некоторых достаточно узких областей. 0>Странное заявление. Не затруднит ли аргументировать?
когда появлялся веб и все пользовались нетскейпом мы написали свой первый игровой веб-сервер. он был на С++. потом я еще писал несколько плагинов, которые забирали инфу с бева и прокси-сервера. тоже на ++. но С++ действительно не совсем удобен в этом плане, приходится разбирать текст и нужен более удобный инструмент разбора текста, который к тому же без всякого гемора работает с юникодом. только поэтому и появились (или появились раньше но получили популярность) веб-языки типа perl, php — это все языки быстрого разбора текста. для тех, кто из всего С++ использовал только работу с текстом и ему неохота было разбираться во всем остальном.
в ембедеде и в вебе у криворуких программистов С++ были проблемы — приложения падали и глючили в многопоточности. к тому же работа с БД в С++ никогда удобством не отличалась, а для веба это было очень нужно. Чтобы приложения не падали С++ урезали, сильно проработали над исключениями, занесли код в виртуальную машину и запретили программисту ручками лезть в память. чтобы многопоточность не глючила внесли синхронизацию в язык, для ускорения работы с БД и разбором текста поработали над строками. получилась Java. Microsoft захотел так же, склонировал ее, но решил заодно убить Delphi и сделал так, что в C# очень удобно стало формочки делать.
Javascript это язык позволяющий оживить интерфейс странички. больше он ничего не умеет. это вообще язык дизайнера, а не программиста. вот хочется, чтобы менюшка выплывала слева — вот, javascript.
Lua это язык на котором пишутся скрипты игровых уровней. если бы не было игр, то не было бы Lua.
Ruby вообще был написал японцем. страна, в которой нет своей школы программирования. это в чистом виде велосипед, созданный из-за того, что человек не понял, как пользоваться другим.
Actionscript это была попытка повышения абстрактной никому не понятной интерактивности интернета. этот язык имел настолько ущербные концепции, и был написан такими жопорукими идиотами, что его в конце концов решили пристрелить. даже такая огромная компания как Adobe не смогла своим авторитетом заставить людей использовать этот кал.
Здравствуйте, abibok, Вы писали:
F>>Итак С++ — мощная низкоуровневая пушка с кучей возможностей, на этом звере написано почти все крутое и самое сложное )
A>Что, по вашему мнению, в С++ низкоуровнего и о какой куче возможностей, которых нет в других языках, идет речь?
Например, прямой доступ к памяти.
F>>Код на С++ быстрее и эффективнее остальных
A>Как вы понимаете "эффективнее" и чем это отличается от "быстрее"?
Можно ещё уменьшить количество использования оперативной памяти, увеличить шанс попадания в кэш процесоора.
F>>В общем требует четкого понимания что ты делаешь
A>А какая область человеческой деятельности не требует четкого понимания что ты делаешь? На каком языке можно писать программы в стиле "что-то как-то само собой получилось, не знаю даже как это вышло"?
В С++ понимать приходится некоторые детали, которые совершенно не относятся к решаемой задаче.
F>>ты должен понимать почему в цикле нельзя определять переменные, а должен их выносить на уровень выше
Это не аргумент fromegg. Подобное надо будет делать и в других языках (при условии что там есть переменные и циклы).
F>>+ контроль использования памяти
A>Сделал new — сделай delete. Что в этом эзотерического, переводящего С++ в разряд чего-то элитарного?
Это очень сложно. Ведь создают и удаляют в разных местах.
Реализация очень многих алгоритмов упрощается, когда не надо думать об освобождении памяти.
Например простая функция чтения строки с консоли. gets какая-нибудь. Вот как её написать?
Представьте себя её проектировщиком?
Если она принимает указатель на массив и заполняет его, то есть вероятность получить переполнение буфера. Если передавать её размер массива, то что делать, если не хватило? Да и пользователь должен правильно вычислить этот размер. А иногда ещё и массив удалить.
Если выделять память внутри, и возвращать на неё указатель, то кто должен освобождать эту память? Можно сделать какую-нибудь функцию delete_after_get и написать в комментариях, что пользователь должен её использовать. И надеяться, что он читает комментарии.
Можно иметь свой статический буфер и возвращать указатель на него. Но опять же переполнение, плюс пострадает многопоточность.
Ладно, сложности реализации — это на писателях библиотек, но пользоваться ими тоже сложно, т.к. везде нашли свои решения, и надо обо всех их помнить.
Здравствуйте, __kot2, Вы писали:
__>Actionscript это была попытка повышения абстрактной никому не понятной интерактивности интернета. этот язык имел настолько ущербные концепции, и был написан такими жопорукими идиотами, что его в конце концов решили пристрелить. даже такая огромная компания как Adobe не смогла своим авторитетом заставить людей использовать этот кал.
Тем не менее, у него очень мощное коммунити и годные зарплаты разработчиков.
Просто его ниша — не корпоративная разработка формочек, а браузерные игры и интерактивные презентации/тачскрины.
То что программу на BrainFuck трудно читать никак не мешает самому языку BrainFuck быть простым для изучения. И говорит лишь о том, что у этого языка не хватает удобных и выразительных средств для представления данной функциональности. На любом языке можно написать страшную абракадабру, с целью оптимизации или запутывания. Однако для большинства практических задач язык остается достаточно простым в плане "прочитать код и понять как он соотносится с алгоритмом" даже для новичка. Чтобы начать программировать на С++, читать и понимать исходники stl или boost совсем не обязательно. Boost — не язык С++, а библиотека написанная на С++. Видите разницу?
Здравствуйте, mtnl, Вы писали: M>Тем не менее, у него очень мощное коммунити и годные зарплаты разработчиков. M>Просто его ниша — не корпоративная разработка формочек, а браузерные игры и интерактивные презентации/тачскрины.
Люди вообще бесконечно разные. Но для меня actionscript, php, perl находятся в голове в той же части, где Киркоров, куклы Братц и целующиеся мужики — это какой-то невероятно жалкий блювотный отстой, хотя, конечно же, имеющий свое коммюнити. мне иногда даже кажется, что запуская редактор с php или там javascript ты оскорбляешь комп, так же, как ставя на новый Порш 911 резину Кама. мне было бы очень стыдно кому-то признаться, что я делаю подобные вещи как слушаю Киркорова, целуюсь с мужиками или пишу на perl
A>>Что, по вашему мнению, в С++ низкоуровнего и о какой куче возможностей, которых нет в других языках, идет речь? A>Например, прямой доступ к памяти.
Засчитывается. Что еще? Ведь речь шла о какой-то куче возможностей.
A>В С++ понимать приходится некоторые детали, которые совершенно не относятся к решаемой задаче.
Например? Только давайте не рассматривать оптимизацию.
A>>Сделал new — сделай delete. Что в этом эзотерического, переводящего С++ в разряд чего-то элитарного?
A>Это очень сложно. Ведь создают и удаляют в разных местах. A>Реализация очень многих алгоритмов упрощается, когда не надо думать об освобождении памяти. A>Например простая функция чтения строки с консоли. gets какая-нибудь. Вот как её написать? A>Представьте себя её проектировщиком? A>Если она принимает указатель на массив и заполняет его, то есть вероятность получить переполнение буфера. Если передавать её размер массива, то что делать, если не хватило? Да и пользователь должен правильно вычислить этот размер. А иногда ещё и массив удалить. A>Если выделять память внутри, и возвращать на неё указатель, то кто должен освобождать эту память? Можно сделать какую-нибудь функцию delete_after_get и написать в комментариях, что пользователь должен её использовать. И надеяться, что он читает комментарии. A>Можно иметь свой статический буфер и возвращать указатель на него. Но опять же переполнение, плюс пострадает многопоточность. A>Ладно, сложности реализации — это на писателях библиотек, но пользоваться ими тоже сложно, т.к. везде нашли свои решения, и надо обо всех их помнить.
Давайте не путать язык и написание приложений на этом языке. Ваши примеры говорят о том, что С++ неудобен для написания больших и сложных систем. При этом сам язык остается простым.
Здравствуйте, abibok, Вы писали:
C>>Берёшь boost::variant и читаешь. Может поймёшь. A>То что программу на BrainFuck трудно читать никак не мешает самому языку BrainFuck быть простым для изучения. И говорит лишь о том, что у этого языка не хватает удобных и выразительных средств для представления данной функциональности. На любом языке можно написать страшную абракадабру, с целью оптимизации или запутывания.
Алгоритм внутри boost::variant просто и примитивен. Проблема как раз с языком — в нём очень много сложных и тонких моментов.
C>Алгоритм внутри boost::variant просто и примитивен.
Алгоритм может быть и прост, но С++ не хватает встроенных средств для эффективного (лаконичного) выражения этого алгоритма.
C>Проблема как раз с языком — в нём очень много сложных и тонких моментов.
Приведите примеры сложных и тонких моментов языка С++.
Здравствуйте, abibok, Вы писали:
C>>Алгоритм внутри boost::variant просто и примитивен. A>Алгоритм может быть и прост, но С++ не хватает встроенных средств для эффективного (лаконичного) выражения этого алгоритма.
Ага.
C>>Проблема как раз с языком — в нём очень много сложных и тонких моментов. A>Приведите примеры сложных и тонких моментов языка С++.
2-phase lookup, слово typename и template — я до сих пор не помню все правила, когда они нужны. Сюда же анонимные namespace'ы, неявные преобразования и SFINAE.
Здравствуйте, abibok, Вы писали:
C>>Алгоритм внутри boost::variant просто и примитивен.
A>Алгоритм может быть и прост, но С++ не хватает встроенных средств для эффективного (лаконичного) выражения этого алгоритма.
C>>Проблема как раз с языком — в нём очень много сложных и тонких моментов.
A>Приведите примеры сложных и тонких моментов языка С++.
Приоритеты (и не только) операторов, множественное + виртуальное наследование, поиск подходящей перегруженной функции, шаблоны и дедукция типов. Продолжать?
Здравствуйте, о_О, Вы писали: о_О>Приоритеты (и не только) операторов, множественное + виртуальное наследование, поиск подходящей перегруженной функции, шаблоны и дедукция типов. Продолжать?
все это высасывание из пальца. если в проекте есть проблемы подобного рода, то код гавно. в нормальном коде таких проблем не возникает.
с приоритетом операторов в коротких выражения вопросов не возникает, а если и возникает, то специально скобочки ставят.
множественное наследование просто и примитивно.
если возникает вопрос а какая же ф-ия тут будет вызвана, то есть просто путаница с именованием ф-ий, а не проблема с множественным наследованием или поиском перегруженной ф-ией. в нормальном коде это варианты однозначные.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, mtnl, Вы писали:
M>> мне было бы очень стыдно кому-то признаться, что я делаю подобные вещи как слушаю Киркорова, целуюсь с мужиками или пишу на perl
По-моему Perl в этом списке -- лишний. Вообще Perl (либо Python) м.б. очень полезен для написания всякого рода вспомогательных скриптов (сборка дистрибутивов, генерация чего-либо при сборке и т.д и т.п), по крайней мере на никсах.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, о_О, Вы писали: о_О>>Приоритеты (и не только) операторов, множественное + виртуальное наследование, поиск подходящей перегруженной функции, шаблоны и дедукция типов. Продолжать? __>все это высасывание из пальца. если в проекте есть проблемы подобного рода, то код гавно. в нормальном коде таких проблем не возникает. __>с приоритетом операторов в коротких выражения вопросов не возникает, а если и возникает, то специально скобочки ставят. __>множественное наследование просто и примитивно. __>если возникает вопрос а какая же ф-ия тут будет вызвана, то есть просто путаница с именованием ф-ий, а не проблема с множественным наследованием или поиском перегруженной ф-ией. в нормальном коде это варианты однозначные.
Что сложного в приоритетах операторов?
о_О>множественное + виртуальное наследование
Мы договорились не смешивать сложность изучения языка и сложность изучения концепций программирования. ООП пришлось бы изучать для любого языка. Реализовать множественное наследование в С++ очень просто.
о_О>поиск подходящей перегруженной функции, шаблоны и дедукция типов.
Снова не вижу ничего принципиально сложного, что требовало бы месяцев корпения над учебниками.
Здравствуйте, abibok, Вы писали:
A>Например? Только давайте не рассматривать оптимизацию.
A>>>Сделал new — сделай delete. Что в этом эзотерического, переводящего С++ в разряд чего-то элитарного?
A>>Это очень сложно. Ведь создают и удаляют в разных местах. A>>Реализация очень многих алгоритмов упрощается, когда не надо думать об освобождении памяти. A>>Например простая функция чтения строки с консоли. gets какая-нибудь. Вот как её написать? A>>Представьте себя её проектировщиком? A>>Если она принимает указатель на массив и заполняет его, то есть вероятность получить переполнение буфера. Если передавать её размер массива, то что делать, если не хватило? Да и пользователь должен правильно вычислить этот размер. А иногда ещё и массив удалить. A>>Если выделять память внутри, и возвращать на неё указатель, то кто должен освобождать эту память? Можно сделать какую-нибудь функцию delete_after_get и написать в комментариях, что пользователь должен её использовать. И надеяться, что он читает комментарии. A>>Можно иметь свой статический буфер и возвращать указатель на него. Но опять же переполнение, плюс пострадает многопоточность. A>>Ладно, сложности реализации — это на писателях библиотек, но пользоваться ими тоже сложно, т.к. везде нашли свои решения, и надо обо всех их помнить.
A>Давайте не путать язык и написание приложений на этом языке. Ваши примеры говорят о том, что С++ неудобен для написания больших и сложных систем. При этом сам язык остается простым.
Действительно давайте не путать язык с тем что нужно для написания приложений. Ведь обычно ценится умение написания приложений, а не уровень "языкофичи знаю, но лыжи не едут".
__>Здравствуйте, ononim, Вы писали: O>>Эот очень субъективно и вообще дело привычки. Раньше мне тоже i++ больше нравилось, а теперь наоборот, и ваще меня коробит и я переделываю в префиксный инкремент везде где под руку подворачивается __>не, ну меня тоже многие вещи коробят, например в приведенном коде конкретно DWORD, printf, в меньшей степени wmain и wchar_t, но я терпимо отношусь к любым рабочим решениям в принципе.
Ононим прав. Зачем полагаться на ключи и различия компиляторов если сам язык говорит что префиксная форма будет быстрее (для user defined типов)? Может вначале префиксная форма и выглядит необычно но если есть возможность сделать сразу лучше не закладываясь на особенности компилятора, то почему бы это сразу не сделать?
Я тоже всегда пишу префиксную форму (даже для встроенных типов) и, имхо, в Гугловском кодинг стайле говорилось использовать только префиксную форму.
C>>>Берёшь boost::variant и читаешь. Может поймёшь. A>>То что программу на BrainFuck трудно читать никак не мешает самому языку BrainFuck быть простым для изучения. И говорит лишь о том, что у этого языка не хватает удобных и выразительных средств для представления данной функциональности. На любом языке можно написать страшную абракадабру, с целью оптимизации или запутывания. C>Алгоритм внутри boost::variant просто и примитивен. Проблема как раз с языком — в нём очень много сложных и тонких моментов.
C
А скрипка эта звучала
Em
Все чище и все сильней,
A7 Dm
Просто-напросто дело не в скрипке,
Fm G C Em
А в том, кто играет на ней.
A7 Dm
Просто-напросто дело не в скрипке,
Fm G C
А в том, кто играет на ней.
A>>Приведите примеры сложных и тонких моментов языка С++.
о_О>Приоритеты (и не только) операторов, множественное + виртуальное наследование, поиск подходящей перегруженной функции, шаблоны и дедукция типов. Продолжать?
о_О>>поиск подходящей перегруженной функции, шаблоны и дедукция типов.
A>Снова не вижу ничего принципиально сложного, что требовало бы месяцев корпения над учебниками.
Ты действительно ничего не понял. Настоящий С++ программист (согласно этому о_О и прочим) должен прочитать и усвоить Страуструпа, зазубрить весь стандарт, опять-таки прочитать и усвоить книги Саттера, Мейерса, Александреску, Джоссутиса, Вандервуда и прочих. И так несколько раз. А если учитывать что появляются и новые авторы, то становится понятно что и всей жизни не хватит чтобы называться настоящим С++ программистом.
О программировании речь не идет вообще, только о чтении. В тех случаях когда таких товарищей допускают до проекта, то их святая обязанность зафигачить в код и темлейты и множественное наследование и всевозможные фичи языка которые им прийдут на ум.
P.S. Почему-то данный феном присущ больше всего С++ программистам.
P.P.S. Я тоже С++ программер но в такой маразм не впадаю.
ПМ>>Человек, который хорошо в нем ориентируется — это хорошее зубрилко а не хороший программист. Умение героически преодолевать трудности, ПМ>которые создает твой собственный инструмент, вместо того, чтобы решать непосредственно прикладную задачу, в современно мире ценится разве ПМ>что только среди прыщавых сосок. K>Человек, который хорошо в нем ориентируется — это профессионал. Если понимаешь как всё работает — то никаких трудностей не возникает.
Немного не так. Человек который зазубрил стандарт называется несколько иначе. Сам можешь догадаться как.
Те же кто понимают что из плюсов можно и нужно использовать небольшое подмножество для решения реальных проблем и есть software engineers.
ПМ>>Работодатель же это сомнительное умение не ценит, и совершенно справедливо. K>Работодатели имеют на этот счёт другую точку зрения.
Нормальные работадатели как раз-таки неодобряют любовь большинства "С++ программистов" тащить в код всевозможные фичи языка. Только, повторюсь, это не проблема языка а тех кто его так использует.
Здравствуйте, Олег К., Вы писали:
C>>Берёшь boost::variant и читаешь. Может поймёшь. ОК>Без буст::вейриэнт никак не обойтись в работе?
Можно. Однако, как иллюстрация сложности языка — вполне себе пример.
C>>>Берёшь boost::variant и читаешь. Может поймёшь. ОК>>Без буст::вейриэнт никак не обойтись в работе? C>Можно. Однако, как иллюстрация сложности языка — вполне себе пример.
Тем не менее, кто-то будет создавать эти сложности на пустом месте а кто-то напишет нормальный код. Так что, имхо, дело все-таки не в языке.
Здравствуйте, Олег К., Вы писали:
C>>>>Берёшь boost::variant и читаешь. Может поймёшь. ОК>>>Без буст::вейриэнт никак не обойтись в работе? C>>Можно. Однако, как иллюстрация сложности языка — вполне себе пример. ОК>Тем не менее, кто-то будет создавать эти сложности на пустом месте а кто-то напишет нормальный код. Так что, имхо, дело все-таки не в языке.
А что в boost::variant ненормального? Это полезнейший компонент для тех задач, где он нужен.
И никто не гарантирует, что в проекте, над которым ты будешь работать, нет подобных местных особенностей. Именно поэтому С++ и сложнее — всё равно много надо знать.
C>>>>>Берёшь boost::variant и читаешь. Может поймёшь. ОК>>>>Без буст::вейриэнт никак не обойтись в работе? C>>>Можно. Однако, как иллюстрация сложности языка — вполне себе пример. ОК>>Тем не менее, кто-то будет создавать эти сложности на пустом месте а кто-то напишет нормальный код. Так что, имхо, дело все-таки не в языке. C>А что в boost::variant ненормального? Это полезнейший компонент для тех задач, где он нужен.
За более чем десять лет не понадобился сам буст не говоря уж об ихнем вейриэнте. Единственное что на ум полезного приходит оттуда это смарт-пойнтеры и регулярные выражения.
C>И никто не гарантирует, что в проекте, над которым ты будешь работать, нет подобных местных особенностей. Именно поэтому С++ и сложнее — всё равно много надо знать.
Если поддерживать код написанный "гениями," то да, согласен. Знать нужно много. Если писать нормальный код с нуля, то процентов 30 максимум.
Здравствуйте, Олег К., Вы писали:
A>>>Приведите примеры сложных и тонких моментов языка С++.
о_О>>Приоритеты (и не только) операторов, множественное + виртуальное наследование, поиск подходящей перегруженной функции, шаблоны и дедукция типов. Продолжать?
ОК>Чувак, ты все это используешь в реальном коде?
да. а что, реальные потцоны не используют перегрузку операторов, фигачат агрегацией и композицией, и всё процедурненько и без шаблонов?
да и, что значит "реальный код"? у тебя есть публичные библиотеки? покажи. или ты настолько крут, что пишешь только за деньги, а весь твой реальный код за 7 печатями?
Здравствуйте, abibok, Вы писали:
о_О>>Приоритеты (и не только) операторов
A>Что сложного в приоритетах операторов?
о_О>>множественное + виртуальное наследование
A>Мы договорились не смешивать сложность изучения языка и сложность изучения концепций программирования. ООП пришлось бы изучать для любого языка. Реализовать множественное наследование в С++ очень просто.
о_О>>поиск подходящей перегруженной функции, шаблоны и дедукция типов.
A>Снова не вижу ничего принципиально сложного, что требовало бы месяцев корпения над учебниками.
да... видимо я дурак. надо было брать "цэпэпэ за 21 день" и начинать фигачить реальный код на реальных задачах, а я столько времени уже потратил впустую
Здравствуйте, о_О, Вы писали:
о_О>Здравствуйте, Олег К., Вы писали:
A>>>>Приведите примеры сложных и тонких моментов языка С++.
о_О>>>Приоритеты (и не только) операторов, множественное + виртуальное наследование, поиск подходящей перегруженной функции, шаблоны и дедукция типов. Продолжать?
ОК>>Чувак, ты все это используешь в реальном коде?
о_О>да. а что, реальные потцоны не используют перегрузку операторов, фигачат агрегацией и композицией, и всё процедурненько и без шаблонов?
И фигачат скобки почище лисперов, что бы приоритеты не заюзать ни дай бог в реальном проекте.
о_О>да... видимо я дурак. надо было брать "цэпэпэ за 21 день" и начинать фигачить реальный код на реальных задачах, а я столько времени уже потратил впустую
Какая часть из этого времени была потрачена на изучение С++, а не на изучение программирования вообще? Какой раздел С++ вы изучаете в настоящий момент?
Re[10]: Учить С++ сложно и трудно, а платят меньше
Здравствуйте, abibok, Вы писали:
о_О>>да... видимо я дурак. надо было брать "цэпэпэ за 21 день" и начинать фигачить реальный код на реальных задачах, а я столько времени уже потратил впустую
A>Какая часть из этого времени была потрачена на изучение С++, а не на изучение программирования вообще? Какой раздел С++ вы изучаете в настоящий момент?
На C++ потратил 1 месяц зубря 8 часов в сутки. Это был Липпман. Я подтверждаю что сам по себе C++ не трудный и красивый, но объемный и содержит много тонкостей. И трудности проявляются, когда мы начинаем всё это применять.
Здравствуйте, Gradient, Вы писали:
C>>Учитывая, что Андроид существует в публичном виде менее 6 лет, то график слегка веселит. G>Не менее веселит то, что, судя по графику, после 7 лет опыта в embedded начинают платить меньше
А что вас удивляет? Как по мне это как раз очень показательный график. Я лично далек от эмбеддед (вернее, в моем эмбеддед линукс, кучагерцовые камни и рыночные зарплаты), но знаком с людьми годами работающими в бывших государственных конторах за 400$ или около того. Хз что их там держит. Может программят под какие-то непопулярные контроллеры, а на че-нить новое переключиться невмоготу? Хз.
В принципе, подобное проседание теоретически мог бы показать, к примеру, график зарплаты гуевых разработчиков несколько лет назад: когда новички отправлялись в C# на аутсорс, а старички до последнего сидели на становившеся уже ненужным Delphi и писали какие-то визуализации данных с датчиков в КБ/НИИ за в несколько раз меньшую зарплату.
Здравствуйте, savitar, Вы писали:
S>Здравствуйте, fromegg, Вы писали:
S>У меня тоже есть вопрос который занимает меня уже несколько последних лет, не рискую создавать отдельно треда, но тут позволю себе спрость, интересно, почему на вакансии типа "инженер, программист ембеддед" так мало предлагают, по моим наблюдениям потолок 60. Как мне кажется область знаний должна включать в себя следующее: нужно разбираться в железе, математике, нужно хорошо знать устройство линуха и C/C++ + асм конкретного проца. За PHP/ASP/Java/C# предлагают обычно больше.
В Штатах на embedded в среднем платят выше чем на PHP/ASP/Java/C#.
Я понимаю что много проэктов на Java/C# outsource в Россию.Проэктов на embedded которые outsource очень мало так, как на такие проэкты требутся clearance в Штатах.
о_О>>>да... видимо я дурак. надо было брать "цэпэпэ за 21 день" и начинать фигачить реальный код на реальных задачах, а я столько времени уже потратил впустую
A>>Какая часть из этого времени была потрачена на изучение С++, а не на изучение программирования вообще? Какой раздел С++ вы изучаете в настоящий момент?
о_О>На C++ потратил 1 месяц зубря 8 часов в сутки. Это был Липпман. Я подтверждаю что сам по себе C++ не трудный и красивый, но объемный и содержит много тонкостей. И трудности проявляются, когда мы начинаем всё это применять.
Здравствуйте, о_О, Вы писали:
о_О>Здравствуйте, Олег К., Вы писали:
A>>>>Приведите примеры сложных и тонких моментов языка С++.
о_О>>>Приоритеты (и не только) операторов, множественное + виртуальное наследование, поиск подходящей перегруженной функции, шаблоны и дедукция типов. Продолжать?
ОК>>Чувак, ты все это используешь в реальном коде?
о_О>да. а что, реальные потцоны не используют перегрузку операторов, фигачат агрегацией и композицией, и всё процедурненько и без шаблонов?
Наоборот, реальные пацаны используют все вышеназванные фичи и не только. Я — не реальный пацан.
о_О>да и, что значит "реальный код"? у тебя есть публичные библиотеки? покажи. или ты настолько крут, что пишешь только за деньги, а весь твой реальный код за 7 печатями?
Реальный код это тот за который тебе платят деньги. И да, я настолько крут что пишу код только за деньги.
Re[10]: Учить С++ сложно и трудно, а платят меньше
Здравствуйте, Олег К., Вы писали:
S>>И фигачат скобки почище лисперов, что бы приоритеты не заюзать ни дай бог в реальном проекте.
ОК>Нормальные программисты пишут простые выражения в которых скобки редко когда понадобятся.
Как я понимаю, вычисление дискриминанта квадратного уравнения — тот самый редкий случай, когда нормальному программисту без скобок не обойтись? Или нормальный программист запишет это вычисление в 3 этажа?
Re[12]: Учить С++ сложно и трудно, а платят меньше
S>>>И фигачат скобки почище лисперов, что бы приоритеты не заюзать ни дай бог в реальном проекте.
ОК>>Нормальные программисты пишут простые выражения в которых скобки редко когда понадобятся. S>Как я понимаю, вычисление дискриминанта квадратного уравнения — тот самый редкий случай, когда нормальному программисту без скобок не обойтись? Или нормальный программист запишет это вычисление в 3 этажа?
Чувак, ты никогда не задумывался почему математики ввели дополнительную переменную (ака дискриминант) при решении квадратных уравнений?
Здравствуйте, Олег К., Вы писали:
S>>>>И фигачат скобки почище лисперов, что бы приоритеты не заюзать ни дай бог в реальном проекте.
ОК>>>Нормальные программисты пишут простые выражения в которых скобки редко когда понадобятся. S>>Как я понимаю, вычисление дискриминанта квадратного уравнения — тот самый редкий случай, когда нормальному программисту без скобок не обойтись? Или нормальный программист запишет это вычисление в 3 этажа?
ОК>Чувак, ты никогда не задумывался почему математики ввели дополнительную переменную (ака дискриминант) при решении квадратных уравнений?
Прежде чем ссылаться на математиков, ты бы хоть глянул в вики http://en.wikipedia.org/wiki/Discriminant. Математики не стесняются юзать приоритеты операций и формулу дискриминанта записывают одним выражением без всяких дополнительных обозначений.
Так что там с нормальными программистами?
Здравствуйте, __kot2, Вы писали:
__>но дело в том, что занимался и руководством проектов и вообще руководством своей компанией и могу сказать что это гораздо проще, чем программирование. конечно же это требует навыков и взгляда на жизнь, но определенных навыков для того чтобы начать программировать надо гораздо больше, чем для того, чтобы начать руководить. предметная область у программиста гораздо сложнее. и задачи гораздо более головоломные возникают. грубо говоря программирование это шахматы, а руководство, это крестики-нолики.
Управление компанией, это другая задача. Сравнивать сложность работы некорректно в принципе, все равное что теплое с синим. И директоров как и программистов больше плохих, а не хороших. И чтобы стать хорошим директором нужно ну никак не меньше времени и сил.
M>>явление, достаточно широко описанное в литературе __>а вы наверняка из руководства. потому что инженер имеет аналитический склад ума, никому по дефолту не доверяет и не будет ссылаться на мнение в стиле "все знают, что"
Я не из руководства, но такой эффект понимаю и периодически борюсь с ним (переоценка собственной важности)
Здравствуйте, abibok, Вы писали:
A>Что такое "учить С++"? Вы что, текст стандарта наизусть заучиваете что ли? Что в С++ есть такого, что требовало бы больше месяца на изучение? Не парадигма ООП, не техники оптимизации, не архитектура ОС и WinAPI, не сторонние библиотеки, а именно сам язык С++.
адвансед использование шаблонов, указатели на указатели на указатели — после нескольких лет на языках высокого уровня к этому крайне сложно возвращаться.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, hrensgory, Вы писали:
H>>On 29.12.2011 12:57, Kernan wrote:
H>>Троллинг это конечно арт, но не стоит тешить себя необоснованными K>Я и не тешу. Кто писал да Java и C# знает, что говнокдить на этих языках можно так же как и на других и точно так же ты будешь ловить MemoryException, натыкаться на залоблоченные ресурсы и прочее, прочее, прочее.
Э не. можно конечно, натыкаться на сие, но возникает оно уже чаще всего в вопросах далеко не тривиальных. А в c++ уйти за гранницу выделенной области памяти можно в простейшей программе.
Здравствуйте, Grizzli, Вы писали: G>адвансед использование шаблонов, указатели на указатели на указатели — после нескольких лет на языках высокого уровня к этому крайне сложно возвращаться.
что первое что второе в реальных проектах начинает использоваться тогда когда программисты совсем не знают, чем себя еще занять
Re[14]: Учить С++ сложно и трудно, а платят меньше
S>>>>>И фигачат скобки почище лисперов, что бы приоритеты не заюзать ни дай бог в реальном проекте.
ОК>>>>Нормальные программисты пишут простые выражения в которых скобки редко когда понадобятся. S>>>Как я понимаю, вычисление дискриминанта квадратного уравнения — тот самый редкий случай, когда нормальному программисту без скобок не обойтись? Или нормальный программист запишет это вычисление в 3 этажа?
ОК>>Чувак, ты никогда не задумывался почему математики ввели дополнительную переменную (ака дискриминант) при решении квадратных уравнений? S>Прежде чем ссылаться на математиков, ты бы хоть глянул в вики http://en.wikipedia.org/wiki/Discriminant. Математики не стесняются юзать приоритеты операций и формулу дискриминанта записывают одним выражением без всяких дополнительных обозначений.
Эко тебя понесло. Начал с квадратных уравнений, закончил "мудренной" статье в википедии.
S>Так что там с нормальными программистами?
Перечитай свой вопрос и задай его нормально. На данный момент он не несет особой смысловой нагрузки. Я попытался его домыслить но не хочу продолжать домысливать дальше.
На всякий случай, вот он:
S>>>Как я понимаю, вычисление дискриминанта квадратного уравнения — тот самый редкий случай, когда нормальному программисту без скобок не обойтись? Или нормальный программист запишет это вычисление в 3 этажа?
__>Здравствуйте, Grizzli, Вы писали: G>>адвансед использование шаблонов, указатели на указатели на указатели — после нескольких лет на языках высокого уровня к этому крайне сложно возвращаться. __>что первое что второе в реальных проектах начинает использоваться тогда когда программисты совсем не знают, чем себя еще занять
Или квалификация (как software engineer-а) низка.
Re[15]: Учить С++ сложно и трудно, а платят меньше
Здравствуйте, Олег К., Вы писали:
ОК>Перечитай свой вопрос и задай его нормально. На данный момент он не несет особой смысловой нагрузки. Я попытался его домыслить но не хочу продолжать домысливать дальше.
ОК>На всякий случай, вот он:
Отмотаем пораньше:
S>>>>>>И фигачат скобки почище лисперов, что бы приоритеты не заюзать ни дай бог в реальном проекте.
Я подколол по поводу того что нормальные программисты не используют приоритеты операций, вместо этого фигачат скобки.
ОК>>>>>Нормальные программисты пишут простые выражения в которых скобки редко когда понадобятся.
Ты повелся.
S>>>>Как я понимаю, вычисление дискриминанта квадратного уравнения — тот самый редкий случай, когда нормальному программисту без скобок не обойтись? Или нормальный программист запишет это вычисление в 3 этажа?
Я подкинул реальный пример, в котором либо нужно юзать приоритеты, либо скобки, либо вводить переменные для подвыражений.
ОК>>>Чувак, ты никогда не задумывался почему математики ввели дополнительную переменную (ака дискриминант) при решении квадратных уравнений?
Ты сослался на математиков, что они вводят дополнительные переменные.
S>>Прежде чем ссылаться на математиков, ты бы хоть глянул в вики http://en.wikipedia.org/wiki/Discriminant. Математики не стесняются юзать приоритеты операций и формулу дискриминанта записывают одним выражением без всяких дополнительных обозначений.
ОК>Эко тебя понесло. Начал с квадратных уравнений, закончил "мудренной" статье в википедии.
Я тебя послал на википедию, посмотреть как математики записывают формулу дискриминанта. Математики не используют для записи дискриминанта (квадратного уравнения) дополнительные переменные, и записывают его одним выражением. Надеюсь, вики для тебя достаточно авторитетный ресурс? Если нет — приводи математиков, которые пишут формулу дискриминанта с дополнительными переменными ака
Здравствуйте, savitar, Вы писали:
S>Здравствуйте, fromegg, Вы писали:
S>У меня тоже есть вопрос который занимает меня уже несколько последних лет, не рискую создавать отдельно треда, но тут позволю себе спрость, интересно, почему на вакансии типа "инженер, программист ембеддед" так мало предлагают, по моим наблюдениям потолок 60. Как мне кажется область знаний должна включать в себя следующее: нужно разбираться в железе, математике, нужно хорошо знать устройство линуха и C/C++ + асм конкретного проца. За PHP/ASP/Java/C# предлагают обычно больше.
Есть знакомый С программист QNX, получающий в Москве 5.5K Evro NET в мес.
Видел вакансии Embeded от 160 000 руб в мес, но не видел таких для PHP/ASP/Java/C#
Любой мега-профи в любой из этих областей будет получать 120-150 и более.
Получать 90-120 на С++ с небольшим опытом очень маловероятно, что не скажешь для ASP/Java/C#
Здравствуйте, Олег К., Вы писали:
C>>>>>>Берёшь boost::variant и читаешь. Может поймёшь. ОК>>>>>Без буст::вейриэнт никак не обойтись в работе? C>>>>Можно. Однако, как иллюстрация сложности языка — вполне себе пример. ОК>>>Тем не менее, кто-то будет создавать эти сложности на пустом месте а кто-то напишет нормальный код. Так что, имхо, дело все-таки не в языке. C>>А что в boost::variant ненормального? Это полезнейший компонент для тех задач, где он нужен.
ОК>За более чем десять лет не понадобился сам буст не говоря уж об ихнем вейриэнте. Единственное что на ум полезного приходит оттуда это смарт-пойнтеры и регулярные выражения.
Это ты просто не делал, например, универсальные (т.е., настраиваемые пользователем) читалки из OLEDB. С бустовариантом и т.п. кода получается раза в три меньше, чем с тем же CComVariant или как его там.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, 0x7be, Вы писали:
0>Не претендую на истину, лишь выскажу предположение: многое из того, что раньше писалось на С++ стали писать на других языках => 0>спрос на программистов С++ упал, а на программистов на этих "других языка" вырос.
+1
С++ востребован в кросс-платформенных и критичных к памяти нишах (iOS/Android/консоли).
AG>С++ востребован в кросс-платформенных и критичных к памяти нишах (iOS/Android/консоли).
Вот уж нет уж
На упомянутых платформах С++ как раз не особо нужен.
Где он (пока) еще нужен — в ядерных (kernel) штуках. Не обязательно linux/windows kernel, эт может быть ядро финансовой системы или чего-то еще этакого.
Здравствуйте, fromegg, Вы писали:
F>.. и в связи с этим обучение С++ программиста стоит дороже и есть сложнее, тогда F>почему же на фоне .NET/Java у С++ ниже зп ??? ну где справедливость )
Потому что платят за результат. Тому, кто заказывает программу, глубоко фиолетово на чем ты её пишешь, лишь бы она делала своё дело была дешева в обслуживании. И программы на С++ тут сливают по всем пунктам, не только по вышеперечисленным.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Здравствуйте, Sorc17, Вы писали:
F>>почему же на фоне .NET/Java у С++ ниже зп ??? ну где справедливость )
S>Потому что платят за результат. Тому, кто заказывает программу, глубоко фиолетово на чем ты её пишешь, лишь бы она делала своё дело была дешева в обслуживании. И программы на С++ тут сливают по всем пунктам, не только по вышеперечисленным.
Я просто обожаю этот ресурс. Вот так, бывает, встанешь с утреца, позавтракаешь, купишь на станции кофе, едешь себе на работу да почитываешь чужие мысли. И ведь порой такое отожгут, что запас хорошего настроения остается на весь день, а то и на всю неделю.
Пиши ещё, пожалуйста.
Здравствуйте, landerhigh, Вы писали:
L>Я просто обожаю этот ресурс. Вот так, бывает, встанешь с утреца, позавтракаешь, купишь на станции кофе, едешь себе на работу да почитываешь чужие мысли. И ведь порой такое отожгут, что запас хорошего настроения остается на весь день, а то и на всю неделю. L>Пиши ещё, пожалуйста.
Здравствуйте, Sorc17, Вы писали:
S>Потому что платят за результат. Тому, кто заказывает программу, глубоко фиолетово на чем ты её пишешь, лишь бы она делала своё дело была дешева в обслуживании. И программы на С++ тут сливают по всем пунктам, не только по вышеперечисленным.
Бурные аплодисменты, переходящие в овацию.
Пиши ещё!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, landerhigh, Вы писали:
L>Я просто обожаю этот ресурс. Вот так, бывает, встанешь с утреца, позавтракаешь, купишь на станции кофе, едешь себе на работу да почитываешь чужие мысли. И ведь порой такое отожгут, что запас хорошего настроения остается на весь день, а то и на всю неделю. L>Пиши ещё, пожалуйста.
Ага, это обсуждение — просто феерия. Я тоже слежу с неизменным интересом.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, fromegg, Вы писали:
F>Вопрос, которй меня волнует уже года 3, а внятного ответа еще не находил или хотя бы аргументов )
То что платят за результат, я думаю вам уже понятно. Тогда вопрос где результат на плюсах, ценится больше.
— Системное ПО. В частности антивирусники. Миллионные обороты в этом бизнесе.
— Геймдев. Миллиардные обороты.
— WinRT с появлением Win8.
С++ дает больше возможностей расти, и в плане зарплат, и как специалист.
L>- Системное ПО. В частности антивирусники. Миллионные обороты в этом бизнесе. L>- Геймдев. Миллиардные обороты.
Какое отношение имеют обороты к зарплате? Можно подумать что программисты антивирусов все сплошь миллионеры. Или геймдев — поработай три года и можешь идти на пенсию обеспеченным.
L>С++ дает больше возможностей расти, и в плане зарплат, и как специалист.
Каким образом язык может давать возможности расти как специалист? Как знаток заморочек конктретного языка — может быть. А вот как специалист?
Здравствуйте, abibok, Вы писали:
L>>- Системное ПО. В частности антивирусники. Миллионные обороты в этом бизнесе. L>>- Геймдев. Миллиардные обороты.
A>Какое отношение имеют обороты к зарплате? Можно подумать что программисты антивирусов все сплошь миллионеры. Или геймдев — поработай три года и можешь идти на пенсию обеспеченным.
Если вы работаете долгое время в канторе, с большим оборотом, становитесь тим лидом — однозначно и зарплата растет, а то и часть оборота.
L>>С++ дает больше возможностей расти, и в плане зарплат, и как специалист.
A>Каким образом язык может давать возможности расти как специалист? Как знаток заморочек конктретного языка — может быть. А вот как специалист?
Ключевая мысль — в универсальности языка. Среднего значение по рынку плавает. Если найти свою нишу, и косить там.
Расти как специалист, позволяет понимание низкоуровневых операций в первую очередь. Отсюда следует и универсальность мышления. Спрыгнуть на фреймворки после плюсов, дело пары недель. А вот обратно — вряд ли.
L>Если вы работаете долгое время в канторе, с большим оборотом, становитесь тим лидом — однозначно и зарплата растет, а то и часть оборота.
По началу дополнительные знания о языке действительно помогут карьерному росту. Но начиная с некоторого уровня расти уже некуда — все коллеги уже и так хорошо разбираются в программировании. И тогда начинают цениться совсем другие качества. На практике зачастую мега-гуру в С++ сидят годами без существенного повышения и жалуются на молодежь, которая еще вчера была джуниором, а сегодня уже выбилась в начальники этого программиста.
Получение части оборота фирмы, если вы простой наемный работник, а не co-founder, это исключительно редкое явление. Мне таких случаев не известно ни одного. Вот превентивно уволить слишком опытного и засидевшегося, чтобы не скапливал чересчур много критических знаний в своих руках — это сплошь и рядом. Весьма здоровая практика для защиты проекта и фирмы от капризов и шантажа.
L>Ключевая мысль — в универсальности языка. Среднего значение по рынку плавает. Если найти свою нишу, и косить там.
Вы определитесь: либо универсальность, либо узкая ниша, где платят от безысходности и дефицита кадров.
L>Расти как специалист, позволяет понимание низкоуровневых операций в первую очередь.
У вас довольно наивные представления о том, что такое "специалист".
L>Отсюда следует и универсальность мышления.
Не вижу как из понимания низкоуровневых операций следует универсальность мышления. Скорее даже наоборот.
L>Спрыгнуть на фреймворки после плюсов, дело пары недель. А вот обратно — вряд ли.
Смена языка, по большому счету, вообще не должна никого волновать. Это как сказать "спрыгнуть с напильника на молоток — пара недель". Спрыгивать нужно на более сложные и более масштабные задачи.
Здравствуйте, abibok, Вы писали:
L>>Если вы работаете долгое время в канторе, с большим оборотом, становитесь тим лидом — однозначно и зарплата растет, а то и часть оборота.
A>По началу дополнительные знания о языке действительно помогут карьерному росту. Но начиная с некоторого уровня расти уже некуда — все коллеги уже и так хорошо разбираются в программировании. И тогда начинают цениться совсем другие качества. На практике зачастую мега-гуру в С++ сидят годами без существенного повышения и жалуются на молодежь, которая еще вчера была джуниором, а сегодня уже выбилась в начальники этого программиста.
Мега-гуру в С++ могут сидеть именно сопровождая тонны кода. А могут быть востребованы именно здесь и сейчас.
Примеров помимо геймдева, системного ПО есть.
Начальник вы или джуниор — это вопрос самой личностни. От знания языка мало зависящий .
A>Получение части оборота фирмы, если вы простой наемный работник, а не co-founder, это исключительно редкое явление. Мне таких случаев не известно ни одного. Вот превентивно уволить слишком опытного и засидевшегося, чтобы не скапливал чересчур много критических знаний в своих руках — это сплошь и рядом. Весьма здоровая практика для защиты проекта и фирмы от капризов и шантажа.
Яндекс например. Рамблер, Аби и др. всем известные конторы. Кто был у истоков — владеют акциями. Свои разработки начинают.
Не совсем понимаю — что значит критические знания. И как опыт, может вредить проекту? Кто всем руководить будет,
если не опытный. Каждый винтик внутри знает, и общую картину видит.
L>>Ключевая мысль — в универсальности языка. Среднего значение по рынку плавает. Если найти свою нишу, и косить там.
A>Вы определитесь: либо универсальность, либо узкая ниша, где платят от безысходности и дефицита кадров.
L>>Расти как специалист, позволяет понимание низкоуровневых операций в первую очередь.
A>У вас довольно наивные представления о том, что такое "специалист".
Есть основы программирования для всех, которые никто не отменял. Есть специалист "вглубь" нишевый, есть "вширь",
владеющий базой нескольких областей. Какой больше специалист — еще можно поспорить.
L>>Отсюда следует и универсальность мышления.
A>Не вижу как из понимания низкоуровневых операций следует универсальность мышления. Скорее даже наоборот.
L>>Спрыгнуть на фреймворки после плюсов, дело пары недель. А вот обратно — вряд ли.
A>Смена языка, по большому счету, вообще не должна никого волновать. Это как сказать "спрыгнуть с напильника на молоток — пара недель". Спрыгивать нужно на более сложные и более масштабные задачи.
Так говорите, как будто полная свобода выбора, что кодить, на чем и за какой срок. В шароваре да. Во фрилансе, выбор сужается. В конторе — никакого может не быть выбора. Тема было почему меньше платят за С++. Т.е. вопрос работы на дядю.
L>Мега-гуру в С++ могут сидеть именно сопровождая тонны кода. А могут быть востребованы именно здесь и сейчас.
Это все какие-то теоретические рассуждения. Могут быть востребованы, а могут и не быть. А вот то, что удел бОльшей части С++ников сопровождать древний код — это правда.
A>>Получение части оборота фирмы, если вы простой наемный работник, а не co-founder, это исключительно редкое явление. Мне таких случаев не известно ни одного. Вот превентивно уволить слишком опытного и засидевшегося, чтобы не скапливал чересчур много критических знаний в своих руках — это сплошь и рядом. Весьма здоровая практика для защиты проекта и фирмы от капризов и шантажа.
L>Яндекс например. Рамблер, Аби и др. всем известные конторы. Кто был у истоков — владеют акциями.
Т.е. как я и говорил, не простые работники, а co-founders. Тем кого наняли позже ничего не светит.
L>Свои разработки начинают.
Это косвенно говорит о том, что в исходных конторах без них смогли прекрасно обходиться, а карьерный рост уткнулся в стандартный потолок.
L>Не совсем понимаю — что значит критические знания. И как опыт, может вредить проекту?
Это когда только один человек знает как все работает и не пускает никого в свой код. Тогда любой его каприз "хочу удвоения зарплаты или уйду" или внезапный кирпич на голову означает большие проблемы для проекта. Кроме того, такой проект часто превращается в "игрушку для одного". Когда все решения принимаются единолично и некому возразить или представить альтернативный вариант, проект из средства для зарабатывания денег становится полигоном для модных программистских веяний и полем для экспериментов. По поводу и без пишется море ничего не делающих классов, любая мелочь заворачивается в гору шаблонов и становится универсальной и суперрасширяемой.
Процесс разработки должен быть организован так, чтобы любого человека можно было заменить с разумными затратами по времени и деньгам.
L>Есть основы программирования для всех, которые никто не отменял. Есть специалист "вглубь" нишевый, есть "вширь", L> владеющий базой нескольких областей. Какой больше специалист — еще можно поспорить.
Давайте различать эксперта по языку и специалиста по разработке ПО на этом языке. Если вы не занимаетесь преподаванием или разработкой компиляторов, то первое к вам скорее всего мало применимо. А для разработчика ПО исчерпывающее знание языка — далеко не на первом месте среди приоритетных скилов.
L>Так говорите, как будто полная свобода выбора, что кодить, на чем и за какой срок. В шароваре да. Во фрилансе, выбор сужается. В конторе — никакого может не быть выбора. Тема было почему меньше платят за С++. Т.е. вопрос работы на дядю.
Снова пришли к тому, с чего начинали. Дяде плевать на то, насколько глубоко программист Х знает С++, как и на то, использовался ли при разработке С++ или другой язык. На первом месте — быстрота получения решения, стоимость поддержки и первоначальной стоимость разработки. И получается, что при сопоставимом качестве С++ проигрывает другим языкам везде, кроме определенных ниш. А с другой стороны, С++ников у нас много и потеряв заказчиков в области ширпотребного ПО, все они ломанулись в эти самые узкие ниши. Тем самым сбив рейты за счет бешеной конкуренции. Итого — работа нудная, тяжелая и малооплачиваемая. При этом у С++ников не хватает то ли ума, то ли смелости трезво взглянуть на ситуацию и сделать простейший прогноз на будущее. А потом забыть все что знали и пойти работать туда, где водятся заказчики и деньги. Это потребует не более полугода. Вместо этого они стонут "ох, как несправедлив мир, почему никто не хочет платить деньги за то, что я прочитал десяток книг и запостил статью на хабр...", и все ждут, что однажды все заказчики в мире вдруг одумаются, выгонят быдлокодеров на C#, php, питоне и прочих предательских языках, и станут умолять разработать что-нибудь эх-оптимизированное.