Интервью с Бьярном Страустрапом

ПЛАГИНЫ - ЗЛО!

Те хто этого не понимает - тупорылые быдлокодеры (в прямом смысле этого слова)

>> RAII - наихудший вариант решения проблемы. Поэтому вопрос должен звучать так: Чем это не хуже RAII?

>Абсурд, я тебя уже просил написать пример "многофазовой инициализации"

Уже писал:

Entity e = new Entity(); e.setFoo(foo); e.setBar(bar); e.init(context);

>>>>И почему это предпочтительней RAII? В каких случаях?

>>>RAII - наихудший вариант решения проблемы. Поэтому вопрос должен звучать так: Чем это не хуже RAII?

>>Может быть тогда благородный дон сможет сказать, что же лучше RAII?

>gc для памяти (90%), finally для всего остального (10%)

Даже разработчики .NET с вами не согласны, т.к. придумали IDisposable и using. Таки вменяемые люди понимают, что даже в условиях GC одним finally жив не будешь.

> Раз в сутки свой любимый комбайн можно и перезапустить ЦЕЛИКОМ.

Ну нифига себе тема 8-( А как же gc и все прелести архитектуры, надёжность Java-систем проявляющиеся, как докладывают гуру, через год, если не перезапускать?!

Мне кажется что многим здесь нужно остановиться и подумать: "Куда я качусь?!". "Что я ищу в этой жизни?". "Не манипулируют ли моим сознанием дяди с большими кошельками?".

Чего-то я это пропустил:

>> Да, особенно прикольно будет делать RPC для работы с таким плагином.

>Веб-серверы так работают, и ничего.

Веб-серверам нужно у "плугина" получить только поток байт, который они тупо отдадут пиру.

> Веб-серверам нужно у "плугина" получить только поток байт

Всё в программировании - потоки байт. Кстати, еще какая-то плагинная архитектура сделана на процессах - вроде, в Photoshop.

>> На западе ООП преподают только на Ява, а не каких-то говноплюсах....

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

Почитайте про их систему образования. Я читал, как в тамошнем вузе задали задачу на тему "воздушный шар летит по ломанной со скростою 20 км/час 2 часа, на какое расстояние от начала он улетит". Одна из учащихся дала ответ в районе 1000 км.

>>gc для памяти (90%), finally для всего остального (10%)

>Даже разработчики .NET с вами не согласны, т.к. придумали IDisposable и using. Таки вменяемые люди понимают, что даже в условиях GC одним finally жив не будешь.

Вопрос стоял "что не хуже RAII". Я ответил - "gc для памяти (90%), finally для всего остального (10%)". Никакой ошибки в своих рассуждениях я не вижу.

> Всё в программировании - потоки байт. Кстати, еще какая-то плагинная архитектура сделана на процессах - вроде, в Photoshop.

3dmax и майа -- точно бинарные плагины не на яве.

>>Даже разработчики .NET с вами не согласны, т.к. придумали IDisposable и using. Таки вменяемые люди понимают, что даже в условиях GC одним finally жив не будешь.

>Вопрос стоял "что не хуже RAII". Я ответил - "gc для памяти (90%), finally для всего остального (10%)". Никакой ошибки в своих рассуждениях я не вижу.

Не удивительно, что у вас проблемы с C++, т.к. вы отвечаете не на те вопросы, которые вам ставят:

--- >Может быть тогда благородный дон сможет сказать, __что же лучше RAII?__

gc для памяти (90%), finally для всего остального (10%) ---

Кстати, ваш псевдоним очень хорошо передает логичность ваших рассуждений. По крайней мере, относительно C++.

>> На западе ООП преподают только на Ява, а не каких-то говноплюсах....

Еще один суперский пример. Там один студент на _все_ вопросы дал ответ "С". В то время как на эти вопросы было только 2 ответа -- А и В.

>> Веб-серверам нужно у "плугина" получить только поток байт

>Всё в программировании - потоки байт.

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

>Кстати, еще какая-то плагинная архитектура сделана на процессах - вроде, в Photoshop.

Ну по уму в Сишных приложениях все плугины надо делать out-of-proc. В Оракле например хранимые процедуры на Си выполняются в рамках отдельного процесса, при этом коммуникация с инстансом Оракла происходит через IPC. Хранимые процедуры на Яве - в контексте инстанса.

>>Всё в программировании - потоки байт.

>Только серверу не надо их парсить, не так ли?

И что? Клиенту их парсить таки надо.

> Иначе там нужен язык описания протокола и внешний тул для автогенерации стабов.

И что? Это сделано не раз и не два.

> В Оракле например хранимые процедуры на Си выполняются в рамках отдельного процесса

Ну то есть ты и сам можешь привести примеры, когда плагины работают в отдельных процессах. Прекрасно.

>>Не удивительно, что у вас проблемы с C++, т.к. вы отвечаете не на те вопросы, которые вам ставят:

>--- >Может быть тогда благородный дон сможет сказать, __что же лучше RAII?__

Ну и на этот вопрос ответ тоже: "gc для памяти (90%), finally для всего остального (10%)". "Немного лучше" это все таки подмножество "лучше".

Интересно. Действительно несколько способов, как в Безопасной Яве компилятор можно обмануть и прокинуть checked exception без его декларирования.

http://www.rsdn.ru/forum/message/2778526.flat.aspx

>> В Оракле например хранимые процедуры на Си выполняются в рамках отдельного процесса

>Ну то есть ты и сам можешь привести примеры, когда плагины работают в отдельных процессах. Прекрасно.

У этого подхода есть один недостаток: сложно и громоздко это слишком, особенно если плагинов много и интеграция с ними сильная, не на уровне "слив для данных в одном из бэкэндов". В Оракле это компенсируется тем что потребность в хранимых процедурах на Си возникает ну *Очень* редко.

> Уже писал: Entity e = new Entity(); e.setFoo(foo); e.setBar(bar); e.init(context);

И где тут проявляется непригодность RAII? Я не понял.

> Ну и на этот вопрос ответ тоже: "gc для памяти (90%), finally для всего остального (10%)".

Ну тогда еще раз. Разработчики .NET учли опыт Java и пришли к выводу, что нифига это не лучше RAII. И доказали это добавив в .NET интерфейс IDisposable и конструкцию using.

>> Уже писал: Entity e = new Entity(); e.setFoo(foo); e.setBar(bar); e.init(context);

>И где тут проявляется непригодность RAII? Я не понял.

Ты просил многофазную инициализацию. Я привел пример 1) создание инстанса 2) настройка оного 3) регистрирование инстанса в обсерверах/листнерах, которое происходит в init.

