Язык D

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

Ага. Тут ещё на Си++ написали Qt. А на других языках не написали, поэтому написание программ на Qt это отличная ниша для Си++. А на других языках Qt возможно и нельзя написать. А если и можно, то ещё никто не написал, давайте мне аналогичное решение на Java. А, нету? Ну тогда слив засчитан.

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

Тут ещё на Си++ написали Qt. А на других языках не написали

Как это не написали? От Turbo Vision до Swing.

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

Бла-бла-бла. Хотя бы одну числодробилку приведите, с эффективностью не уступающей тому что я по ссылочке описывал, балаболище Вы наш «повсеместно наблюдающий».

Вот Вам, можете почитать на досуге http://a-iv.ru/lev/disser.pdf (осторожно, 100Мб).

лучше изучай Ada.

От Turbo Vision до Swing.

Нужен именно Qt, таким уж образом этот дурачок вопрос поставил.

Нужен именно Qt

Нужно «аналогичное решение».

таким уж образом этот дурачок вопрос поставил.

«Этот дурачок» точно умнее тебя.

Нужно «аналогичное решение».

Это ты уже сам придумал.

«Этот дурачок» точно умнее тебя.

Ты тоже считаешь, что си++ лучший выбор для математических расчетов?

Нужно «аналогичное решение».

Это ты уже сам придумал.

Это цитата: Язык D (комментарий)

Alv> давайте сюда аналогичное решение не на плюсах

«Этот дурачок» точно умнее тебя.

Ты тоже считаешь, что си++ лучший выбор для математических расчетов?

Неважно, что именно я считаю, потому что промышленное числодробление - не моя область. Нашу математику мы пишем на Python.

P.S. можешь задать себе вопрос «а почему Chrome написан на Си++?».

Нужен именно Qt,

Дислексию здесь не лечат.

Нужно «аналогичное решение».

Это ты уже сам придумал.

Это цитата: Язык D (комментарий)

Alv> давайте сюда аналогичное решение не на плюсах

Хорошая постановка вопроса: 1. Находим какую-то одному тебе известную опердень. 2. Говорим, что нам нужна аналогичная опредень, но на других технологиях. 3. Никто эту опердень, а уж тем более её аналогов не видел. 4. Профит!

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

Нашу математику мы пишем на Python.

Ага, и я ещё дурак после этого, *facepalm*.

P.S. можешь задать себе вопрос «а почему Chrome написан на Си++?».

Потому что webkit, разве это так сложно?

Слабоумие, я вижу тоже.

Нашу математику мы пишем на Python.

Ага, и я ещё дурак после этого, *facepalm*.

В общем, да. Потому что не знаешь о том, что такое промышленное числодробление, но споришь об этом.

В общем, да. Потому что не знаешь о том, что такое промышленное числодробление, но споришь об этом.

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

Вы выполняете численные операции на питоне, сами говорите, что численные операции не ваша область, но оцениваете уровень других людей в этой области? Каноничный Данинг-Крюгер.

Вы выполняете численные операции на питоне

Разница между тем, чем занимаемся мы, и промышленным чслодроблением - в том, что мы с удовольствием заплатим 50% производительности за в 5 раз более быструю разработку.

сами говорите, что численные операции не ваша область

Да. И даже того немногого, что я знаю, достаточно, чтобы не судить о том, какие инструменты нужны для этой работы.

А ты реально глуп.

И даже того немногого, что я знаю, достаточно

Конечно, конечно, не волнуйтесь.

А ты реально глуп.

А ты нереально.

Вы меня своим балаболством утомили. Может true_admin Вам более доступно сможет объяснить в чем Вы заблуждаетесь? От Вас так много букв и хамства, и ни одного ответа нормального на конкретно поставленные вопросы.

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

И многим это не нравится, но никуда от этого не уйти. Поэтому и хочется видеть язык, который может дать реальную альтернативу перечисленным языкам. Кто там пытается сейчас D(мертворожденный, видимо), Go(что-то даже яву перегнать не может), Rust(ждать или нет?)... Limbo, быть может еще, но говно ведь...

