Гражданин не понимает параллельного программирования. И он не один такой, тысячи их.

кто осилит перевод?

За каким хером?

перевод

испорченный телефон не нужен

объясни мне параллельное программирование, я тоже не понимаю при чем здесь оно

The compiler and the runtime have to always assume the worst — not only that any pointer can alias any other pointer but that a memory address can be stored as an integer or its lower bits could be used as bitfields

4.2

man strict aliasing

Imperative languages offer no protection against data races — maybe with the exception of D.

Такое чувство, что статью писал анонимный ЛОР-овский аналитик.

C++ давно пора стандартизировать ABI, отламывать существующую совместимость с C и приводить синтаксис в человеческий вид. Если это произойдет (а это не произойдет), то можно будет говорить о каком-то будущем.

C++ давно пора объявить deprecated

fixed

куда идёт Си++ в своём развитии

Будучи говном идет совершенно закономерным образом на говно.

То есть, нужно взять и написать новые плюсы?

Да. Хотя это уже делается и не без успеха. Сильно надеюсь на Rust.

Так и запишем: пока ты надеешься на раст, на с++ пишут ядра.

// я сам не люблю писать на с++ и не пишу практически.

Зря они это делают. Придется переписать еще раз на человеческом языке.

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

отламывать существующую совместимость с C

Без этой совместимости С++ никому и даром не нужен.

Спроси у Страустропа.

ну и по листай его свежие этого года редакции книг по С++.

у него вполне чётко приписанно цели существования и эволюции сабжа.

Без этой совместимости С++ никому и даром не нужен.

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

мне нужен. С не люблю. С++ уважаю.

уже есть и можно скачать?

можно. The C++ Programming Language (4th edition)

На рутрекере есть chm на piratebay pdf и epub были

по ссылке не ходил как Ъ, но осуждаю

С++ не хватает возможности объявить parent класс «невидимым» для child. очень мешает делать callbackи. еще мне лично мешает невозможность вставлять подсказки для компилятора, например

std::list<class X> lx;
...
for(X& i : lx)
{
    USE_FEATURE_X {
        i->function();
    };
}

все таки сходил по ссылке. там какой-то ужасный мужик на верху страницы нарисован, наверно автор. осудил мужика и читать не стал.

на самом деле, С++ ABI придумали долбозвери. Сишный API предполагает подмену функций при динамической линковке через LD_PRELOAD. а с++ный класс хрен подменишь. тогда вообще не чего было сохранять совместимость для приплюснутых символов.

Кроме того, есть еще одна фича. Пусть есть класс Foo. в нем невиртуальный метод bar(). класс и его код сидят в библиотеке libfoo.so. как вызывается Foo::bar()? а тупо в приложение вставлен код

.text
call _Foo_barololololl123

.section .plt
_Foo_barololololl123:
jmp [.plt+ptr_to_real_Foo_barololololl123]

.section .got
ptr_to_real_Foo_barololololl123:long 0

А ведь можно просто добавить экспортную версию vtable где виртуальными будут все методы, и даже статические функции будут «виртуальными». И экспортировать один символ на класс. Ибо что так 2 чтения(из plt и из got), что по новой читать указатель на vtable и прыгать прямо туда. Только указатель на vtable компилятор может скэшировать в стеке а got и plt хрен скешируешь.

Про pragma не слыхал?!? На OpenMP посмотри, хотя бы.

а толку от прагмы этой... её к LLVMному basicblockу или value не приделаешь

эдвард руки-крюки С++

я ищу хорошую аналогию тому, на что похоже программирование на С++ и я вспомнил этот фильм Тима Бёртона 1990 года, «Эдвард Руки-ножницы».

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

с ножницами вместо рук не так уж и плохо . у Эдварда много талантов: он, например, может офигенно делать причёски для собак .

у меня часто были такие же мысли после посещения конференций по С++: на этот раз это была Становимся раком индейсами 2013 * назад, в пампасы 2013 * . в прошлом году, весь восторг был про новый свисто блестящий стандарт С++11 . в этом году это больше проверка реальности . не поймите меня неправильно, на выставке было много офигенных причёсок собак (я имею в виду код на С++, простой и элегантный), но основой объём конференции был про то, как не покалечиться и как оказать первую помощь в случае случайной ампутации.

