Здравствуйте, AlexRK, Вы писали:
ARK>>>Ты уделяешь моему пукану подозрительно много внимания. НС>>Это ты с баттхертом сюда прибежал, не я. ARK>Не, всё было не так.
Все было именно так.
ARK> Ты сказал глупость
Обоснуй сперва.
ARK>, я указал тебе на это
Не, у тебя, судя по тону и количеству смайликов, мощно полыхнуло.
Здравствуйте, Ночной Смотрящий, Вы писали:
ARK>> Ты сказал глупость НС>Обоснуй сперва.
Ход обсуждения:
массовый ЯП должен быть понятен сходу таким как я или студентам первашам
Зачем?
проф. программисты изобретают более сложные ЯП, чтоб стать еще более проф-м программатором
Нет, чтобы решать все более сложные задачи все эффнктивнее
Много какие языки, в том числе C#, были изобретены вовсе не для того, чтобы решать все более сложные задачи.
ARK>>, я указал тебе на это НС>Не, у тебя, судя по тону и количеству смайликов, мощно полыхнуло.
Здравствуйте, Ночной Смотрящий, Вы писали:
ARK>>Много какие языки, в том числе C#, были изобретены вовсе не для того, чтобы решать все более сложные задачи.
НС>О как. А для чего?
Чтобы дать возможность решать некоторые (далеко не все) задачи программистам более низкой квалификации, чем потребной для того же Ц++. Повышение эффективности с точки зрения бизнеса. То же самое относится к Java/Swift/etc.
А если взять хаскель или идрис, то и они сделаны не для того, чтобы эффективно решать сложные задачи.
Единственный язык из недавних, что я могу вспомнить, который действительно позволяет делать более сложные вещи, чем это было до него (да и этот факт многими не признается) — это руст.
Здравствуйте, AlexRK, Вы писали:
НС>>О как. А для чего? ARK>Чтобы дать возможность решать некоторые (далеко не все) задачи программистам более низкой квалификации, чем потребной для того же Ц++.
Обосновать сможешь?
ARK> Повышение эффективности с точки зрения бизнеса.
О, значит таки повышение эффективность.
ARK>А если взять хаскель или идрис, то и они сделаны не для того, чтобы эффективно решать сложные задачи.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>О как. А для чего? ARK>>Чтобы дать возможность решать некоторые (далеко не все) задачи программистам более низкой квалификации, чем потребной для того же Ц++.
НС>Обосновать сможешь?
Мы решили создать упрощенную версию С++, чтобы повысить производительность труда разработчиков.
Разумеется, он не скажет — "я сделал C# для дураков".
Однако, более простая вещь является:
1) Более доступной, то есть более простой вещью может пользоваться большее число людей, и требования к интеллекту этих людей — ниже.
2) В общем случае — более ограниченной, то есть круг решаемых более простой вещью задач _обычно_ ниже, чем круг, решаемый более сложной вещью (если сложность инструмента не обусловлена неадекватной реализацией).
ARK>> Повышение эффективности с точки зрения бизнеса. НС>О, значит таки повышение эффективность.
Эффективность бизнеса, а не программиста. И не решение сложных задач, которые без С# эффективно не решить.
Не, если под "задачами" понимаются не задачи программирования, а задачи бизнеса, то всё, конечно, меняется.
ARK>>А если взять хаскель или идрис, то и они сделаны не для того, чтобы эффективно решать сложные задачи. НС>Нет, не для того. И?
Ну, собственно, твое заявление верно только для очень малого числа языков.
Мы решили создать упрощенную версию С++, чтобы повысить производительность труда разработчиков.
Т.е. ровно то, о чем написал и я. ЧТД.
ARK>Разумеется, он не скажет — "я сделал C# для дураков".
Зато тебе, я смотрю, очень хочется это сказать. Ну как же, ты ведь С++ освоил, правда?
ARK>Однако, более простая вещь является: ARK>1) Более доступной, то есть более простой вещью может пользоваться большее число людей, и требования к интеллекту этих людей — ниже.
Кривая логика. На машине проще попасть из пункта А в пункт Б на значительном удалении. Значит ли это, что машина более простая вещь, чем самокат, и ниже ли требования к интеллекту водителя, нежели к самокатонаезднику?
ARK>2) В общем случае — более ограниченной
Обоснуй.
ARK>, то есть круг решаемых более простой вещью задач _обычно_ ниже, чем круг, решаемый более сложной вещью (если сложность инструмента не обусловлена неадекватной реализацией).
А он ниже?
ARK>>> Повышение эффективности с точки зрения бизнеса. НС>>О, значит таки повышение эффективность. ARK>Эффективность бизнеса, а не программиста.
А это одно и тоже, когда мы о коммерческом программировании говорим.
ARK> И не решение сложных задач, которые без С# эффективно не решить.
Да нет, как раз таки решение. Ты в каком нибудь асинхронно-распределенном веб-ориентированном сервисе на С++ замучаешся пыль глотать, изобретая велосипеды.
ARK>Не, если под "задачами" понимаются не задачи программирования, а задачи бизнеса, то всё, конечно, меняется.
Прекрасная демонстрация, чо. Мне даже нечего добавить к картинке.
ARK>>>А если взять хаскель или идрис, то и они сделаны не для того, чтобы эффективно решать сложные задачи. НС>>Нет, не для того. И? ARK>Ну, собственно, твое заявление верно только для очень малого числа языков.
Мое заявление верно для мейнстрима. На иное я и не претендовал.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Зато тебе, я смотрю, очень хочется это сказать. Ну как же, ты ведь С++ освоил, правда?
Нет, ты хреновый телепат. И С++ я знаю довольно скверно. И моя персона вообще не имеет отношения к теме.
ARK>>Однако, более простая вещь является: ARK>>1) Более доступной, то есть более простой вещью может пользоваться большее число людей, и требования к интеллекту этих людей — ниже.
НС>Кривая логика. На машине проще попасть из пункта А в пункт Б на значительном удалении. Значит ли это, что машина более простая вещь, чем самокат, и ниже ли требования к интеллекту водителя, нежели к самокатонаезднику?
Это у тебя кривая логика. На машине НЕ проще доехать, на ней быстрее доехать, что совершенно не одно и то же. Ты подменил понятия.
ARK>>2) В общем случае — более ограниченной НС>Обоснуй.
По-моему, это очевидно. Более простая в использовании вещь в общем случае имеет меньшее число возможностей взаимодействия с ней (по определению простоты). Если сложная вещь спроектирована более-менее разумно, то большее число возможностей взаимодействия будет использовано для достижения бОльшего числа вариантов использования.
Конечно, можно сделать глупую сложную вещь, для которой все варианты входного взаимодействия будут приводить к одному выходу, но я не вижу смысла рассматривать такие бесполезные вещи. Точно так же можно сделать и глупую простую вещь.
ARK>>, то есть круг решаемых более простой вещью задач _обычно_ ниже, чем круг, решаемый более сложной вещью (если сложность инструмента не обусловлена неадекватной реализацией). НС>А он ниже?
У C# безусловно ниже, чем у С++. У сишарпа он, собственно, вообще весьма узкий. Если, конечно, рассматривать разные классы задач. В абсолютных величинах даже одна задача "быдлокодить внутренние системы предприятий" будет довольно большой по размеру.
ARK>>Эффективность бизнеса, а не программиста. НС>А это одно и тоже, когда мы о коммерческом программировании говорим.
С точки зрения владельца бизнеса — одно и то же. С точки зрения программиста — это не очевидно.
ARK>> И не решение сложных задач, которые без С# эффективно не решить. НС>Да нет, как раз таки решение. Ты в каком нибудь асинхронно-распределенном веб-ориентированном сервисе на С++ замучаешся пыль глотать, изобретая велосипеды.
eao197 с тобой не согласится.
ARK>>Ну, собственно, твое заявление верно только для очень малого числа языков. НС>Мое заявление верно для мейнстрима. На иное я и не претендовал.
Твое заявление для мейнстрима верно только в той части, где говорится про эффективность, при условии дополнительного ограничения, что под словом "эффективность" понимается эффективность с точки зрения бизнеса.
Здравствуйте, AlexRK, Вы писали:
НС>>Кривая логика. На машине проще попасть из пункта А в пункт Б на значительном удалении. Значит ли это, что машина более простая вещь, чем самокат, и ниже ли требования к интеллекту водителя, нежели к самокатонаезднику? ARK>Это у тебя кривая логика. На машине НЕ проще доехать, на ней быстрее доехать, что совершенно не одно и то же. Ты подменил понятия.
Это ты подменил. В русском языке можно сказать вместо быстрее — проще. То же самое и в случае шарпа.
ARK>>>2) В общем случае — более ограниченной НС>>Обоснуй. ARK>По-моему, это очевидно.
Нет.
ARK> Более простая в использовании вещь в общем случае имеет меньшее число возможностей взаимодействия с ней
Нет. Тем более что речь не об общем, а о конкретном, и твои высосанные из пальца сомнительные обобщения доказательной силы не имеют.
ARK> (по определению простоты).
Определение в студию. Полное.
ARK> Если сложная вещь спроектирована более-менее разумно
А если нет?
ARK>>>, то есть круг решаемых более простой вещью задач _обычно_ ниже, чем круг, решаемый более сложной вещью (если сложность инструмента не обусловлена неадекватной реализацией). НС>>А он ниже? ARK>У C# безусловно ниже, чем у С++
Нет.
ARK>. У сишарпа он, собственно, вообще весьма узкий. Если, конечно, рассматривать разные классы задач. В абсолютных величинах даже одна задача "быдлокодить внутренние системы предприятий" будет довольно большой по размеру.
Опять слышу я баттхерт. Быдлокодить... Быдлокодить это как раз писать какой нибудь лапшекод для очередной кривой железки на С++, ибо код сам по себе примитивен и мелок, и многое прощает.
ARK>>>Эффективность бизнеса, а не программиста. НС>>А это одно и тоже, когда мы о коммерческом программировании говорим. ARK>С точки зрения владельца бизнеса — одно и то же. С точки зрения программиста — это не очевидно.
Кого волнует мнение программиста, интересы которого противоречат бизнесу? Что за бред?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Кривая логика. На машине проще попасть из пункта А в пункт Б на значительном удалении. Значит ли это, что машина более простая вещь, чем самокат, и ниже ли требования к интеллекту водителя, нежели к самокатонаезднику? ARK>>Это у тебя кривая логика. На машине НЕ проще доехать, на ней быстрее доехать, что совершенно не одно и то же. Ты подменил понятия.
НС>Это ты подменил. В русском языке можно сказать вместо быстрее — проще. То же самое и в случае шарпа.
Нет, нельзя. Быстрее — не проще, а проще — не быстрее.
НС>Тем более что речь не об общем, а о конкретном, и твои высосанные из пальца сомнительные обобщения доказательной силы не имеют.
Точно так же твои высосанные из пальца рассуждения о новых языках для решения сложных задач доказательной силы не имеют.
ARK>> Если сложная вещь спроектирована более-менее разумно НС>А если нет?
Ксли нет, то такие вещи я не рассматриваю.
ARK>>>>, то есть круг решаемых более простой вещью задач _обычно_ ниже, чем круг, решаемый более сложной вещью (если сложность инструмента не обусловлена неадекватной реализацией). НС>>>А он ниже? ARK>>У C# безусловно ниже, чем у С++ НС>Нет.
Да. Один сборщик мусора сразу вычеркивает кучу применений. Операционные системы, коробочный софт, игры, софт для самолетов-машин-марсоходов-роботов, ядра высокопроизводительных серверных систем (трейдинговых, поисковых и т.д.) — нигде здесь C# нет и никогда не будет.
ARK>>. У сишарпа он, собственно, вообще весьма узкий. Если, конечно, рассматривать разные классы задач. В абсолютных величинах даже одна задача "быдлокодить внутренние системы предприятий" будет довольно большой по размеру. НС>Опять слышу я баттхерт. Быдлокодить... Быдлокодить это как раз писать какой нибудь лапшекод для очередной кривой железки на С++, ибо код сам по себе примитивен и мелок, и многое прощает.
Здравствуйте, AlexRK, Вы писали:
ARK>>> Если сложная вещь спроектирована более-менее разумно НС>>А если нет? ARK>Ксли нет, то такие вещи я не рассматриваю.
Рассматриваешь. Ты ж ведь про С++ тут вещаешь, верно?
ARK>Да. Один сборщик мусора сразу вычеркивает кучу применений. Операционные системы, коробочный софт, игры, софт для самолетов-машин-марсоходов-роботов, ядра высокопроизводительных серверных систем (трейдинговых, поисковых и т.д.) — нигде здесь C# нет и никогда не будет.
Ровно как практически нет С++ в вебе, кроме небольшого количества узкоспециализированных сервисов. Да и с поиском у тебя смешно получилось. В сегменте локальных поисковых сервисов однозначный лидер — Эластик. Ну и ELK на его основе для логов. А он, о ужас, на джаве писан, а вовсе не на С++.
Здравствуйте, AlexRK, Вы писали:
НС>>Да нет, как раз таки решение. Ты в каком нибудь асинхронно-распределенном веб-ориентированном сервисе на С++ замучаешся пыль глотать, изобретая велосипеды.
ARK>eao197 с тобой не согласится.
eao197 сказал, что по поводу асинхронного и веб-ориентированного более релевантна вот эта ссылка.
Здравствуйте, so5team, Вы писали:
НС>>>Да нет, как раз таки решение. Ты в каком нибудь асинхронно-распределенном веб-ориентированном сервисе на С++ замучаешся пыль глотать, изобретая велосипеды. ARK>>eao197 с тобой не согласится.
от 2M msg/sec при обмене сообщениями между разными нитями
Что так медленно-то? На блокировках поди всё? Это смотрели? На java выдаёт 20M msg/sec — на порядок быстрее! И это данные семилетней давности...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
EP>Со stackless сопроцедурами будет сохранён только один фрейм (не суть каким образом), поэтому и нельзя прозрачно yield'ануть из нижележащих фреймов (они-то не сохраняются автоматом).
Наверное надо так: прозрачно yield'ануть в нижележащие фреймы . Не сохраняются же нижележацие фреймы.
от 2M msg/sec при обмене сообщениями между разными нитями
·>Что так медленно-то? На блокировках поди всё?
Конечно. Да еще и в режиме пинг-понга одиночными сообщениями.
·>Это смотрели? На java выдаёт 20M msg/sec — на порядок быстрее! И это данные семилетней давности...
от 2M msg/sec при обмене сообщениями между разными нитями
S>·>Что так медленно-то? На блокировках поди всё? S>Конечно. Не надо использовать блокировки в высокопроизводительных системах.
S>Да еще и в режиме пинг-понга одиночными сообщениями.
Если батчами, то там ещё быстрее.
Disruptor has an explicit batching API on the publisher side that can give over 100 million messages per second.
S>·>Это смотрели? На java выдаёт 20M msg/sec — на порядок быстрее! И это данные семилетней давности... S>Если бы там был еще обмен сообщениями...
Так это оно и есть:
A simple ping-pong algorithm will be used to signal from one to the other and back again
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·> Не надо использовать блокировки в высокопроизводительных системах.
Если производительность вашей системы упирается в систему передачи сообщений между рабочими потоками, значит вы что-то делаете сильно не так.
S>>Да еще и в режиме пинг-понга одиночными сообщениями. ·>Если батчами, то там ещё быстрее. ·>
Disruptor has an explicit batching API on the publisher side that can give over 100 million messages per second.
Если передавать bulk-сообщения, в которых будет 100 мелких прикладных сообщений, то вы получите 200M сообщений в секунду. В чем проблема?
S>>·>Это смотрели? На java выдаёт 20M msg/sec — на порядок быстрее! И это данные семилетней давности... S>>Если бы там был еще обмен сообщениями... ·>Так это оно и есть: ·>
A simple ping-pong algorithm will be used to signal from one to the other and back again
Там нет обмена сообщениями, там идет взаимный инкремент атомарных переменных двумя конкурирующими потоками на busy wait-инге. К доставке и обработке произвольных сообщений это имеет крайне отдаленное отношение.
Не надо использовать блокировки в высокопроизводительных системах.