>Разработчики .NET учли опыт Java и пришли к выводу, что нифига это не лучше RAII. И доказали это добавив в .NET интерфейс IDisposable и конструкцию using.

1) А что, на С# нельзя писать не пользуясь этим? 2) Зачем пользоваться этим?

> 2) Зачем пользоваться этим?

Чтобы в программе было меньше багов.

>Я знаком с очень многими студентами, сильно не любящими подтирать за собой, и потому пишут на Java. Им даже не пытаются давать C и С++. Ибо ещё в школе они узнали что Java это будущее и очень круто, что программист это чувак с Java-ой. Это очень хорошо. Почему? Объясню. Факт наличия мега "технологий" программирования позволяет держать толпы и орды недопрограммистов подальше от нормальных программ.

Не совсем. Ни в коем случае никого не оскорбляю - сам писал по работе одно время на Java, не такая уж и большая разница с dotNet. Пришла в голову одна мысль и это так и есть похоже - почитал про аутсортинг. Западным компаниям очень выгодно (и они это делают) пробивать в универах курсы.Наши тоже пробивают, не в таких масшатабах. Им нужны исполнители на грязную, не благодарную работу которой их высококвалифицированные специалисты (высокооплачиваемые) не будут заниматься. Поэтому и не дают знаний о таких вещах. Серьезные сложные системные программы писать в России почти и не кому.

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

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

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

>> 2) Зачем пользоваться этим?

>Чтобы в программе было меньше багов.