-= эдвард руки-из-жопы: маразм нам дал стальные руки крюки, а вместо серца плазменный С++ головного мозга =-

Маленький магазинчик ужасов смотреть

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

у С++ есть отмазка: обратная совместимость — особенно, совместимость с С . вы можете думать о С подмножестве С++ как добросовестном исполнителе языка ассемблера, который вы не должны использовать в обычном каждодневном программировании , окромя того, что вам это так только кажется, по первому взгляду . вдругорядь и понеже, если вы тупо доберётесь до вашего С++ инструментария, скорее всего вы придёте к «голым указателям», к циклам for, и ко всёму этому уродству.

хорошо известный пример чего не надо делать: это использовать malloc для динамического выделения памяти, и free для деаллокации . malloc получает количество байт и возвращает указатель на void, который вам нужно привести к какому-нибудь более полезному типу — было бы сложно прийти к худшему API для управления памятью . вот пример действительно плохого кода (но почти правильного, если бы не возможность разыменования нулевого указателя):

struct Pod {
    int count;
    int * counters;
};

int n = 10;
Pod * pod = (Pod *) malloc (sizeof Pod);
pod->count = n
pod->counters = (int *) malloc (n * sizeof(int));
...
free (pod->counters);
free (pod);

к счастью, никто так не пишет на С++, хотя я уверен, что есть много унаследованных приложений с такими конструкциями, так что хватит ржать.

с++ «решает» проблему избыточного приведения типов и вычисления размеров, не череватые ошибками заменой malloc и free на new и delete . правильная версия кода на С++ будет:

struct Pod {
    int count;
    int * counters;
};

int n = 10;
Pod * pod = new Pod;
pod->count = n;
pod->counters = new int [n];
...
delete [] pod->counters;
delete pod;

кстати, решена и проблема разыменования null указателя, потому что new бросит исключение когда системе не хватит памяти . есть ещё слабый шанс утечки памяти если со вторым new выйдет облом (но насколько часто это случается? намёк: наколько большим может быть n?) так что по-настоящему правильной версией будет:

class Snd { // Sophisticated New Data
public:
    Snd (int n) : _count(n), _counters(new int [n]) {}
    ~Snd () { delete [] _counters; }
private:
    int _count;
    int * _counters;
};

Snd * snd = new Snd (10);
...
delete snd;

мы уже закончили? конечно, ещё нет! код не безопасен относительно исключений.

фолькЛОР на С++ говорит, что нужно избегать «голых» указателей, массивов и delete . так что средством от хромоты malloc является оператор new, который тоже поломан, потому что он возвращает опасный указатель, а указатели — это плохо.

мы все знаем (и можем это доказать, шрамами на своём лице), что нужно пользоваться STL контейнерами и умными указателями, везде, где это только возможно . ох, и используйте семантику значений для передачи . нет, подождите! семантика значений приносит накладные расходы по производительности из-за избыточного копирования . так что насчёт shared_ptr и векторов из shared_ptr? но это добавляет накладные расходы на поцсчёт ссылок! нет, вот новая идея: семантика перемещения и ссылки-rvalue.

я могу продолжать ещё и ещё в том же духе (и часто таки буду) . вы заметили образецъ (паттерн)? каждая примочка порождает другую примочку . теперь уже нужно избегать не просто подмножество С++ . каждая новая фича или добавление новой библиотеки порождает новую серию подколок . и вы знаете, что новая фича плохо спроектирована, если об этом говорил Скотт Мейерс (последняя его речь была о засадах, угадайте чего, семантики перемещения).

хилософия С++

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

С++ стал крайне сложным языком . есть бесчисленныое количество способов, как что-то сделать — почти все из них либо полностью неправильны, либо не поддерживаемы, либо и то и другое . проблема в том, что большинство кода конпелируется и, ВНЕЗАПНО, даже запускается . ошибки и недостатки обнаруживаются гораздо позднее, зачастую после выпуска продукта (то есть, код таки не работает).

