[Hrach_Techie]

очень интересно знать ваши мнения ...

[Tivin]

А с чего это вдруг ??

[Varg]

Флудишь, Грач, щас тут базар недеццкий начнется,
ИМХО не вымрет, т.к. крутые проджект менеджеры ни о каких других языках не слышали

[Bionika]

Vse vimret, i toka iskusstvennie intellektuali budut rabotat' na c++, a mojet i na....

[Varg]

Искусственному интеллекту пофиг на чем писать, дали б пожрать

[nm]

в ближайшем обозримом будущем нет.

пока не наберется критическая масса стартапов. поясню

Стартапы создаются для двух целей - или получить деньги от инвестисционного фонта, поработать какое-то время и сдохнуть или для зарабатывания денег. В первом случае для нормального бизнес плана нужно уметь оценивать риски - вот тут то и выясняется, что такие оценки существуют для цпп, ява и других mailstream языков. этим кормится целая армия консультантов, архитекторов, поректировщиков и т.д. соответственного изначальные затраты на стартап больше -- т.к. помимо чисто программистов нужно покупать еще дополнительныеъ услуги.
в случае когда стартап создается для зарабатывания денег и люди вкладывают сами свои деньги, работают маленьким коллкетивом и у них почти нету факторов, указывающих или ограничивающих их развитие -- то они используют тот продукт/технологию/язык программирования, который более подходит для данной задачи и позволяет рещить ее в более короткие сроки. соответственно очень часто оказывается , что за очень которкое время (п осравнению с проектами на c++/java) программистам удается создать мощный продукт.


если вглядеться в корни такого деления, то оказывается, что все существенно проще ...

есть очень хорошее английское слово - clueless . к сожалению, количество людей у которых нет этого самого клю, сущесственно больше, чем те, у которых оно есть. и если первые практически не способны создавать _новые_ идеи, то вторые как раз этим и занимаются. плюс еще и разница в производительности - smart people могут писать отлаженный код сущесетвенно (3-5-10 раз) быстрее, чем clueless. такая же разница есть и в других областях - начиная от мэнеджмента, кончая технологиями упаковки продуктов

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

чисто исторически C и C++ были нужны что бы писать ПО, которое работает быстро. большая часть процессоров, которые сейчас стоят в PC -- простаивают в ожидании пользовательского ввода. а разницу во времени реакции на нажатие мышкой кнопки -- будет это 10e-5 или 10e-4 секунд, вы не заметите никогда. соответственно можно позволить писать программы на *интерпретируемых* *слабо типизированных* *более медленных* языках *высокого уровня*, которые существенно сокращают количество телодвижений, которые вынужден делать программист для написания программы. чего только стоят усилия c++ и java программистов по обходу строгой типизации и созданию всяческих иерархий наслодования, которые потом катастрофчески сложно расширять или изменять. строгая типизация приводит так-же к существенным проблемам при рефакторинге и при написании автоматических тестов, без которых заниматься рефакторингом - занятие схожее с хождением вслепую по минному полю совмещенному с зыбучими песками -- либо взлетишь на воздух, либо тебя засосет
на даный момент круг задач, которые требуют 100% использования скорости процессора, очень узок. и при этом большая часть проблем идет от неоптимизированнох ОС -- как пример рекомендую почитать сравнение производительности opensource прокси и коммерческих. разница в производительности -- в 5-10 раз. при этом hardware, на котором работают коммерческие прокси может быть слабее, чем те, на которых тестируются opensource.


правка2: цитируя интернет-мысли: выбираю язык программирования вы выбираете не только язык и технологию. вы выбираете среду и способ выражения своих мыслей и вы выбираете community -- тех людей, которые развивают, создают, делются опытом и т.д. отттуда-же: в среднем, выбирая язык программирования Python или Perl вы выбираете более толковых (smart) программистов, чем на Java/C++/VB/C#/PHP. только потому, что овладение этими языками требует больше усилий и знаний.
из не IT жизни -- токарем 6 разряда вы не можете стать сразу. вы должны долго учиться, работать и набираться опыта. зато потом вы способны решать более сложные задачи (вытачивать точнее и более сложные детали) чем другие.

правка3: количество людей зашоренных связкой Windows/VC++/MFC удручающе велико. при том, что это могут быть очень толковые программисты, им почти невозможно объяснять какие-то принципиально другие понятия -- такие как взаимодействующие последовательные процессы, функциональные и логические языки программирования. даже простую вещь -- что модель data container/manager/view существенно эффективнее, чем mfc-шный data/view.




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