Странный ответ. Если бы я знал До-Диез, я бы возможно написал "Плохой". Как раз количество багов оно (возможно) увеличивает, так как тут scoped память используется вперемешку с gc-памятью. Из-за этого количество контекстов за которыми программисту надо следить увеличивается.

4.2

Детко, не врите!

Чего вы все спорите? Рынку не нужно такого количества квалифицированных специалистов С/С++ эта проблема возникла не вчера, а лет десять назад. Точно также, как университет не может содержать 10000 профессоров, это нонсенс, никто не даст такого бюджета. А ява - отличная вещь, тем более что ее двигает такой мощный вендор, как Sun.

> Есть тенденцию двинуться в другие страны на поиск дешевых работников.

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

>..., мы тянемся к звёздам. alx_me * (*) (28.06.2008 17:56:59)

Пипиской?

IDisposable - не от хорошей жизни. Связан он с тем что GC не гарантирует моментальное удаление объекта как только он становится не нужен. А это в свою очередь гарантирует программе кучу глюков, которая надеется на то что ресурсы освобождаются вовремя (для примера - работа с пулом подключений к БД - попробуйте вызвать в цикле метод который что-то делает с базой, и для каждого действия создает новое подключение. Пул быстро закончится - GC "не успевает" удалять объекты)

Эта ситуация как раз из тех 10% для finally ок которых говорил Absurd.

быдлоязык не нужен. Программы, написанные на С# проще пишутся, а главное работают в разы быстрее

>Сомневаюсь, что можно что-то найти на 100 с лишним страницах. Таки дела есть поважнее у каждого.

Утверждалось, что Xenocephal не доказывает свои утверждения. Видимо, недоказанное утверждение уже найдено. Иначе нефиг и говорить, что такие утверждения там есть.

> быдлоязык не нужен.

ну у кишечнополостных его и так нет. доказано вскрытием!! ::))

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

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

> Иначе нефиг и говорить, что такие утверждения там есть.

лол, что? Тебе нужны доказательства? Вот моё утверждение "Ява не нужна". Доказательство: неимоверно жрёт память. Доказано? Остальные аспекты меня не интересуют.

>Вот тебе небесплатный рендер http://hoops3d.com/ написанный на плюсах и ДиректХ.

Рендер на ДиректХ? Это не рендер, это фигня для игр и предпросмотра. Финальный рендеринг делается вообще без аппаратного ускорения.

> Повторяю: рендер нужно писать на C

ага, щаз, разбежался.

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

Вообще надо изначально знать, где его проект/библиотека будет использоваться. Нахрена мне извращаться на c, если 100% известно, что либа нацелена на использование внутри с++ проектов?

>>Чтобы в программе было меньше багов. 

>Странный ответ. Если бы я знал До-Диез, я бы возможно написал
>"Плохой". Как раз количество багов оно (возможно) увеличивает, так
>как тут scoped память используется вперемешку с gc-памятью. Из-за
>этого количество контекстов за которыми программисту надо следить
>увеличивается.

Там нет никакой scoped памяти. Есть только GC-память.
Вот пример из MSDN (http://msdn.microsoft.com/en-us/library/yh598w02(VS.80).aspx):

using (Font font3 = new Font("Arial", 10.0f), 
           font4 = new Font("Arial", 10.0f))
{
    // Use font3 and font4.
}

При выходе из секции using у объектов font3 и font4
просто автоматом вызывается метод Dispose(). А сами
эти объекты утилизируются сборщиком мусора.

Без IDisposable и using пришлось бы писать:

Font font3 = null;
Font font4 = null;
try {
  font3 = new Font("Arial", 10.0f);
  font4 = new Font("Arial", 10.0f);
  ...
}
finally {
  if( font3 ) font3.Dispose();
  if( font4 ) font4.Dispose();
}

Ну и в каком случае больше контекстов, за которыми нужно следить?

> Утверждалось, что Xenocephal не доказывает свои утверждения. Видимо, недоказанное утверждение уже найдено.

Да они все такие :) Он не доказывал, не спорил, он только вещал и пыжился. Говорил очевидные вещи вперемежку с чушью,