вы можете сказать: ну, ничего не поделаешь, это флешъ С++  — такова природа программирования . если вы и правда так думаете, вам всерьёз нужно посмотреть на Хаскель . вашей первой реакцией будет: я не знаю как сделать самые первые шаги и очевидные вещи (кроме вычисления факториалов и чисел Фибоначчи) в этом крайне ограничивающем недоязычке . это полностью отличается от опыта на С++, где вы можете начинать хакать уже с первого дня . чего вы не понимаете так того, что у вас это займёт 10 лет, если повезёт, чтобы обнаружить «правильный способ» программирования на С++ (если такой способ вообще есть) . и, поди догадайся: чем лучшем программистом на С++ ты становишься, тем более функциональными выглядят твои программы . спросите любого гуру С++ и они скажут: избегай мутаций, побочных эффектов, не используй циклы, избегай иерархий классов и наследования . но вам понадобится строгая дисциплина и полный контроль над тем, с кем вы сотрудничаете чтобы это осуществить, потому что С++ так много разрешает.

хаскель не разрешает, он не позволит тебе — или твоим коллегам — писать небезопасный код . да, поначалу придётся почесать репу чтобы что-то реализовать на хаскеле, чего ты можешь по-быстрому нахакать на С++ за 10 минут . если повезёт, и ты работаешь на Шона Парента или другого выдающегося программиста, он сделает обзор твоих хаков и покажет тебе, как на С++ программировать не надо. иначе, ты спрячешься в темноте на десяток лет накапливая раны, покалечив себя и мечтая о причёсках собачек. другое дело, штанга

управление ресурсами

я начал этот поцт примерами управления ресурсов (строго говоря, управления памятью), потому что это один из моих любимых примеров . я писал об этом и рекламировал это с 90х годов (см . список литературы в конце) . очевидно, у меня ничего не вышло, потому что 20 лет спустя техники управления ресурсами всё ещё не общепризнаны . Бьярн Страуструп почувствовал себя обязанным потратить половину его вступительной речи объясняя управление ресурсами толпе продвинутых С++ программистов . опять же, можно винить тупых (некомпетентных) программистов, не втыкающих в управление ресурсами, как основу программирования на С++ . хотя проблема в том, что в языке нет ничего такого, что сказало бы программисту, что в коде чего-то не хватает (см. код в начале поста) . на самом деле, зачастую изучить технику исправления — воспринимается как изучить новый язык.

почему так тяжело? потому что в С++ большинство управления ресурсами — это управление памятью . на самом деле, было зачастую указано, что сборка мусора не решает проблем управления ресурсами: всегда будут файловые хендлы, оконные хендлы, открытые базы данных и транзакции, и т.п . это всё важные ресурсы, но их управление омрачается нудятиной управления памятью . причина того, почему в С++ нет сборщика мусора не в том, что это нельзя сделать эффективно, но в том, что С++ сам по себе враждебен к GC . компилятор и среда выполнения всегда должны предполагать худшее — не только то, что любой указатель может быть алиасом (псевдонимом; aliasing) любого другого указателя, но в том, что адрес в памяти может храниться как целое или его младшие поля могут использоваться как битовые поля (вот почему для С++ рассматриваются только консервативные сборщики мусора). facepalm, йа ниасилил #pragma align

общеизвестно, но неверно то, что подсчёт ссылок (особенно, через разделяемые указатели shared pointers) лучше чем сборка мусора . вообще-то есть исследование, показывающее, что эти два подхода — две стороны одной монеты . вы должны понимать, что удаление разделяемого указателя повлечёт за собой произвольно длинную паузу в выполнении программы, с характеристиками производительности, сходными со сборкой мусора . это так не только потому что любой серьёзный алгоритм подсчёта ссылок должен уметь справляться с циклами, но также потому — что каждый раз, когда счётчик ссылок доходит до 0 на элементе данных, весь граф указателей, доступных из этого объекта нужно обойти заново . структура данных, построенная на разделяемых указателях может удаляться долго по времени, и за исключением простых случаев, вы никогда не узнаете какой именнно указатель вышел из области видимости последним и запустил этот процесс.

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

