Здравствуйте, VladD2, Вы писали:
VD>Не достаточно. Надо чтобы они везде валялись. К тому же по Лиспу нет ни одного хорошего учебника на русском. Это факт.
Здравствуйте, VladD2, Вы писали:
VD>Я я их не терял. Просто это все преимущества инфраструктуры, а не языка.
Осталось обосновать отсутствие влияния языка на инфраструктуру.
Я это к тому, что если бы вместо Си++ в то время и в том месте оказался бы OCaml, далеко не факт, что он бы стал мейнстримом вместо Си++.
Или ты считаешь, что стал бы?
Просто звучит это так, будто от языка вообще ничего не зависит, кругом правят деньги и большие корпорации. Оно, конечно, ради бога, только к чему тогда споры о языках вообще, если от них толку ноль?
Divide et impera это, конечно, хорошо, только для начала следует убедиться, что разделять можно.
Здравствуйте, VladD2, Вы писали:
VD>Дык как только начинаешь задумываться, так сразу становится ясно, что С++ как раз наихудший выбор почти всегда. То есть если спросить меня, что могло бы подвигнуть меня к использованию С++, то я бы ответил очень просто — полное отсутствие альтернативы и очень большой бюджет.
Здравствуйте, VladD2, Вы писали:
VD>Речь шла о преобразовании финансовых данных на биржах, как я понял. Поверить в то, что скажем на Лиспе это было бы сделать в разы проще программист не захотел.
При работе на бирже необходимо очень высокое быстродействие. Как для анализа данных, так и для банальных автоматических торговых систем. Да, их пишут на С++. И нейросети для предсказания курсов на фондовых и валютных рынках тоже. А это как-никак область ИИ (это про твои высказывания о непригодности для интеллектуальных задач).
VD>Ну, пусть откликнутся те кто его пишут. Ау... Где вы...
Я. По работе — анализ видео. Есть, например, ограничение по времени на обработку одного кадра стандартного разрешения — 5 млсек. Это на сжатие (или, наоборот, разжатие), анализ, сохранение на диск. Система мягкого реального времени.
Как хобби занимаюсь иногда как раз предсказанием курса валют. На выходных, бывает, загружаю простаивающую сетку на работе — тот же анализ данных, расчёт статистики всякой и т.п. Представь, что обработка работала бы в 5 раз медленнее — ждать пришлось бы не 2, а 10 дней. Плохо же
VD>>>Тут как минимум нужно использовать библиотеки написанные на ассемблере с применением симд-инструкций, а по уму данные вычисления вообще стоит переложить на плечи современных видеокарт которые имеют и соотвественный набор команд, и вычислительные мощьности в разы большие чем у современных универсальных процессоров.
Видеокарты, например, умеют работать только 4-х байтовыми float. Для многих задач это принципиальное ограничение. И оно не единственное.
VD>А так и просто библиотека будет рулить. Напиши ее или возьми от того же Intel-а и использовать из любого компилируемого языка. VD>Вот только решение на видюже один фиг порвет все твои выкрутасы.
Можно посмотреть на содержание тех же интеловских библиотек, на задачи которые они решают. Это область применения С++. А там и обработка сигналов, видео/аудио, сжатие, криптография, строки/регэкспы даже есть. Не говоря уже об универсальных математических библиотеках.
Возьмём очень универсальный пакет Матлаб. Ох, и у него математика лежит в dll, написанных на С++.
Я хочу сказать, что адекватных задач для языка С++ много. Кому-то они встречаются редко, а у кого-то постоянно перед глазами. Не стоит абсолютизировать собственный опыт.
VladD2,
LCR>>Динамическая область видимости есть ещё в StringTemplate — неплохой язык для построения генераторов.
VD>Ага, неплохой. Еще бы не было этой фичи и было бы побольше контроля, и вообще бы бы замечательным. VD>На мой взгляд это была ошибка дизайна. Потом автор создал шаблоны с параметрами и они полностью устранили необходимость в динамической области видимости.
И как обращаться из глубоко вложенного шаблона к параметру внешнего шаблона? Если бы не было динамической области видимости, пришлось бы писать такие кренделя (протаскиваем var вглубь до template10):
block(var) ::=
много текста <template0(p1=var, p2="preved")>
template0(p1, p2) :=
много текста <template1(p1=var, p2="medved")>
template1(p1, p2) :=
много текста <template2(p1=var, p2="andvvp")>
...
template10(p1, p2) :=
наконец тут мы получаем доступ к <p1>
который равен <var> и можем его использовать
А с динамической областью видимости можно обратиться прямо к var из template10 не протаскивая его через всю цепь вызовов. В обычных языках это конечно решается просто созданием глобального относительно template0..template10 бинда, а здесь такого нет. Или как?
Здравствуйте, Pzz, Вы писали:
Pzz>Довольно трудно формально сформулировать, что такое "правильный" C++ код. Как начнешь формулировать, на выходе все pure ANSI C получается
Да не надо формулировать. Вполне достаточно понимать
Типа требуешь все выходы на "танкоопасные направления" (например: написание любых шаблонов, написание любых макросов, и т. д.) согласовывать с непосредственным начальников, предоставляя письменное обоснование необходимости такого решения.
С начальника спрашивать, если одобрил то, что сам не может обосновать. Так что если сомневается -- пусть у главного гуру какого-то фирменного консультируется.
Pzz>Ну и следить все время за соблюдением сил никаких нет.
Ну при всплытии факта имеют сильно исполнителя и очень сильно его начальника и далее по цепочке...
Pzz>Штрафы, кстати, запрещены Трудовым Кодексом. Остается только гнать в шею
Вот тоже мне проблема. Зато премии не запрещены...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, VladD2, Вы писали:
VD>Дык я примерно это и сказал. Только реальное его использование только в малом проценте случаев обусловлено реальной необходимостью. Слишком часто на С++ пишут разные конверторы, системы управления бизнес-задачами и прочую муть для которой С++ явный оверкил. Но тем кто кроме лопаты ничего в жизни не освоил кажется, что копать траншеи лопатой самое оно.
Про лопату -- это всё прикольно конечно, но С++ намного сложнее лопаты, так что аналогия не рулит
D>>"Обработка" читай распознавание\ интеллектуальная обработка, когда обрабатывают на биты пикселей, а информацию, которую они несут.
VD>Для меня слова "интеллектуальная" и С++ просто не совместимы. Так что не смешите мои тапочки. Хотите интеллекта, берите МЛ-клоны. По скорости они будут на уровне, а интеллекта там в разы больше. Ну, и "когда обрабатывают на биты пикселей" — это простите просто маразм. Такие вещи что на JavaScript, что на C++ будут работать дико медленно (относительно конечно). Тут как минимум нужно использовать библиотеки написанные на ассемблере с применением симд-инструкций, а по уму данные вычисления вообще стоит переложить на плечи современных видеокарт которые имеют и соотвественный набор команд, и вычислительные мощьности в разы большие чем у современных универсальных процессоров.
IMHO, ты не там интеллект ищешь...
Есть куча задач, в которых кодирование не представляет вообще никакой проблемы. Проблему представляет разработка и настройка алгоритмов. И тогда годится любой процедурный язык, без существенного встроенного оверхеда и поддерживаемый промышленными трансляторами и средами разработки...
И тогда, зачастую, конкурируют как раз С++ и C... Следующий кандидат (уже сильно хуже) -- что-то ООП из наследников PASCAL...
VD>Дык как только начинаешь задумываться, так сразу становится ясно, что С++ как раз наихудший выбор почти всегда. То есть если спросить меня, что могло бы подвигнуть меня к использованию С++, то я бы ответил очень просто — полное отсутствие альтернативы и очень большой бюджет.
Вот тебе три задачи:
1) Написание базы данных
2) Написание системы, которая в реальном времени анализирует изображение с размещённых в здании камер и привлекает внимание оператора к подозрительным случаям (несанкционированный доступ кого-то куда-то, несанкционированное поведение и т. д.)
3) Написание системы, которая анализирует видео с камеры наблюдения ГИБДД и выдаёт чкриншоты с наилучшими фотками нарушителей + госномер машины нарушителя.
На чём реализовывать будем?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, VladD2, Вы писали:
CC>>Не все алгоритмы возможны на видяхе. Баловался с CUDA — пока оно применимо в частных случаях.
VD>Не все. Но по иронии судьбы те что доступны один фиг пишутся на С++ и их разработчики гордятся "высокой" производительностью. Хотя реально она просто никакая... в сравнении.
Зато идут на любой машине... И на любой машине одинаково работают, к тому же...
"Куда" пока что, увы, только для разового кода хороша... В коробочный продукт (особенно, если это не игрушка) её ставить как-то стрёмно.
Ну и потом, КУДА, она пока что вроде как тока С и С++ поддерживает?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, VladD2, Вы писали:
VD>>>Ага. То же преимущество имеют Лисп (есть компилятор в нэйтив), Окамл, и еще пара десятков не так распространенных языков. ГВ>>Правильно. Разница в размерах, как минимум. VD>Размерах, чего, простите? Или это снова пенисометрия?
В размерах добавляемого кода к распространяемому исполняемому модулю.
ГВ>>Кто есть "офисный планктон"? VD>Те кто выбирают инструменты "как все" и пишут код "как у всех" в итоге решая, скажем, задачи офисной автоматизации на С++.
Иными словами, офисный планктон — это мейнстрим в кристалльном виде. Интересно.
ГВ>>Ты на порядок-другой не ошибся? Только у меня в одном небольшом относительно проекте используется четыре сторонних библиотеки. VD>Нет. В лубщем случае буст, асе и еще пара либ. И то не всегда. Чаще все же велосипеды.
Со свечкой везде постоял, чтобы такое утверждать?
VD>Я все могу понять. Но при этом я прекрасно понимаю, что стремление к велосипедостроению вызвано двумя основными факторами: VD>1. Дурью в бошке.
Оставим за скобками.
VD>2. Низкоуровневостью и отсуствием полноценных стандартов в С++.
Полноценных — это каких?
VD>Если сравнить положение дел с библиотеками в С++ и Яве/.NET, то разница видна невооруженным взглядом.
Безусловно. Велосипеды явы и дотнета ещё впереди.
VD>Можно сказать, что Яве и .NET проектировались так, чтобы стать отличной платфоромой для библиотек и фрэймворков. Да и не маловажно, что прямо в составе платформ поставляется огромнейшая стандартная библиотека. Чего в С++ не было, нет и видимо никогда не будет.
И это просто замечательно, что C++ не занимается предписыванием реализации примитивов.
ГВ>>Попробуй просто поверить, что если бы, например, Lisp оказался столь же распространён, как C++, то на нём велосипеды строили бы не реже. [...] VD>Зачем мне представлять "бы"? Я привел совершенно конкретный пример Яве/.NET. В них же все ОК с либами?
Как это — OK? Почему же тогда bltoolkit появилась? Натуральный велосипед.
ГВ>>Что лишний раз подтверждает тезис об интерфейсе с C. Теперь в этой компании ещё и .Net. Ну что ж, пусть зацветают все цветы. VD>Дык это еще и подтверждает истинность другой мысли... Не обязательно быть совместимым с С сверху вниз, чтобы быть совместимым с интерфейсом С. Дотнет, и тот же Ди это отлично демонстрируют. В прочем как Питон и многие другие. А вот совместимости с С++ нет, и никогда не будет. Даже содатель Ди на это не пошел. Потому как ради дурацких велосипедов не стоит реализовывать монструозный С++ как часть другого языка. Все что надо интегрируется через С-интерфейс.
Я не собираюсь спорить с тем, что C-интерфейса зачастую достаточно. Насчёт рассуждений относительно C++ в этом контексте — так он сам в каком-то смысле находится в компании языков, имеющих интерфейс с C.
И ещё пара интересных моментов: например COM имеет хорошие такие корни в C++ (за что его и ругали одно время), GDI+ — пусть не корни, но как минимум интерфейс.
ГВ>>>>А остальные прогрессивные парадигмы благополучно плещутся в среде, которое создало ПО на C/C++. Вот такая вот идиллия. VD>>>Да кого трогает где и кем была создана ванна? Большинство людей волнует удобство этой ванны и ее чистота. ГВ>>Большинство вообще ничего не волнует, кроме холодильника и комфортабельности кресла. Статус-кво это никаким образом не меняет. VD>Ну, да. Некоторые по году не моются. Но мы вроде не об этом...
Ну, если ты имеешь в виду, что некоторые по году не залезают в ванну мейнстрима, то тут ты прав.
VD>>>* Огромная разрекламмированность. ГВ>>Странно, что при этом взрывное распространение C++ не сопровождалось рекламной компанией. Больше того, в то время существовала ещё груда объектных языков. На вскидку могу вспомнить VD>У того времени были свои особенности. Сейчас все не так. Да и реклама была не хилая. АтиЭндТи тогда была очень влиятельная контора. Они вот ОС свою протащить сумели.
Ты считаешь, что кроме рекламы от нехилой AT&T никаких больше факторов не способствовало продвижению Unix? А может быть, дело в том, что Unix оказался вполне удачной переносимой многопользовательской ОС, которая в самом деле позволила переносить ПО с одной машины на другую?
VD>>>* Наличие огромного количества учебников и другой литературы. ГВ>>Достаточно одного хорошего учебника по языку. По тому же Lisp, например, их вполне достаточно. VD>Не достаточно. Надо чтобы они везде валялись. К тому же по Лиспу нет ни одного хорошего учебника на русском. Это факт.
Надо, чтобы ещё их хотели купить. Не находишь, что есть некоторая разница между "валялись" и "хотели приобрести"?
ГВ>>Ну вот видишь, даже ты нашёл кучу преимуществ у C++. Хотя казалось бы. VD>Я я их не терял. Просто это все преимущества инфраструктуры, а не языка.
Так или иначе, но это имеет прямое отношение к языку. Если отставить в сторону пассажи про "офисный планктон", то наличие коммьюнити и поддержка гигантов в современных условиях — очень существенный аргумент. Я отнюдь не пытаюсь сказать, что он единственный, но то, что немаловажный — это бесспорно. Если ты не заметил, я здесь сам прибегаю к аргументам массовостью.
ГВ>>Скажу тебе по секрету, что С++ на самом деле — язык "системного" программирования. VD>Да чушь это. И используют его не для системного программирования, а для черт знает чего. А тот же Линкус и ядро НТ один хрен на С написано. А новые ОС пишутся но новых языках.
Кроме Singularity, про какие ОС ты ещё можешь рассказать, которые пишутся не на C? Желательно, про те, которые уже продаются или имеют приличные шансы на это. Поскольку иначе ОС есть и на Lisp.
Кроме того, в системное программирование, в общем, не только ОС включаются. В этот класс, скорее, имеет смысл зачислить весь "инфраструктурный" софт — в том числе библиотеки, серверы баз данных и, вполне очевидно, трансляторы языков программирования. То есть как раз вот тот самый ACE, про который ты вспомнил, вполне себе пример такой библиотеки.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Erop, Вы писали:
E>Вот тебе три задачи: E>1) Написание базы данных E>2) Написание системы, которая в реальном времени анализирует изображение с размещённых в здании камер и привлекает внимание оператора к подозрительным случаям (несанкционированный доступ кого-то куда-то, несанкционированное поведение и т. д.) E>3) Написание системы, которая анализирует видео с камеры наблюдения ГИБДД и выдаёт чкриншоты с наилучшими фотками нарушителей + госномер машины нарушителя.
E>На чём реализовывать будем?
E>>На чём реализовывать будем? N>Ко всем трем неплохо подходит OCaml.
1) А что, уже есть много пром. компиляторов, программистов, средств разработки, тоже промышленного уровня?..
2) (Кстати) Много баз на нём уже реализовали?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
E>IMHO, ты не там интеллект ищешь... E>Есть куча задач, в которых кодирование не представляет вообще никакой проблемы. Проблему представляет разработка и настройка алгоритмов. И тогда годится любой процедурный язык, без существенного встроенного оверхеда и поддерживаемый промышленными трансляторами и средами разработки...
А этот факт всегда игнорируется языкодвинутыми товарищами.
Могу свой недавний пример привести 182 строки кода на С++, 50 чистых рабочих часов. Интеллекта кстати немного, просто нужно было получить от WinAPI то что он не дает напрямую.
D>>OCaml Language Sucks
D>>Обратить внимание на: Arithmetic's readability \ No Polymorphism \ Standard Library Sucks
FR>Не надо читать ушибленных лиспом, это трава уровня немерле
Вроде бы в заметке приведены вполне адекватные аргументы (критика) — а уж в лисповом или в немерелевом трансе они явились автору значения не имеет
Здравствуйте, Didro, Вы писали:
FR>>Не надо читать ушибленных лиспом, это трава уровня немерле D>Вроде бы в заметке приведены вполне адекватные аргументы (критика) — а уж в лисповом или в немерелевом трансе они явились автору значения не имеет
Ocaml конечно корявый язык, но эти проблемы вполне разрешимы:
No Polymorphism — в сравнении с динамическим лиспом конечно, но даже для этого есть Object.magic который хоть и считается дурным тоном но вполне доступен.
Standard Library Sucks — тут он похоже просто искал к чему прикопатся
Здравствуйте, VladD2, Вы писали:
ГВ>>Ты на порядок-другой не ошибся? Только у меня в одном небольшом относительно проекте используется четыре сторонних библиотеки.
VD>Нет. В лубщем случае буст, асе и еще пара либ. И то не всегда. Чаще все же велосипеды.
по большому счету, этих 3-4 либ хватает для решения всех задач которые действительно стоит, можно и нужно решать на С++.
D>>>OCaml Language Sucks
D>>>Обратить внимание на: Arithmetic's readability \ No Polymorphism \ Standard Library Sucks
Про Arithmetic readability — это критика чисто базовых возможностей без учёта продвинутых. В Ocaml Mathematical Framework эта проблема решена вполне успешно с помощью ocamlp4:
let symb p = 3*x**2-2*x-3;;
let symb e = p*(sin(x+1)+log(x**2-2*x+2)-2);;
Здравствуйте, VladD2, Вы писали:
CC>>Я тут Числодробилки (не видео, но графические данные в том числе) писал до недавнего времени. С использованием SSE на Intel С++. VD>Значит должен понимать, что это уже не совсем С++. И что имея оптимизированную библиотеку примитивов и на Яве можно весьма шутсрый код писать.
Это уже и не ява будет
CC>>Сейчас правда основная занятость в другой отрасли. VD>Боюсь спросить в какой. Не ужели снова финансы?
Ага на C#
CC>>>>Ты писал на С++ с использованием современных (не микрософт) компиляторов? VD>>>Intel и GNU в их число входят? CC>>ICC == Intel C++ Compiler VD>Это я догадался. Я это к тому, что я ими пользовался. Правда SSE не использовал.
Ты — может и нет. А вот компилер — с удовольствием.
CC>>Не все алгоритмы возможны на видяхе. Баловался с CUDA — пока оно применимо в частных случаях. VD>Не все. Но по иронии судьбы те что доступны один фиг пишутся на С++ и их разработчики гордятся "высокой" производительностью. Хотя реально она просто никакая... в сравнении.
В смысле доступны? кому доступны. Переформулируй, т.к. не понятно про что ты.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Числодробилки (не видео, но графические данные в том числе) писал до недавнего времени. С использованием SSE на Intel С++. 