[AvDav]

Пациент скорее жив чем мертв. Еще глобально хорошая статья

Загадка: почему так происходит, что некоторые из крупнейших консалтинговых компаний в мире по информационным технологиям делают самую плохую работу?

Почему так случается, что "крутые" новые консалтинговые компании начинают с череды впечатляющих успехов, метеорного взлета, и быстро деградируют до посредственных?

Я размышлял об этом, и думал о том, как Fog Creek Software (моя компания) должна расти. И лучшие уроки, которые я смог найти, пришли из Макдоналдс. Да-да, я имею в виду эту ужасную сеть ресторанов-закусочных.

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

Другой секрет "биг маков" состоит в том, что вы можете иметь IQ (интеллектуальный коэффициент), который колеблется между "идиот"и "баран" (используя технические термины) и все равно вы будете способны выпустить "биг мак", который будет таким же заурядным, как и все другие "биг маки"в мире. Все это потому, что настоящий секретный соус Макдональдса — это его громадное руководство, описывающее в потрясающей детализации точную процедуру, которой каждый владелец франчайза должен следовать при создании "биг мака". Если "биг мак" гамбургер жарится 37 секунд в Анкоридже, Аляска, он будет жариться 37 секунд в Сингапуре - не 36 и не 38. Что бы сделать "биг мак" вы просто должны следовать этим чертовым правилам.

Эти правила были тщательно составлены весьма разумными людьми (там в Университете Гамбургеров Макдональдса) так, чтобы "чайники" могли соблюдать их так же хорошо, как и смышленные люди. На самом деле правила включают все виды предосторожностей, как например звонки, которые звенят, если вы держите картошку в горячем масле слишком долго, которые были созданы, чтобы компенсировать более чем небольшие человеские слабости. В них есть секундомеры и точные времена на все. Есть система, которая должна гарантировать, что уборщик проверяет чистоту туалетов каждые полчаса (Подсказка: они не чистые.)

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

Просто для развлечения давайте сравним повара в Макдональдсе, который в точности следует набору правил и не знает ничего о пище, с таким гением как Обнаженный Шеф-повар, британский красавец Джеми Оливер. (Если вы сейчас решите покинуть этот вебсайт и нажать на этот линк для того, чтобы увидеть видео в стиле MTV о том, как Обнаженный Шеф-повар готовит айоли с базиликом (Прим. переводчика: айоли - густой соус из толченого чеснока, яичных белков, лимонного сока и оливкового масла, который используют с рыбой и овощами), то вот вам мое благословение. Идите на здоровье). В любом случае, сравнение Макдональдс с изысканным шеф-поваром полностью абсурдно, но пожалуйста, придержите недоверие на минуту, потому что здесь есть, чему поучиться.

Итак, Обнаженный Шеф-повар не следует никакому Руководству. Он не измеряет ничего. Когда он готовит, вы видите, как пища летает повсюду, как бы между прочим. "Мы добавим еще немного розмари, это не повредит, и хорошенько встряхнем", говорит он. "Разомнем это все. Отлично. Просто посыпем это все везде." (Да, это действительно выглядит, как будто он просто посыпает все вокруг. Извините, но если я попробую посыпать все равномерно, это не сработает.) Это занимает примерно 14 секунд и он в основном сымровизировал полное изысканное блюдо из поджаренного порезанного морского окуня с приправами, запеченного с картофелем и грибами с салсой-верде (Прим. переводчика: салса-верде: острый соус зеленого цвета). Вкусно.

Хорошо, я думаю, очевидно, что пища "Обнаженного Шеф-повара" лучше, чем то, что вы получите в Макдональдс. Даже если это звучит глупо, давайте спросим, почему. Это вовсе не глупый вопрос. Почему большая компания с несметными ресурсами, невероятным масштабом, доступом к самым лучшим "дизайнерам" пищи, которых можно найти за деньги, и бесконечным оборотом наличных, не может приготовить приличную еду?

Представьте, что Обнаженному Шеф-повару надоело заниматься "телешоу" и он откроет ресторан. Конечно, он блестящий шеф-повар, еда будет бесподобна, так что место будет переполнено клиентами и будет шокирующе прибыльным.