конкурентность (одновременность) и параллелизм

прошло 8 лет с того момента, как Герб Саттер, как известно, заявил: завтраки на халяву — закончились! . даже с тех пор, как большой танкер С++ с сотнями нефти медленно сменил курс апстену титанек . не похоже, что конкурентность была изобретена в 2005 году . нитки Posix были определены в 1995 . микрософт ввёл нитки в Шиндовз 95 и поддержку многопроцессорности в Шиндовз НТ . однако, конкурентность всё-таки признали в стандарте С++ 2011.

С++11 пришлось начинать с самого начала . нужно было определить модель памяти: когда и в каком порядке записи в память из разных ниток становятся видимыми другим ниткам . для практических надобностей, модель памяти С++ была скопирована с Явы (кроме некоторых противоречивых гарантий того, что Ява гарантирует в случае гонок данных data races) . однако, так как С++ нужно было соревноваться с языком ассемблера, полная модель памяти включает так называемые слабые атомарности, которые я описал бы как переносимые (портабельные) гонки данных, и рекомендовал бы избегать.

С++11 также определил примитивы для создания и управления нитками, и простые примитивы синхронизации как определённые Дейкстрой и Хоаром ещё в 1960х, такие как мутексы и условные переменные . можно спорить с тем, на самом ли деле это подходящие для целей синхронизации строительные блоки — но возможно, это пофиг: потому что как известно, они всё равно не составимы (composable) . составимая абстракция для синхронизации — это SТМ (программная транзакционная память), которую тяжело реализовать правильно и эффективно в императивном-то язычке . в Комитете По Стандартам есть группа изучения STM, так что есть шанс что однажды она станет частью Стандарта . но поскольку С++ не предлагает контроля над побочными эффектами, её будет очень тяжело использовать так как надо.

ещё была ошибочная и путанная попытка обеспечить поддержку параллелизма уровня задач с помощью асинхронных задач и не составимых (non-composable) будущих (оба всерьёз рассматриваются как устарелые в С++14) . переменные, локальные для нитки также стандартизировали подход уровня задачи, который гораздо труднее . блокировки и условные переменные также привязаны к ниткам, а не задачам . так что это было в основном, стихийное бедствие . Комитет По Стандартам ™ запилил их в план работ на много лет вперёд . это включает составимый (composable) параллелизм уровня задач, каналы для коммуникации, которые как надеемся, заменят futures, отмену задач и вероятно, в течение долгого срока времени, параллелизм уровня данных, включая поддержку GPU . производная микрософтовского PPL и интеловского TBB должна стать частью стандарта (надеемся, что не Microsoft AMP).

напряжёмся и поверим что все эти штуки будут стандартизированы и реализованы, скажем, к 2015 году . даже если это и случится, я всё ещё не думаю, что у людей получится использовать С++ для мейнстримного параллельного программирования . С++ проектировался для однопоточного программирования, и параллельное программирование требует революционных, а не эволюционных изменений . два слова: гонки данных . императивные язычки не предлагают защиты от гонок данных — возможно, за исключением D.

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

в D, по крайней мере, есть понятие о глубокой константности (deep constness) и иммутабельности (immutability) (никакая нитка не может изменить иммутабельную структуру данных) . ещё один кивок в сторону конкурентности от D это возможность определить чистые (pure) функции . к тому же, в D мутабельные объекты по умолчанию не разделяемые между нитками . хотя наиболее важно то, что нитки не являются хорошей абстракцией для параллельного программирования, так что этот подход не будет работать с легковесными задачами и очередями, ворующими работу (work-stealing queues), где задачи передаются между нитками.

но, С++ не поддерживает НИЧЕГО из этого и похоже, никогда не будет поддерживать.

