Родная стихия для С++

Неужели всё из коробки?

угу. Очень удобно.

А ссылку на туториал какой-нибудь можешь дать? Ну или на доку?

Спасибо, поизучаю на досуге.

Пока из лиспоподобного ковырял только scheme во время чтения sicp.

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

Гуй я бы вообще шарпу отдал. Но вот библиотеки лучше на плюсах.

Я тут глянул, вроде как конкуренси в clojure основана на йава тредах. Я могу ошибаться конечно, но если нет, я надеюсь ты знаешь о том, что jmv треды кушают карамельки по сравнению с эрланговскими процессами? Причём и т.з. затрат на содержание (512 байт в ерланге емним) и с т.з. скорости создания (тыц)

Ну это так, размышления. Просто если говорить ещё и scalability, то clojure как бы пролетает. Даже не смотря на то, что у неё там всё из коробки.

Что думаешь по этому поводу?

зачем замена кода на лету? Если очень хочется, то можно вcтроить в приложение какой-нибудь скриптовый модуль. Например, на lua или javascript.

помимо этого, зная про jvm-ный classloader, замена кода на лету тоже «выливается в копеечку» :(

В каких областях программирования С++ незаменим?

Нет таких.

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

Не стоит мне тут спорить. :(

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

Применять С++11C++14 можно везде.

Гуй я бы вообще шарпу отдал. Но вот библиотеки лучше на плюсах.

Гуй он тоже бывает разный. Если мы клепаем примитивные формочки с (условно) стандартными контролами, аля Delphi-style, да ещё и под винду, то шарп идеален, можно сказать, вне конкуренции. Если Гуй сложный, то тут все неоднозначно. Я как-то делал кастомные контролы на дотнете и пришел к выводу, что GDI+ в шарпе медленно работает. Хотя давно это было, может с тех пор все поменялось.

И даже на микроконтроллере многие хотят иметь язык поприличнее голимого Си.

Да - C99, от голимых плюсов нет никакого толка.

Я как-то делал кастомные контролы на дотнете и пришел к выводу, что GDI+ в шарпе медленно работает.

Сейчас GDI+ не нужен уже. Есть WPF, который умеет через GPU себя ускорять. И, если нужно что-то сильно кастомное с кучей рисования, есть XNA (который можно встраивать в WPFb который тоже GPU должен уметь).

WPF есть для тем. Или ты совсем кастомные виджеты делал? Типа с новыми функциями? Тут наверное большинство либ будет тормозить, что Qt, что виндовый MFC. Хотя наверное да, такой виджет лучше на плюсах писать. Все-равно быстрее.

WPF есть для тем. Или ты совсем кастомные виджеты делал? Типа с новыми функциями?

Именно кастомные, хотя если рассматривать Qt, то его QGraphicsView/QGraphicsScene подошли бы неплохо.

пришел к выводу, что GDI+ в шарпе медленно работает.

Очень спорный вывод, потому как я на свой практике убедился, что GDI+ очень быстр. По сути он является оберткой над GDI.

Тут то он копыта и откинет. Какой ты злобный буддист, однако.

Кложурка, кложурка, повернись к лесу передом, ко мне задом. Ой…

Гуй я бы вообще шарпу отдал
дотнет

При Саныче такого не было.

Всем по... ну ты понел.

Вы путаете кернелспейс и юзерспейс

зачем замена кода на лету?

Честно говоря странный вопрос от разработчика pcrf, который используется в уота. Допустим ты в своём pcrf нашёл баг, и тебе надо его исправить. Ты его нашёл, исправил и теперь надо бы сделать так, что бы твой pcrf незаметно обновился. Что будешь делать? У тебя это как-то раелизовано? Если что, я серьёзно спрашиваю. Интересно, как это сделать на спп.

XNA разве не deprecated?

Ты ведь не знаешь про erlang, да?

Нет конечно, я так вбросил.

З.Ы. А вообще - изучу на досуге.

Гуй я бы вообще шарпу отдал.

Следующий!

Но уж точно не питону. Фи!

В java тоже есть зеленые нитки.

XNA просто не нужен.

Из коробки?

Есть WPF, который умеет через GPU себя ускорять.

Который выглядит как жопа.

Есть несколько вариантов

• У нас встроен скриптовый движок на луа. Если ошибка в этом скрипте, то он просто заменяется на ходу. Из полезных фич, для нужд тестирования можно сделать так, что бы одновременно работали две версии скрипта: новая и старая. При этом новая версия будет использоваться для определенного процента пользователей. Если у них будет все ок, то новый начинает использовтаться для всех. Вообще эти скрипты пишет служба эксплуатации ан резработчики. Мы для этого предоставляем только интерфейс.
• Есть возможность просто переустановить нужный компонент. Т.е. заменить испольняемый файл и сделать ему рестарт. Это приведет к небольшой 2-5 секунд задережке в работе, которая будет практически незаметна так сообщения лежат в очереди. Для некоторых компонентов, которые основаны на nginx - можно сделать т.н. rolling restart.
• Если уж совсем жопа, то можно просто загасить этот узел кластера и переключить (точнее, она сама перключится) нагрузку на второй узел. После этого можно полностью переустановить узел.

Сразу, цифер нету, и я не шарю ни в Кложуре, ни в Эрланге, так что на правах кухонного кукарекания.

Думаю, тут речь о не совсем одинаковых вещах (способах использования), так что и сравнивать надо не напрямую.

Erlang масштабируется (т.е. можно и не масштабируемо, но зачем), но это масштабирование дает оверхед.

Кложура работает проще. В Clojure есть Software Transactional Memory (STM) — технология многопоточности, аналогичная транзакциям в БД. Альтернатива синхронизации на lock'ах. Асинхронная модель для STM - это actors. Они интегрированы с STM - сообщения внутри транзакции живут до коммита, и уничтожаются, если с транзакцией стало что-то недоброе. Соответственно, акторы работают быстро, нету никакого императивного цикла и блокирующего receive.

В деталях. Цимес в том, что actors — это мутабельные ссылки на немутабельные значения. Референс актора может начать ссылаться на новое немутабельное значение только с помощью посылки сообщения. Сообщения — это функции (и необязательные аргументы), которые применяются к значению актора, а их результат становится новым значением актора. Сообщения посылают возвращаемое значение мгновенно, а настоящая работа происходит асинхронно в тредпуле. Т.к. сообщения это функции, они могут быть мультиметодами, т.е. в принципе полиморфны. Т.к. множество функций открыто, множество сообщений тоже открыто, в отличие от циклов обработки паттерн-мачинга. Еще важная фича — значение актора обычно мгновенно доступно для чтения, без посылки сообщений, т.е. для этого не нужно делать какой-то специальной синхронизации.

В эрланге есть планировщик и легкие процессы, хавающие по 300 байт (или 512 как ты сказал?), это быстро и круто.

Зато в Clojure акторам не нужно какого-то выделенного стека, кучи, почтового ящика, ваще ничего, т.е. о них можно думать как о простых ссылках (4 байта на x86), так что акторов в одну ноду можно впихать еще больше, чем эрланговских легких процессов. Плюс вышеперечисленные фичи и специфичное использование в рамках готовой инфраструктуры/фреймворков (для кложуры и жвм есть фреймворки, да!).

Вывод: кложура вытянет на одной ноде еще больше эрланга, но зато это нельзя будет масштабировать.

А что жвм нестабильна, и всё написаное на жвм проклято, то эрланговская VM тоже умирает и ее приходится поднимать собакой, Валкин/lionet то ли в ЖЖ пейсал, то ли на конференции какой рассказывал.

основана на йава тредах

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

Для меня С/C++ незаменимы, потому что независимы. Шарп и джава зависят от любых капризов корпораций, будущее которых неизвестно. Да, там есть шикарные IDE, развернутые мануалы по новым версиям. Но нет. Все равно не доверяю. Непоняяятно (с)

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

Ок, спасибо. Было очень интересно почитать. Очевидно я ошибся, предполагая, что конкуренси clojure основано на йавовских потоках.

его должно вытеснить, да?

Да, там счётчик есть. Ну и на receive он тоже вытесняеться, если в мейлбоксе нет сообщений, которые можно матчить.

Очевидно я ошибся, предполагая, что конкуренси clojure основано на йавовских потоках.

да не, не ошибся) Нету нормальных потоков — свелосипедим навороченную memory model. Жавапроблемы)

