На подкасте Радио Т номер 222 поговорили о языках программирования вообще и о C++ в частности.
Размышления на тему судьбы языка С++ стали особенно актуальны после недели ненависти к С++ на Хабрахабре.
воскресенье, января 16, 2011
Приняла участие в подкасте Радио Т
Подписаться на:
Комментарии к сообщению (Atom)
Atom feed
66 коммент.:
Ухты, какое хорошее радио, там есть прямая ссылка на mp3
>> Размышления на тему судьбы языка С++ стали особенно актуальны после недели ненависти к С++ на Хабрахабре.
Я надеюсь Страуструп читает хабр :D
IMHO это скорее на кризис головного мозга похоже и нежедение работать
Комментируя подкаст, могу сказать, что мы уже около 3-4 мес не можем найти более-менее толкового приплюснутого инженера в Денвере, хотя бы на 5-6 по 10ти бальной шкале. Из вакансии уже убрана вся специфика NLP, Comp. Linguistic & Machine Learning. Вакансий хватает, более-менее адекватных кандидатов не видно.
А ведущие кто? Гуру программирования?
По OS на C++ - это BeOS/Haiku - http://www.haiku-os.org
Вообще, обычно новую ОС делают на новом языке - т.к. чтобы выражать новые сущности, которые выделяют эту ОС среди предшественников, нужен новый язык (это может быть язык для предыдущей ОС с добавками).
Объектные системы на C не проверяются статически компилятором. В принципе, ведь всё, что делается на C++ можно и на макроассемблере сваять. Но без проверок :-).
спасибо!
по поводу "недели ненависти" - все высказывания - это просто обычный холивар. Без предложения адекватной замены - это обычное сотрясание воздуха.
2noonv: а как же D? Тот который 2.0
зы
неделя ненависти к С++ на хабре - моих рук дело :D
Ёлки-моталки, как на ЛОР попал. Вот это толщина! "C++ мёртв", "линукс мёртв", "время компиляции!!11", "трейдеры уходят на шарп", "изменение сознания", "с++!=си с классами", "glib - это тру ООП", "не бывает ООП без синтаксиса объект.метод()", "вы ничего не понимаете в больших проектах", lisp (какой-же плюсосрач без него), "железо дешевле программистов", "если бы они взяли c++ явно получилось бы намного хуже". Поржал, спасибо.
2Анонимный: а что за компания в Денвере? интересная у вас тематика, но почему именно C++?
Хабр - клоунада какая-то. Толпа школьников-верстальщиков, фанатеющих от Apple, метает лучи ненависти на С++, потому-что не здали по нему экзамен в своем вузе.
Странно, что именно РадиоТ - уж больно много там воды на отвлечённые темы, лично я слушал онлайн и хватило только примерно до обсуждения кодеков в браузере да у кого вебморда к почте круче...
Вроде бы ты писала для Wii, но неуж-то там есть такой уж простор в выборе языка? Насколько я понимаю, игры для консолей сейчас можно писать официально только на Си/С++/ассемблере и возможно С# (xBox 360) просто по той причине, что для этих языков есть инструменты и девкиты, а для других языков нет (homebrew не в счёт).
@LG.BALUKATION
Игрушки можно и на Java писать, но дальше арканоида это не уйдет. Слишком медленно. Если 200 строк кода на asm будут работать быстрее, чем 3 на С++, то придется писать asm.
На С или С++ пишется всё, что должно выжимать максимум при больших нагрузках. Вон Оракл свою СУБД на pure C пишет. Вот, ололо, да? =) Java - это кросплатформная Delphi.
>> Игрушки можно и на Java писать, но дальше арканоида это не уйдет.
Ил-2 штурмовик с логикой на Java, ММОРПГ Runescape и Minecraft с миллоном покупок смотрят на вас, как на фанатика с++
Дело не в языке, тот же C# поверх ManagedDirectX (или как там это сейчас называется, XNA, кажись) отлично идет в геймдеве.
Это не говорит о том, что С++ отстой, но ведь не зря его оставили (вышеперечисленные) только для графики, наверное им не очень удобно было писать игровую логику на C++, а?
к предидушему каменту -
Java, она не кроссплатформенная, Java это и есть платформа
а кросплатформенность это миф и её не существет
Каждому языку свое. Для низкого уровня C и C++ это все еще самый лучший выбор. Но чтобы реализовывать бизнес-логику на нем - нужно иметь очень веские основания. Да и для ряда задач "высокой нагрузки" сейчас есть совсем иные решения. Например, обрабатывать миллионы пользователей и десятки тысяч конкурирующих подключений ежесекундно в несколько раз проще на Erlang, потому-что он для этого и существует.
Интересно было послушать с вашим участием, был приятный сюрприз). Но из обсуждения про С++ вышел спор абсолютно несвязанных и не конкурирующих лагерей. Самая здравая мысль была у Бобука в конце: "Если бы ты Женя работал в gamedev-е"... . Также не понравилось мнение что игры под iPhone не пишут на С++, я если честно сомневаюсь что Infitiny Blade и Rage были написан на Objective-C, там скорее всео С или С++, по крайней мере я пишу под ифон используя C++ т/к/ Box2d на нем написан + сам считаю его своим первым любимым языком, сейчас его место занимает Objective-C )). После 2ух с половиной лет опыта на Objective-C многие вещи в С++ стали раздражать), естественно я беру в расчет присутствие стандартных библиотек. Приходите в Радио-Т еще )).
Facebook использует Hip-Hop не просто так, сейчас стали появлятся разные библиотеки которые позволяют писать под Web на С/С++. Алена, сочувствую тебе, в компании людей с полной явой мозга
а еще авторы путают объектный язык и обьектно ориентированное программирование. к примеру: в Windows все обьекты, хэндлы и взаимодействие(очень хорошо видно в GDI программировании) являются объектно ориентированныеми но использовать их можно в любом языке, не только в обьектном. например структуры указателей на функции в с появились еще в начале 80х, и такой подход используется в gnome lib, а такой подход это прадедушка объектных языков
Алена, вы молодец.
На фоне некоторых не очень адекватных ведущих, мнение которых о себе явно завышено, вы выглядели очень достойно.
[повторяю комментарий, исправив опечатки и акценты]
Мой общий вывод по подкасту касается не C++, а Java.
Уверенность джавистов, что любые задачи можно решить на Java, что нет задач, которые оптимальнее решать на других языках - это очень напоминает нежелание программистов 1С:Предприятие видеть вокруг себя что-либо, кроме прикладного бухгалтерского программирования.
Это наводит на мысль, что джависты больше всего занимаются решением бухгалтерских задач:)
2Alex Ott
а что за компания в Денвере? интересная у вас тематика, но почему именно C++?
http://www.alchemyapi.com/
Потому что ни один конкурет не может нас догнать по кол-ву API calls per second, потому-что большинство алгоритмов основаны на нечеткой логике и иногда тренировка модели занимает около двух дней на достаточно серьезных выч. мощностях (на жабе в 2-3 раза дольше), в конце-концов, только С/С++ можно использовать на GPGU/CUDA.
Пользуясь случаем, если есть желающие - милости просим на собеседование, контактная информация по ссылке.
[b]Алёна[/b], как Вы выдержали такое невероятное количество бреда про С++/Java/др. языки в такой малый промежуток времени?
Алена, а зачем вы туда пошли? В смысле, зачем приняли участие?
>> в конце-концов, только С/С++ можно использовать на GPGU/CUDA.
Ой, а вот это заблуждение. OpenGL, OpenCL, CUDA придерживаются клиент серверной архитектуры. Вообщем-то абсолютно без разницы, из какого языка идут вызовы.
Что касается самих ядер, так это же чистый ANSI С с минорными расширениями.
Да и нагенерировать ядра из того же питона, могу сказать многим проще, чем писать целиковый продукт на С/C++, по крайней мере с точки зрения логики и возможности выдачи нормальных оценок производительности.
И даже если будут миксоваться технологии (к примеру при делении физика/графика), если все вычиления принадлежат GPU, то вообщем-то передача VBO между логическими частями в рамках одного контекста имеет минимальных оверхед.
2robert-krolik
разумеется, но это все биндинги, а значит неминуемый оверхед. Я гвоворю про нативную поддержку.
Diz
А ведущие кто? Гуру программирования?
Bobuk - менеджер Яндекса
Umputun - Ява-программист
Остальных не знаю
Lazin
неделя ненависти к С++ на хабре - моих рук дело :D
Ага! Так и запишем...
LG.BALUKATION
Вроде бы ты писала для Wii, но неуж-то там есть такой уж простор в выборе языка?
Писала, ага. Выбора нет.
Насколько я понимаю, игры для консолей сейчас можно писать официально только на Си/С++/ассемблере и возможно С# (xBox 360)
Все так и есть, да.
На C# под XBOX 360 писать можно.
Анонимный
Дело не в языке, тот же C# поверх ManagedDirectX (или как там это сейчас называется, XNA, кажись) отлично идет в геймдеве.
AFAIK, С# все равно используется сильно меньше, чем С++.
Это не говорит о том, что С++ отстой, но ведь не зря его оставили (вышеперечисленные) только для графики, наверное им не очень удобно было писать игровую логику на C++, а?
Он далеко не только для графики используется. Не скажу про ИЛ-штурмовик, не знаю, что там и как. Но разделение движок-скриптовая часть встречается часто. В качестве скриптового языка видела Python, Lua, свои изобретения. В движке находится не только графика, но и ядро игровой логики, ИИ и много еще чего...
soniccat
Интересно было послушать с вашим участием, был приятный сюрприз)
спасибо :-)
Приходите в Радио-Т еще )).
да может и приду еще, почему не придти...
Анонимный
Алена, вы молодец.
спасибо :-)
Анонимный
[b]Алёна[/b], как Вы выдержали такое невероятное количество бреда про С++/Java/др. языки в такой малый промежуток времени?
да ладно, было весело
loyso-b
Алена, а зачем вы туда пошли? В смысле, зачем приняли участие?
Интересный опыт, до этого я никогда не участвовала в подкастах.
Спасибо за участие в подкасте! С удовольствием Вас послушал... приходите, пожалуйста, еще!
Алена отличное выступление! Хорошая дискуссия. Java программисты как всегда уперты...
2Анонимный:
ну насчет доступности GPU только из С++ вы неправы. Я использую OpenCL из кложуры и оно работает нормально.
Скорость бывает очень критичной, но если явовское приложение крутится постоянно в памяти, то скорость у него будет достаточно хорошей - у меня достаточно много знакомых используют Clojure/Scala/Java для machine learning, и на производительность особо не жалуются.
P.S. я вот сейчас сравнил скорость работы явовской tika, со своим кодом определения типов на C++ (один из самых быстрых среди знакомых мне коммерческих реализаций), и разница в производительности (после разогрева java machine) была не сильно большой
P.P.S. посмотрел в свои проекты - оказывается я вашим API пользовался, не знал что вы из Денвера... Буду в следующий раз в командировке там, можно пообщаться, если интересно
В комментариях, почему то очень много негатива к подкасту и их ведущим, что не может не огорчать. Я давно слушаю этот подкаст, и хочется как то поддержать ведущих.
Не хочется лишний раз повторять того же Umputuna, но... Во-первых: этот подкаст построен по принципу шоу, поэтому ведущие обсуждают темы разносторонне. То есть они должны (ну или постораться)отразить все точки зрения. Поэтому кто то поддерживал плюсы, кто то был против(не всегда по всоей воле). Во-вторых: авторы не претендуют на роль гуру и истины в последней инстанции, они просто выражают своё мнение. И вконце концов - все люди имеют свою точку зрения. Надо быть толерантнее :)
А мне даже смешно, что подняли бучу на ведущих Радио-Т. Очевидно же, что то же Umputun часто просто подтролливает гостей с целью вывести их на чистую воду, ну и для шоу. Не надо относиться слишком серьёзно ко всему этому, это же не конференция разработчиков, а подкаст.
А вам, Елена, спасибо - было очень интересно послушать ваше мнение о С++, тем более, что я тоже имею отношение к gamedev. Полагаю, вам приходилось выступать перед публикой? Очень уж свободно вы говорите для первого подкаста (:
>> разумеется, но это все биндинги, а значит неминуемый оверхед. Я гвоворю про нативную поддержку.
Мой опыт говорит о том, что overhead на биндинги как правило меньшее зло, чем overhead по времени разработки.
Тем более всегда остаётся возможность сгенерировать код на основании логики, заимплементированной в языке с лучшими выразительными способностями.
Возможно моё временное заблуждение, но пройдя путь от C/C++/(lisp, python и хаскелл чуть-чуть) именно в CG пришёл к выводу, что можно при худшем раскладе не потерять в производительности и сильно увеличить скорость разработки.
2Alex Ott
Python/Scala/Java
как все это знакомо..., но эти языки хороши для researching'а, но, как мы убедились неоднократно, не для production. Посмотрите в тот же Stanford - impl/performance/etc, порой, просто ужасны.
... и разница в производительности (после разогрева java machine) ...
Да, и кроме того, очень не хочется зависеть от этих условностей: "разогрева java-машины", "непредсказуемости сборщика мусора", лицензионной политики и интриг корпораций, в конце концов (см Oracle vs Sun)
2Анонимный: ну с С++ тоже можно непредсказуемости набрать в большом проекте-то :-(
"...недели ненависти к С++..." - что это за фигня? ... Пробежал глазами посты на Хабре.
Вы знаете, я со статьями согласен :-) - нужно отпугивать "халявщиков". Тоесть тех, кто хочет научиться программировать за 24 часа.
Потому что на изучение этого языка уходят годы! Зато потом можно с легкостью переходить на любой другой популярный язык за 24 часа :-)
2Dima: не на все "популярные" (в какой из областей?) языки перейдешь за 24 часа...
но одно из преимуществ уменьшения "любви" к С++ есть - можно выбивать себе высокую зарплату, до которой тем же жабистам далеко :-)
Алена,
интересно было послушать, спасибо!
В особенности понравилась взвешенность и, не знаю, ненавязчивость суждений (вы мягко высказываете свое мнение и воспринимаете мнение других и не давите там, где не специализируетесь, например о Java.)
Тем, кто высказывался про "Java программисты как всегда уперты", "как вы вытерпели столько явистов вокруг себя" и прочее :)
Тут недавно Умпутун писал в твиттере нечто вроде "многие пишут - вот позвали бы меня вместо Алены на подкаст, уухххх вот я бы им показал. Успокойтесь, вас НЕ позвали, угадайте почему?"
Так вот, для тех кто таки не угадал :)
Интереснее всего слушать именно такие подкасты, где высказываются разные мнения, кто-то мягко рассказывает свой опыт, кто-то беззлобно подкалывает и подтролливает.
Если бы гость брызгал слюной и пытался размазать ведущих подкаста по ковру а-ля "Да вы просто не сдали экзамен по С++, да что вы знаете про него!" и все такое - слушать подкаст было бы в разы скучнее. Кому нужна эта вакханалия троллей? Я бы лично вырубил подкаст на 10 минуте такого шоу :)
Мы все таких тредов видили более чем дофига на форумах.
Потому что на изучение этого языка уходят годы! Зато потом можно с легкостью переходить на любой другой популярный язык за 24 часа :-)
1. Об этом заблуждении писал еще небезызвестный Skipy. Ни за 24, ни за 72, ни даже за 144 (!) часа перейте по-настоящему не получится, увы. Не льстите себе :)
2. Возможно, именно из-за этого среди программистов Java (а так же из-за того, что их в абсолютном числе очень много, причем многие, как тут сказали, перешли на нее за 24 часа), Java-программистов некоторые и считают низкоквалифицированными по сравнению с труъ С++ программистами.
Алёна, "а мужики то и не знают", для чего нужен (ну очень нужен) std::auto_ptr:
http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Resource_Return.
И еще "от себя" - "умные указатели" очень хороши тем, что по ним сразу видна семантика владения ресурсом (а иногда и тот код, который им владеет), т.е. код становится более "самодокументируемым" и уж точно более читаемым. Те, кто много работал с Qt (а там из исторических/идеологических причин используются только простые указатели) согласятся, что даже по его документации (а она недаром считается одной из лучших среди документаций к C++ библиотекам) не всегда понятно, кто и как владеет ресурсом и надо ли (можно ли) уничтожать его «вручную» (только не надо рассказывать про модель памяти в Qt – я знаю ее на уровне исходных кодов – она в Qt не везде).
По мне так C со своими «raw pointer» по читаемости/понятности проигрывает C++ (да простят меня фаны C).
Алёна, не хотите написать статью про «умные указатели» в C++ и их разумное применение?
с умными указателями тоже хватает проблем, и с точки зрения использования (поскольку методика подсчета ссылок - глубоко порочна), и с точки зрения производительности.
вот небольшое исследование на тему умные указатели С++ vs. GC в части производительности.
Да и Лев Валкин (lionet) писал, что на большом объеме выделения мелких объектов, OCaml GC, например, обгоняет стандартный malloc
Забавно очередной говносрач на тему C++ не читать на LOR-е, а слушать. Впрочем, уровень наездов на C++ на LOR-е зачастую повыше будет.
Алена, спасибо вам, вы прекрасная гостья подкаста!
Приходите почаще, будет очень приятно вас слышать!
Технологии меняются, меняются требования к программированию.
Но С++ словноватый видимо для лентяев. Отсюда и возникают такие вопросы.
Burjui
вам, Елена, спасибо - было очень интересно послушать ваше мнение о С++,
пожалуйста!
Полагаю, вам приходилось выступать перед публикой? Очень уж свободно вы говорите для первого подкаста (:
Приходилось, ага.
Marat
Алёна, не хотите написать статью про «умные указатели» в C++ и их разумное применение?
Хочу. Но я много чего хочу, не факт что соберусь.
@Alex Ott:
>вот небольшое исследование на тему умные указатели С++ vs. GC в части производительности.
Точнее говоря не "умные указатели вообще", а boost::shared_ptr. AFAIK, boost-овский shared_ptr не интрузивный, т.е. у него счетчик ссылок лежит отдельно, что приводит к дополнительным new/delete для создания/удаления данного счетчика. В случае же интрузивных умных указателей (как Poco::AutoPtr) этих накладных расходов не будет.
Ну и, кроме того, подобные benchmark-и хороши на задачах, где сначала много памяти навыделяли, а потом всю ее освободили. Более серьезные исследования показывают, что GC имеет сравнимую с ручным управлением памятью скорость только при наличии в 5 раз большего ее объема, чем это нужно.
Вы молодец!!!, хотя если судить по подкасту Java какой-то совсем уж крутой получился. ИМХО программист должен знать как минимум 2-3 языка(асм само-собой), например связка -императифный-функциональный или компилируемыq-интерпритируемый (пример в игроделе С++ + lua) и т.д. В принципе только один язык круче С++ это pure C
Замечательный подкаст. Тонкий троллинг ведущих. В т.ч. и друг друга. :-)
Разговор не интересен и вообще не состоится если все со всеми согласны. В разговоре должны быть разные точки зрения, должен быть конфликт какой-то, или видимость его. Так что всё нормально.
Правда я не понял пассажа про ручное управление памятью в яве (в своих пулах памяти). Что-то было про ByteArray. Если там есть механизм размещения объектов в моём запасённом ByteArray'e, то это замечательно. Но ничего нагуглить на эту тему не смог. Быть может кто подскажет что это?
Ага. Нашел. Это таки ByteBuffer
http://download.oracle.com/javase/1.4.2/docs/api/java/nio/ByteBuffer.html
Но я не нашел как же туда засунуть не какой-то примитивный тип, а структуру-объект. Т.е. видимо надо будет делать фасад для таких объектов который будет непосредственно иметь ссылку на этот ByteBuffer и куда-то там что-то писать/читать.
Единственное что -- человеческих ссылок на другие объекты такие объекты живущие в буфере иметь не будут. По кр. мере с ходу я не вижу как такой объект сможет ссылаться на объект живущий в общем хипе. Может как-то через слабые ссылки и отображать одно на другое.. Хез.
В общем пожалуй посложнее чем в плюсах просто аллокатор памяти поменять.
Но в общем да. Подкаст полезный. Ещё один довод в спорах с шарпщиками :-)
Но таки один камень в сторону ведущего играющего за "нападающего": java это не самый хороший противовес С++ в данном споре был. Единственный плюс жабы -- это GC и работа с памятью. Всё. (напомню в рамках этого спора-разговора).
Всё же остальное, все называемые недостатки С++ в яве стократ виднее.
Это:
1) Огромадные иерархии классов. Та самая древовидная структуру с корнем. Это самое ООП которое неоднократно клеймилось в ходе разговора.
2) Метапрограммирование. Уж чего-чего а этого в яве ОЧЕНЬ много. Особенно в j2ee. И я согласен с ведущими -- за это нужно расстреливать. К сожалению в яве средства метапрограммирования слишком легкодоступны.
Откровенно говоря, я всё ждал когда упомянут например Haskell или тот же CL с его иной парадигмой ООП (для не любителей скобочек есть Dylan -- тот же Common Lisp практически, но с алголоподобным синтаксисом, т.е. никаких скобочек). Мне, кстати, очень понравилось тамошнее ООП. Потратил вечер на чтение доки и проникся.
Да, а на С++, из повседневно bи повсеместно используемых ОС написан например Symbian. Микроядерная система реального времени как бы :-)
А вот насчёт auto_ptr подумалось. Он мне вообще нравится потому что быстрый. Такой-же быстрый, как void*. Все эти shared_ptr только тормозят и кучу фрагментируют, их стараюсь без нужды не трогать. Так вот, auto_ptr замечательно лезет в контейнеры, если запихивать его туда через move(). Проблема возникает с std::sort, который, зараза такая, оказывается делает копию опорного элемента. Это нихрена не хороший сюрприз. Граждане, будьте осторожны, когда сортируете что-то сложное.
@valexey:
ByteBuffer -- это совсем не ручное управление памятью в Java. Если ведущие подкаста такие вещи утверждают, то это всего лишь свидетельствует об их уровне.
Ручное управление памятью есть в Real-Time Java. Вот пара ссылок для информации:
http://java.sun.com/developer/technicalArticles/Programming/rt_pt1/
http://www.cs.purdue.edu/homes/jv/pubs/isorc04.pdf
Только, имхо, траха с управлением памятью в Java в этих случаях будет не меньше, если не больше, чем в C++.
Alex Ott
небольшое исследование на тему умные указатели С++ vs. GC в части производительности
Продолжая то, что напрямую не относится к этому посту :), скажу, что:
1) странный тест - хорошо бы посмотреть на результаты работы профилировщика;
2) за то, как используется boost::shared_ptr в тесте (см. исходный код в тамошних коментах), я бы "оторвал...", т.е. заставил выучить boost::shared_ptr best practices наизусть.
Хотя отрицать то, что GC может выигрывать у детерминированного (программистом) управления памятью (и уже тем более при подсчете ссылок) глупо;
3) в свете C++0x и move semantic в будущем удастся сократить количество вызовов конструктора копирования boost::shared_ptr (т.е. кол-во выполняемых CAS-операций), заменив некоторые из них вызовами move-конструктора (несколько операций копирования raw pointer) - конечно это не спасет shared_ptr в этом тесте, но все равно "новые результаты" будут интересными (особенно для "цппшников").
Алёна
Хочу. Но я много чего хочу, не факт что соберусь.
Был бы очень рад видеть Ваши (!) статьи не только об умных указателях, но и о других известных (в разрезе C++) идиомах/шаблонах проектирования - уж очень интересен Ваш опыт (не только геймдев).
И, кстати, не знал про Delphi - я и сам с него начинал, но после того, как узнал, как ведут себя конструкторы в Delphi при выбрасывании из них исключения - брррр...
Подкаст, кстати, получился хороший - приятно послушать такой "не напрягающе" лёгкий троллинг, не перегруженный перечислением того, что "все уже и так знают". Я вот люблю C++, но деньги получаю за Java. Может быть, именно владение несколькими языками, "успокаивает душу программиста" и позволяет не напрягаться по поводу очередного холивара.
К теме разговора в начале подкаста, нашелся рейтинг языков по данным кадрового агенства
Алёна, к устным баталиям нужно готовиться... Провести разведку, побольше узнать о противнике. В ходе беседы постоянно сквозило подменой понятий: то язык, то библиотека, то платформа, то вакансии в Америке - не ясно что с чем сравнивалось. Бред про glib особенно понравился. Ниша С++ Страуструпом определена как, разработка библиотек. У Java - Web приложения. А по поводу вакансий, тут также вилка: мало С++ по экономическим причинам - получить быстро выгоду. Сами возможности языка здесь не причем. Java давит всем весом своей платформ... Конечно кроссовость и коробочность это понятно и круто для менедров...
Бьерн рекомендовал изучать низкий уровень программинга. Понять смысл эволюции языка и вообще научиться программировать отлично на чистом СИ. Правильный путь именно восходящего развития. Если писать только на STL без понимания на уровне ОС разница парадигм в умах программистов С++ и Java не существенна. Получается узкий кодер без опоры. И еще, думаю, что не правильно измерять результат затраченными усилиями и значимость результата зарплатой. Или можно?
Алёна, спасибо, вы здорово раскрасили Радио-Т. Им очень нехватало вашего голоса.
Работа в исполняющей среде, это как покупка товара у перекупщика - тот же товар но втридорога. И никто не замечает, что практически все Unix системы написаны на C/C++, большай часть Windows написана на C/C++.
Java - это исключительно прикладной язык для прикладных задач. Я думаю тут даже спорить не о чем.
Алёна - Вас было приятно теперь не только читать, но и слышать ))))
Собсно в подтверждение моего предыдущего поста - ссылочка C++ Applications
Только сейчас послушал 222 радиот.
Мне очень понравилось как вы вели дискуссию на столь холиварную тему. Зная как Умпутун умеет "вдарить" в "подставившегося" я боялся что может получиться грубо и неинтеллигентно :) Однако вы были на высоте. Я получил истинное удовольствие слушая вас.
В силу разных причин ваш блог не читаю, но ценю :) Специально зашёл, чтобы поблагодарить :)
shebdim
В силу разных причин ваш блог не читаю, но ценю :) Специально зашёл, чтобы поблагодарить :)
спасибо :-)
Чувачки в подкасте похоже вообще в программировании не шарят :-) пусть они драйвера на джаве напишут ага (или на сишарпе). Чтоб их говнокод джавовский заработал надо виртуальную машину запустить которая написана на C/C++ (это если еще памяти и мощи проца хватит). Они походу хабранутые :-)
И как же хорошо, что уметь программировать - это лучше чем шарить в программировании...
Из прослушивания подкаста у меня сложилось мнение о ведущих как о людях, которые способны перейти на любую технологию, если так скажет рынок. И если при переходе на новую технологию будет иметься выбор, то он будет сделан исходя из задачи, а не потому, что такая-то технология аж позволяет написать целый драйвер.
А для Явы не будет нужна виртуальная машина, если кто-нибудь напишет соответствующий компилятор.
Так что нечего поливать людей грязью, особенно по причинам, высосанным из своего же пальца.
Указанная вами ссылка на выпуск не рабочая, к сожалению. Новая => http://new.radio-t.com/2011/01/222_8801.html
Прошу прощения за некрокоммент, но этот выпуск «Радио-Т» был одним из самых технически интересных, ведущих так никто не гонял (кроме гостьи из IBM), а ведущие никогда так не атаковали гостя (кроме гостьи из IBM, но то был другой выпуск:). Без преувеличения, это золотой фонд подкаста.
Отправить комментарий