конечно, вы можете узнать все эти особенности (features) про-конкурентноси и параллелизма как функциональное программирование — особенно, иммутабельность и чистые функции . рискую надоесть напоминаная: Хаскель на голову впереди кривой по отношению к параллелизьму, включая программирование GPU в factor тоже прикольно писать GPU-шныя шейдеры. это было причиной тому что я так легко перебрался на Хаскель после стольких лет проповедования (evangelizing) хороших С++ практик . каждый программер, серьёзно относящийся к конкурентности и параллелизьму должен выучить достаточно Хаскеля, чтобы понять как с этим справляться . есть отличная книженция Симона Марлоу, параллельное и конкурентное программирование для тех, кто в штанге . после того, как вы её осилите, вы либо начнёте применять функциональные техники, программируя на С++, либо поймёте какая непонятка и нестыковка (impedance mismatch) существует между параллельным программированием и императивным недоязычком, и переключитесь на Хаскель головного мозга.

выводы

я верую ad absurdum, что язык С++ и его хилософия напрямую конфликтует с требованиями параллельного программирования . этот конфликт отвечает за очень медленное осиливание (uptake) параллельного программирования в попсовой (мейнстримной, mainstream) разработке программ . мощь многоядерных процессоров, векторных блоков и ЖПУ (GPU) просераюцца проматываются из-за устарелой парадигмы программирования.

список литературы

вот я привёл некоторые мои публикации про управление ресурсами:

1 . Бартош Милевски, «Управление Ресурсами В С++», журнал по объектному ориентированию программированию, март/апрель 1997, том 10, № 1 . стр . 14-22 . это было ещё в эпоху до unique_ptr, так что я использовал auto_ptr, чего бы это ни стоило . поскольку у вас не может быть векторов auto_ptr я реализовал auto_vector.

2 . Отчёт о С++ в сентябре 1998 и феврале 1999 (всё ещё с auto_ptr)

сильные указатели и управление ресурсами в С++

управление ресурсами в действии

С++ в действии (всё ещё auto_ptr), Аддисон Висли 2011 . смотрите вырезку из этой книги про управление ресурсами

бродим вниз по лужайке памяти, Андрея Александреску CUJ октябрь 2005 (используя unique_ptr)

unique_ptr — насколько оно уникально? издательство WordPress (LOL) , 2009

Вот моя критика в бложике подхода С++11 к конкурентноси:

асинхронные задачи в С++11: ещё ниаслили поломанные обещания — будущие (futures) из С++0х-= эдвард руки-из-жопы: маразм нам дал стальные руки крюки, а вместо серца плазменный С++ головного мозга =-

// ваш К. О.

на самом деле, С++ ABI придумали долбозвери.

+10500. но, Ватсон, почему?

на самом деле в С++ не одно ABI, а несколько. вместо одного calling convention как в Cшном cdecl (для шиндосовцев — stdcall) есть целых три:

1. статический метод класса

2. невиртуальный метод

3. виртуальный метод.

и все эти соглашения разные для разных случаев. пруфлинки: 1 (у него ещё книжка есть), 2 3

плюс, добавь к этому разные ABI для x86 и AMD64.

плюс, манглинг.

плюс, надо как-то вставлять в рантайм запуск всех этих конструкторов и деструкторов в нужный момент (см. например рантайм С++.NET)

плюс, линковка .got и .plt, как ты сказал (однако, есть prelink)

А ведь можно просто добавить экспортную версию vtable где виртуальными будут все методы, и даже статические функции будут «виртуальными». И экспортировать один символ на класс.

одним символом на класс, ИМХО, вряд ли обойдёшься. но вот в SOM например экспортировалось не более трёх

ведь можно просто добавить экспортную версию vtable где виртуальными будут все методы, и даже статические функции будут «виртуальными». И экспортировать один символ на класс. Ибо что так 2 чтения(из plt и из got), что по новой читать указатель на vtable и прыгать прямо туда. Только указатель на vtable компилятор может скэшировать в стеке а got и plt хрен скешируешь.

да или вообще, обойтись няшной сишечкой

или, если у вас диабёт, и хочется сахарку: взять vala или ooc

хорошо известный пример чего не надо делать: это использовать malloc для динамического выделения памяти,

4.2

по-настоящему правильной версией будет:

расскажите уже человеку про STL:

vector<int> pod(10);

а то он переизобретает то, что давно уже есть