Хоть свой пиши=)

Может true_admin Вам более доступно сможет объяснить в чем Вы заблуждаетесь?

fixed.

Юлю забыл

Правда, она пока, вроде, сырая...

Вроде это ты ни разу не поведал, какая уберфича крестов позволяет ваш уберметод реализовать. От тебя лишь ссылки на твои портянки по 100 мегов. Кому сдалось читать твою предметную область забесплатно?

Скажи конкретно: что вам дают кресты в вычислительном ядре, что не может быть сделано на, скажем, 90-2003 фортране?

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

Сейчас вроде в паскале есть шаблоны, в хаскеле заложены идеи чем то мхожие с LRnLA. Но в крестах видимо ко всему компайлер очень здорово оптимизирует, поскоку в него очень много труда вложено, это ж типа мэйнстрим;-)

Ну сыровата, да и не так широко, как плюсы, применима.

Ну я думаю, что фортран дал бы те же показатели производительности. Еще можно было и чистый С брать. Но это, мягко скажем, не самые выразительные языки. Так вот, С++ на сегодняшний день единственный язык, которые позволяет писать относительно высокоуровневый код без потерь производительности и оставляя возможности ручного контроля и оптимизации «до последнего».

Кроме С++, я активно пишу на python, lua и scala. И с удовольствием не вспоминал бы С++ как страшный сон...

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

Go(что-то даже яву перегнать не может)

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=g... http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=g... Вполне может (inb4: regex-dna), даже несмотря на http://golang.org/doc/go_faq.html#Why_does_Go_perform_badly_on_benchmark_x

Специально для любителей «низкоуровневого контроля»: http://blog.golang.org/2011/03/c-go-cgo.html

Для особо одаренных - компилятор с хорошей оптимизацией и рекурсия на шаблонах, это как мин.

Сдаётся, по делу сказать тебе нечего.

Так где там обещанные числодробилки на других ЯП? Кабы Вы были в теме, по делу бы могли привести десяток-другой...

ЗЫ Вы меня совсем утомили. Хотите продолжать диалог - научитесь быть вежливым.

Спасибо. Я вообще то не имел ввиду столь радикальные меры... «Но ход Ваших мыслей мне нравится»(с);-)

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

Ну я думаю, что фортран дал бы те же показатели производительности.

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

Что-то я не вижу по вашим ссылкам, что может. Проигрывает(за редким исключением) и Java и, тем более, С/С++.

Уберфича, по большому счету, одна. Дизайн языка, направленный на такое построение средств абстракции и управления сложностью, которые позволили бы не забывать о реальной системе, а еще не мешали бы тем людям, которые не хотят их использовать(принцип нулевой стоимости). Да, недостатков много, но что делать? Альтернативы достойной нет.

Впрочем, помимо недостатков, есть и достоинства. Мне вот интересно, как мне нормально выразить идиомы, вроде NVI, RAII, как нормально работать с гарантиями безопасности обработки исключений и т.д. и т.п. Это все появилось в сообществе С++ программистов и плохо выразимо на других языках. Иногда мне этих фич не хватает...

Юлю забыл

Юля - это что?

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

http://blog.golang.org/2011/06/profiling-go-programs.html
Профилирование программы на го, может быть интересно.

Юля - это такой перерожденный открытый оптимизированный MATLAB

Но с одной стороны кресты позволяют писать высокоуровневый и лаконичный код

Не позволяют — даже замыканий нормальных нет.

с другой стороны этот код может быть очень эффективным (можно объяснить компайлеру что именно от него нужно за счет низкоуровнего ручного управления памятью и жонглирования указателями).

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

Со всем вышеупомянутым лучше справится любой Лисп, особенно с оптимизациями по декларациям типов.

В общем, так мы и не услышали начальника транспортного цеха.

Какой, мля, лисп? Ты что курил? Его семантика в принципе не может привести к высокой производительности. Я уже не говорю о прямой работе с системой под ногами. Хватит сказки рассказывать, я наслушался уже вас. Теперь знаю scheme, common lisp и clojure. И они такое же говно, как и другия языки.