Когда у вас есть шокирующе прибыльный ресторан, вы быстро осознаете, что даже если он заполнен каждый вечер, и даже если вы берете $19 за закуску и $3.95 за кока-колу, ваши прибыли скоро упрутся в естественный предел, потому что один шеф-повар может приготовить ограниченное количество блюд. Тогда вы нанимаете еще одного шеф-повара, и может быть открываете еще рестораны, может быть даже в других городах.

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

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

Проблема: это не работает, как задумано. Существует миллион вещей, который хороший шеф-повар делает, и которые связаны с импровизацией. Хороший повар видит потрясающие манго на фермерском рынке и импровизирует соус из манго и силантро для рыбы в этот день. Хороший повар обходит временную нехватку картофеля, создав чипсы из плодов таро (Прим. переводчика: таро - вид тропического растения). Повар-автомат, который просто следует инструкциям, может быть способен приготовить заданное блюдо, когда все работает идеально, но без настоящего таланта и мастерства он не сможет импровизировать, и именно поэтому вы никогда не увидите хикама (Прим. переводчика: хикама - толстый корень коричневого цвета, внутри белый, используемый в пищу в Латинской Америке. Сладкий и напоминающий по вкусу орех. Особенно хорош для салатов) в Макдональдсе.

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

Подводим итог вышесказанному:

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

Майк был несчастлив. Он нанял громадную компанию консультантов по ИТ для того, чтобы построить Систему. Консультанты по ИТ, которых он нанял, были некомпетентны, все время талдычили о какой-то "Методике", потратили миллионы долларов и не смогли произвести ничего.

К счастью, Майк нашел молодого программиста, который был по-настоящему умен и талантлив. Молодой программист построил всю систему в один день за $20 и пиццу. Майк был в восторге. Он рекомендовал юного программиста всем своим друзьям.

Юный Программист начал делать деньги. Скоро у него было больше работы, чем он мог справиться, и он нанял группу людей для помощи. Хорошие "специалисты" хотели слишком много оплаты акциями, так что он решил нанять еще более молодых программистов прямо из колледжа и "обучить их" в течение шестинедельного курса.

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

Через несколько десятков лет Юный Программист превращается в Громадную Некомпетентную Компанию Консультантов по ИТ с Методикой с большой буквы и многими людьми, которые слепо следуют этой Методике, даже когда она не работает, потому что у них нет абсолютно никакой идеи о том, что еще делать, и они вовсе не талантливые программисты -- они просто средние выпускники различных университетов, которые прослушали шестинедельный курс.

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

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

Но эти правила и процедуры работают только тогда, когда все идет хорошо. Различные консалтинговые компании по "Веб-сайтам с поддержкой баз данных" расплодились в последние пару лет и заполнили свои ряды, обучив различных любителей четырнадцати вещам, которые нужно знать для создания веб-сайтов с поддержкой баз данных ("вот это оператор выбора select, парень, теперь построй Веб-сайт"). Но теперь, когда "доткомы" лопаются и внезапно появился спрос на программированние ГУИ (GUI) высокого уровня, умение работать с C++, и настоящую компьютерную науку, парни, которые имеют только оператор выбора в своем арсенале, должны подняться на слишком крутую лестницу знаний и не могут это сделать. Но они продолжают пробовать, следуя правилам из главы 17 о нормализации баз данных, которые таинственным образом больше неприменимы для Нового Мира. Блестящие основатели этих компаний, конечно, могли бы приспособиться к новому миру: они - талантливые компьютерные ученые, которые могут выучить все, но компании, которые они построили, не могут приспособиться, потому что они заменили талант книгой правил, и эти книги не подходят к новым временам.

В чем мораль этой истории? Опасайся Методик. Они представляют собой отличный способ привести всех к жалкому, но удовлетворительному, уровню выполнения, но в то же время они раздражают более талантливых людей, которым досаждают ограничения, наложенные на них. Мне очевидно, что талантливый повар не будет счастлив, делая бургеры в Макдональдсе, именно из-за правил. Так почему же консультанты по ИТ так много восхваляют свои Методики (Никак не пойму).

Что все это означает для Fog Creek? Стать громадной консалтинговой компанией никогда не было нашей целью. Мы выполняем консалтинговые работы как средство для достижения цели. Наша долгосрочная цель — стать софтверной компанией, которая всегда прибыльна, и мы достигаем нашу цель, выполняя консалтинговые работы для дополнения софтверных доходов. Мы будем продолжать это делать до тех пор, пока наш доход от софтвера не покроет наши расходы. Когда это случится, мы все еще будем заниматься консалтингом, но будем в состоянии выбирать наши работы, и будем концентрироваться на тех работах, которые поддерживают наш софтвер. Софтвер, как вы знаете, масштабируется невероятно хорошо. Когда один новый заказчик покупает FogBUGZ, мы делаем больше денег, не тратя никаких денег.

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