С++ стал крайне сложным языком

да

вам всерьёз нужно посмотреть на Хаскель

где можно посмотреть на то, что он написал на хаскеле?

хммм... пакетный менеджер для C++ правда, только под шindoвз

у него в бложике есть то, как он из С++ пытается сделать хаскель. презентации с pdf-ами про всё это.

а что он написал на хаскелле, а не на плюсах — х.з., искать надо

у тебя преждевременная эякуляция пост-отправление?

дальше не читай @ сразу отправляй

он говорит про STL, что и это не решает всех проблем. потому что не exception safe, thread safe, constness/immutable safe.

и НИЧЕГО не поделаешь, это С++.

маленький магазинчик ужасов

err, вот эта ссылка правильней

тёплый ламповый трешъ.

исчо рекомендую «атака крабов-монстров» того же автора.

Тёзка, что за пустой прогон?

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

link fixed Омары

дальше не читай @ сразу отправляй

я пролистал вниз, увидел много букав и ниосилил

он говорит про STL

т.е. просто решил позанудствовать, окай

что и это не решает всех проблем

идеальных решений вообще нет

потому что не exception safe

где можно найти человека, которому это помешало? я много видел проблем с С++, но вот, чтоб кто-то рассказывал, как плохой не exception safe std::vector ему помешал - нет

thread safe

ну так правильно - нужно брать thread safe версию, если не хочется думать, например такую:

http://msdn.microsoft.com/en-us/library/ee355343.aspx

constness/immutable safe

да ладно

и НИЧЕГО не поделаешь, это С++.

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

пойду погамаю в йоба-игры на хаскеле

кстати Кармак вроде несколько лет как переписывает на нем Wolfenstein 3D, вот как закончит - будет просто прорыв

8 лет я слышу про проблемы C++ и 8 лет программисты продолжают писать на нём. И это только моё впечатление, олдфаги поднимут это число разика так в 2 как минимум.

Ничего не поделаешь, недостатки есть везде, но достоинства C++ очень часто их перевешивают.

А вышеупомянутый Хаскель - далеко не панацея. И тоже имеет проблемы, не такие как у С++, а совершенно другие, понятное дело.

//прошу прощения за пост в стиле капитана Очевидности

переписывает на нем Wolfenstein 3D, вот как закончит - будет просто прорыв

где-то есть сорцы? ну кто ж в детстве не читал исподников того старого вольфенштейна 2.5D ещё на turbo C++.. (или там уже watcom был?)

простой, понятный рейкастинг.

а как это в зигохистоморфных препроморфизмах будет?

обратный кв. корень через монады? =))

где-то есть сорцы?

вроде нет, он когда-то упоминал это, потом в твиттер кинул сообщение и пока все глухо :(

тезисы в том, что

1. старая парадигма программирования на С++ мешает нормальному осиливанию параллелизма и конкурентности

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

3. а зачем тогда нужен скрипач С++? скрипач не нужен, родной

но достоинства C++ очень часто их перевешивают.

плюс, за ГОДЫ существования С++ он так и не стал платформой. ну почти как лисп, но с CL например другая история: это создание систем, и фичи лиспа для создания программы-как-системы вполне себе адекватны, в разрезе более общей системы.

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

но, в С++ и этого нет!! что же это такое, за что ни хватишься, ничего у большевиков С++-ников нет

но, в С++ и этого нет!! что же это такое, за что ни хватишься, ничего у большевиков С++-ников нет

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

внезапно, поковырял Factor. приходится ставить мозги раком, но игрушки на OpenGL с шейдерами и FFI в примерах занятные. внятный FFI, богатая библиотека, в полпинка прикручивается EBNF через PEG для всяческих DSL-лей (например, инфиксный синтаксис и т.п.). XML, вебсервисы, функциональные структуры данных и прочая прочая.

вот только писать на этом всём — надо окончательно упороться.

проще уж взять из contibs смоллток через PEG и писать на нём, как-то привычнее :))

ссылка надмозгов и энциклонгов про impedance mismatch

OMFG!! LOL у них все статейки такие

WTF это за энциклонги? надмозги отакуэ