>Вообще надо изначально знать, где его проект/библиотека будет использоваться. Нахрена мне извращаться на c, если 100% известно, что либа нацелена на использование внутри с++ проектов?

Объясни, какие функции ООП нужны в рендере?

s/ООП/C++/

>Там нет никакой scoped памяти. Есть только GC-память.

Ну тогда это автоматизированный finally-блок а не RAII в понимании плюсов.

>Ну и в каком случае больше контекстов, за которыми нужно следить?

И что, Font здесь - критический ресурс? В Яве - нет. Если он используется постоянно в каком-то контроле, можно мембером его сделать - тогда он не будет создаваться при каждой отрисовке.

>Объясни, какие функции ООП нужны в рендере?

Объекты?

>Говорил очевидные вещи вперемежку с чушью,

Приведи пример "чуши".

>Приведи пример "чуши".

"Маленькое быдло, ты хотя бы одно слово осилишь по теме сказануть?"

Дальше не читал.

>Нахрена мне извращаться на c, если 100% известно, что либа нацелена на использование внутри с++ проектов?

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

>>Приведи пример "чуши".

>"Маленькое быдло, ты хотя бы одно слово осилишь по теме сказануть?"

Скажешь Interface 01 и Aftor заслуживали каких-то иных эпитетов? С iron00cutter&Yossarian Ксеноцефал разговаривал вежливо.

>Дальше не читал.

Битард?

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

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

Их подвигает к этому экономический кризис в собственной стране. Так, что фик его знает как будет. Ближе к осени будет еще хуже. Прогнозируют апогей где то в январе 2009.

Пи..ец %)

>> Я работаю в софт. компании в Бостоне и знаю предмет. Личный опыт говорит, что от индусов можна добиться хорошего качества кода. Но репутацию низкоквалифицированных и приносящих сюрпризы людей они, как нация, получили заслуженно. <<

http://habrahabr.ru/blog/i_am_clever/36606.html#habracut

Как видно индусы готовы работать за суммы в 2 раза меньшие. Часовая разница с Москвой (+2,5 часа) - вполне терпимо.

http://habrahabr.ru/blog/lenta/32748.html

Каждый пятый сотрудник IBM теперь живёт в Индии

http://habrahabr.ru/blog/lenta/36939.html

Низкая зарплата — главное и чуть ли не единственное преимущество индийских разработчиков. Если соотношение зарплат снизится до 1,5:1 (при нынешних темпах роста это произойдёт к 2015 году), то западным заказчикам придётся искать других, более дешёвых, исполнителей, в том числе из Восточной Европы. Правда, в России и Беларуси зарплаты растут не менее стремительно, чем в Индии.

http://amilner.habrahabr.ru/blog/25197.html

Очень обобщённо главная мысль, которая красной нитью проходит через многие материалы в СМИ и веб-ресурсах Индии, звучит примерно так: «Наша страна, история которой исчисляется тысячелетиями, ещё покажет этим западным выскочкам, кто в нашем доме (на нашей планете) хозяин».

http://www.itechbridge.com/forum/index.php?showtopic=42383

И это:

http://habrahabr.ru/blog/strange_things/29451.html

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

Поскольку зарплаты в Беларуси, Украине и России быстро растут, то эти страны резко теряют конкурентные преимущества перед Мавританией, Тунисом и Ганой. Да и по уровню образования с Африкой трудно конкурировать: например, в той же Мавритании почти всё население свободно говорит по-английски.

Хотя на счет Африки сомневаюсь.

> Но при этом ты будешь наверняка пользоваться библиотеками на Си типа OpenGL, так как они объективно удобней (не спорь со мной, я точно знаю что с библиотеками на Си меньше всего гиморов, это факт). Это вандализм - взять нормальный код и облепить его страусиным пометом, закрыв его для даунстримов которые в силу своей вменяемости хотят использовать что-то вместо плюсов.

Сказать честно мне на это на*рать. Есть библиотека с нужной функцией, я её использую. А уж на чём оно написано - дело десятое. Тот же модплуг используется в сишных проектах за отсутствием альтернативы.