Так что С++ в плане производительности пока наше все :( Rust может быть потом. Но они уже отказались от настраеваемой работы с памятью. Сейчас там RC с поиском циклов, планируется полноценный GC. Семантически поддерживаются регионы, но профита от этого нет(в плане кастомизации работы с памятью, понятно, что они обеспечивают безопасность и предотвращают висячие ссылки). А хочется, чтоб я мог выбирать и стратегию управления памятью(GC, RC, руками(с выводом регионов и проверкой корректности кода), etc.) и мог еще выбирать и писать свои аллокаторы(как в С++, это часто помогало увеличить производительность). В С++ мне не хватает концептов и модулей, по большому счету. Ну и лишнего много.

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

Не позволяют — даже замыканий нормальных нет.

А нафига они там? На замыканиях свет клином не сошелся.

Со всем вышеупомянутым лучше справится любой Лисп, особенно с оптимизациями по декларациям типов.

Ничего не могу сказать по поводу Лиспа, я его не знаю. По поводу оптимизаций по декларациям типов (если это именно то, как оно называется) - такой проблемы лично у меня не стоит.

По поводу применения Лиспа к описанным мною задачам на ЛОРе все обсасывалось со всех сторон, в т.ч. весьма квалифицированными людьми (типа mv) и даже такими «мегамосгами» как лавсачег. Общее заключению было - Лисп рудит для кодогенерации (на С), настройке плисок, и не более того.

ЗЫ это Вы что ли новый логин себе завели, заместо metadeus?

Его семантика в принципе не может привести к высокой производительности.

Назовите конкретное противоречие семантики Лиспа и высокой производительности.

А хочется, чтоб я мог выбирать и стратегию управления памятью

Ну так в сабже топика это есть в отличие от плюсов, например.

По поводу замыканий. Что вам не нравится?

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

По поводу замыканий. Что вам не нравится?

Мне вот по поводу замыканий не нравится, что target для std::function / boost::function может возвращать nullptr (после capturing и bind). То есть замыкания вроде как и не функции вовсе.

А нафига они там? На замыканиях свет клином не сошелся.

Вопрос был «кресты позволяют писать высокоуровневый и лаконичный код», без полноценных замыканий это трудно себе представить.

ЗЫ это Вы что ли новый логин себе завели, заместо metadeus?

Пришлось, а ту у кого то аргументы кончились и он наябедничал воспитательнице, а мне тут вообще-то другой топик интересен.

без полноценных замыканий это трудно себе представить.

Возможно у Вас проблемы с воображением?;-)

у кого то аргументы кончились и он наябедничал воспитательнице

В забавном мире Вы живете... Хочу отметить, что бан пошел Вам на пользу, Вы стали куда вежливей:

– Не извольте беспокоиться, мессир, – отозвался Азазелло и обратился к Варенухе: – Хамить не надо по телефону. Лгать не надо по телефону. Понятно? Не будете больше этим заниматься?

Возможно у Вас проблемы с воображением?;-)

Вам хватает низкоуровневых средств языка, а у меня плохо с воображением? Оригинально, как всегда.

В забавном мире Вы живете... Хочу отметить, что бан пошел Вам на пользу, Вы стали куда вежливей:

Ага, если бы я за форму бан получил) За форму я предупреждение получил, а бан за обоснованное несогласие с линией партии.

Ну тогда просветите меня пожалуйста (я вообще то не программист), зачем Вам так нужны замыкания, и почему кроме замыканий Вы других высокоуровневых средств не представляете.

зачем Вам так нужны замыкания

Замыкания отличный способ ограничения сложности и реализации модульности через ограничение видимости. В JavaScript на этом весь ООП построен, который на порядок мощнее c++'ного. Функциональщина, опять же, нормальная без замыканий не получится (boost::bind и проч. это костыли).

кроме замыканий Вы других высокоуровневых средств не представляете