[nm]

Originally Posted by AvDav

Пациент скорее жив чем мертв. Еще глобально хорошая статья

пациент скорее мертв, чем жив! и статья этому в подтверждение.

вобщем мы видим схлестывание 2 разных подходов - западного и восточного.
западный - быстро обучиться делать хрень и начать на этом зарабатыавть деньги
восточный - долго учиться, для того, что бы уметь делать ХРЕНЬ, делать ХРЕНЬ -- не поточным методом, а штучно, на заказ -- это требует больше сил, дороже, ну и существенно отличается по качеству - все таки это ХРЕНЬ, а не какая-то там хрень.

я лично всем даю почитать вот эти 2 следующих линка. читать вдумчиво и именно в таком порядке

http://miu-mau.org/73.html
http://miu-mau.org/74.html

[CyberJoe]

Все когда нибудь вымрет, и Цпп не иссключение.
Исспользуемость языка зависит от исспользуемой технологии, так как технологии
меняються то, многим языкам в итоге придет Капут.
Уважаю c++ но все же это далеко не верх совершенства.
Вы когда нибудь задумывались на, что может быть похож язык програмирования будущего?

[Ablertus]

Биоинфлеры вовсю занимаются созданием языка для системной биологии (причем именно языка программирования, описательный язык - SBML - существует давно). Наверно точно так же скоро появятся (очень скоро, если уже не появились) специальные языки программирования для медицины, географии, метеорологии и сельского хозяйства. Универсальным (в смысле претендующим на универсальность) языкам тогда придет капец, потому как нельзя объять необьятное. Несколько позже исчезнет сама профессия “инженер-программист”, поскольку прикладное программирование станет частью общего образования. Что б не говорили, но все таки легче биолога обучить писать на Перле, чем выпускнику политеха разьяснить молекулярную биологию. Возможно останутся понятия "computer scientist" и останутся системщики, но это будут одни из многих специалистов, применяющих языки программирования.

[Nikita]

Мое ИМХО.
С/С++ умрет.
Один программер на Питоне может выполнить проэкт в несколько раз быстрее чем 2 программера на С/С++ (Это вот статистика)
Конечно можно сказать что мол на питоне (в прочем и на других языках более высокого уровня, или проблемно ориентированных языках программирования) расходуется больше ресурсов машины бла бла бла
Тут вроде нужно вспомнить закон мура (все удваевается каждые 18 месяцев). Хотя есть одна цифра, если он будет действовать еще 100 лет то производительность машин повысится в 90 квинтилионов раз. Скорее всего наткнется на что то и встанет ... в этом случае на первый план выйдет расспаралелизация процессов, и появятся соотетствующие компиляторы/интерпретаторы.
Относительно молекулярной биологии и программирования на перле ... эта проблема до сих пор не решена, скорее всего появятся специалисты по дата процессингу для каждой науки, они не будут ни биологами/физиками/компьютерщиками а будут работать на стыках. Подобно физхимии, биохимии бла бла бла ...
Хреновый из меня аналитик...

[Hrach_Techie]

Originally Posted by accemic26

Мое ИМХО.
С/С++ умрет.
Один программер на Питоне может выполнить проэкт в несколько раз быстрее чем 2 программера на С/С++ (Это вот статистика)
Конечно можно сказать что мол на питоне (в прочем и на других языках более высокого уровня, или проблемно ориентированных языках программирования) расходуется больше ресурсов машины бла бла бла
Тут вроде нужно вспомнить закон мура (все удваевается каждые 18 месяцев). Хотя есть одна цифра, если он будет действовать еще 100 лет то производительность машин повысится в 90 квинтилионов раз. Скорее всего наткнется на что то и встанет ... в этом случае на первый план выйдет расспаралелизация процессов, и появятся соотетствующие компиляторы/интерпретаторы.
Относительно молекулярной биологии и программирования на перле ... эта проблема до сих пор не решена, скорее всего появятся специалисты по дата процессингу для каждой науки, они не будут ни биологами/физиками/компьютерщиками а будут работать на стыках. Подобно физхимии, биохимии бла бла бла ...
Хреновый из меня аналитик...

афтар выпей йаду!!!