основная проблема в том, что в результате всех этих читерских фич код на кложуре работает очень странно (плюс из-за скобочек нечитабелен as fuck), от чего мимо проходящие люди производят немеряное количество кирпичей и закрывают этот код как страшный сон, и продолжают велосипедить свои synchronized(this).

Я вот на сях в триста строк уложил то, что на перле можно однострочником сделать с парой КАВЫЧКА;КАВЫЧКА и ничо, работает перезагружалка модема когда провайдер зависает

anonymous (19.08.2013 10:45:15)> Debasher> PolarFox> buddhist> unfo> feofan> encyrtid>

Как борщок сегодня, не жидковат? Смотрите, как бы не остыл.

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

Т.е. там же, где ява.

В какой-то мере, только как-то так:
Java - где нужна коллективная разработка требовательного (но не очень) к производительности софта с промышленной скоростью.
С++ - где нужна коллективная разработка очень требовательного к производительности (сістемного) софта с околопромышленной скоростью.

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

Огласите список, open source.

GDI+ очень быстр. По сути он является оберткой над GDI

К сожалению, в рендеринге текста первый медленнее второго примерно в 9 раз (источник - http://blogs.msdn.com/b/cjacks/archive/2006/05/19/gdi-vs-gdi-text-rendering-p... да и сам столкнулся)

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

http://ru.wikibooks.org/wiki/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BD%D0%B0_Clojure

Тут согласен. Но эрлангу тут нет равных, насколько мне известно.

Только вот зачем? Много потоков это супер, но это для поделок. Для нормальных приложений надо использовать не много потоков, а мало :). Вместо потков делается стейтмашина. В результате преимущество эрланга оказывается невостребованным, либо востребованным среди ленивых, либо среди тех, что не знает о стейтмашине.

В результате что-то не видно на эраланге ни софтсвитчей популярных, ни вебсерверов уровня nginx.

Для нормальных приложений надо использовать не много потоков, а мало :)

Что для тебя нормальные приложения?

Остальное комментировать не буду ввиду недостаточности моей компетентности.

И, да, конечные автоматы удобны далеко не всегда.