Это опять вы мне свои суждения приписываете. Помимо замыканий ещё не плохо было бы нормальный ООП иметь, шаблоны, которые от использования по назначению не приводят к компиляции по полчаса, модулей, макросов структурных, рефлексии полной, сборщика мусора отключаемого, поддержки юниттестов, поддержки параллелизации и синхронизации в коде (вот что главное для числодробилок), развитой системы типов (АТД для начала) с выводом (кое как дождались этого убогого auto), иммутабельность и чистые функции, контракты и аспектное программирование, да много ещё чего. Только если они все это будут добавлять в том же виде, в каком сейчас добавляют новые возможности, то скоро код на си++ уже совсем приблизится к #@(%@#)$)$^<#)@>>#$^@(%@*#&$^)

Судя по всему замыкания в C++11 запилили достаточно мощные, но они полностью в духе C++ и содержат просто воз новых граблей, на которые теперь тоже стало можно наступать. Вот например создал разработчик внутри метода класса замыкание [&] использующее внутри явно или неявно this, вернул его наружу и теперь исполнение этого замыкания напрямую зависит от области видимости объекта класса, который может быть даже shared_ptr, а толку 0, т.к. эта ссылка не отслеживается, теперь ему надо будет писать что-то типа: shared_ptr<decltype(this)> this_ptr(this); [=]{ decltype(*this)& this_ref = *this_ptr; this_ref.some_method(); }

Ну или как-то так.

Помимо замыканий ещё не плохо было бы нормальный ООП иметь, шаблоны, которые от использования по назначению не приводят к компиляции по полчаса, модулей, макросов структурных, рефлексии полной, сборщика мусора отключаемого, поддержки юниттестов, поддержки параллелизации и синхронизации в коде (вот что главное для числодробилок), развитой системы типов (АТД для начала) с выводом (кое как дождались этого убогого auto), иммутабельность и чистые функции, контракты и аспектное программирование,

Такое впечатление, что кто-то излагает свой эротический сон.

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

Все таки ИМНО это один из способов, и не более того. Я как то не чуйствую его прямо такой вот выдающейсти, что токо вот так и никак иначе.

Функциональщина, опять же, нормальная без замыканий не получится

Я ФП юзаю тока в питоне, и обхожусь в ней как то без замыканий. Редко-редко когда чего то закложурю... может я какие то не те замыкания имею ввиду?;-)

шаблоны, которые от использования по назначению не приводят к компиляции по полчаса

Ну последние компиляторы стали сильно шустрее по отзывам коллег.

развитой системы типов (АТД для начала) с выводом (кое как дождались этого убогого auto)

Полностью согласен.

поддержки параллелизации и синхронизации в коде (вот что главное для числодробилок)

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

Вы все правильно говорите. Так никто и не утверждает, что С++ это идеальный ЯП (который Вы описываете). Напротив, все от него плюются. Но главный тезис - ЯП кошмарный, но лучше ДЛЯ ОПРЕДЕЛЕННОГО КЛАССА ЗАДАЧ увы нету. И пока не видно на горизонте...

Если говорить за те же числодробилки (к-ми мы занимаемся) - с программисткой т.з. это примитивные коды, где 99% описанных Вами вещей нафик ненужны. Но есть нюанс, они должны очень быстро молотить очень большие объемы данных. И дальше, все танцы с бубном связанны именно с тем, что стандартные решения неэффективны, а эффективыне решения не стандартны и требуют извращений. Но опять таки, эти извращения должны давать на выходе эффективный код (что бы накладки на извращения были минимальны) и все описанное Вами тоже ненужно. Замыкания там ну не представляю как присобачить... ;-)

Такое впечатление, что кто-то излагает свой эротический сон.

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

Какая глубокая мысль

А то. В реальности приходится выбирать из реальных инструментов, а не из тех, которые существуют в эротических снах. Языка с фишками, которые ты описал, в природе не существует. И, полагаю, существовать не будет (разве что в виде C# 9.0).

и как я вообще мог этих милых людей за дураков принять?

Каких «людей»? Я двоюсь у тебя в глазах?

Блин, я тоже хочу так же лаконично как ты излагать свои мысли... устал что ли под конец года, или просто язык чешется?;-(

Каких «людей»? Я двоюсь у тебя в глазах?

Это он про меня наверное;-)