Rust vs C++

Кто-то писал на Rust? Стоит ли начинать учить? Насколько Rust хуже/лучше С++?

0

Сообщение от Fulcrum_013 Поэтому все то что вы написали называется ломать глобальную оптимизацию

Понятно. Вы утверждаете что ассемблерные вставки не нужны.
Вести разумную дискуссию (включая чтение аргументов) вы также не способны.

Сообщение от Fulcrum_013 В реальности это во первых полный бред.

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

Сообщение от Fulcrum_013 Вообщето высокоуровневость языка - это наличие инструментов позволяющих создавать высокоуровневые абстракции.

Это чушь.
Высокоуровневые абстракции можно писать на любом языке, хоть на ассемблере.
На самом же деле высокоуровневость языка определяется тем, оперирует ли язык терминами процессора или абстрактными понятиями. Очевидно, самым низкоуровневым языком является Ассемблер (он оперирует терминами процессора напрямую), чуть выше Си,С++, Паскаль и т.п.: они тоже оперируют машинными данными, прикрытыми тонкой оберткой абстракции. А вот скриптовые языки уже знать не знают про процессор. Для того же Баша существуют только строки и утилиты.

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

Про "засовывание абстракций на самый низ" вообще не понял что вы хотели сказать. Попробуйте переформулировать по-человечески.
Про эффективность высокоуровневых языков - она обязательно будет ниже, чем у низкоуровневых, по определению. Это плата за слои абстракции и простоту разработки.

Сообщение от Fulcrum_013 [про операции ввода-вывода в bash] Как это нет? Куда делись? Да вот взяла и делась.

Не уходите от ответа. В bash с момента создания были операции ввода-вывода. То, что вы ими не умеете пользоваться или просто о них не знаете говорит исключительно о ваших знаниях.

Сообщение от IamLost Rust пока лучшая попытка решить проблему бесполезности С++ в настоящем и будущем

А можете вкратце перечислить какие именно проблемы плюсов он решает?

Сообщение от IamLost Будущее за интерпретируемыми языками, а не древним мусором, созданном 40 лет назад.

Разве Rust не компилируемый?

Сообщение от Fulcrum_013 В чем таком интерпретация превосходит нэтив, окромя того что уступает абсолютно во всем от 3-х порядков?

В основном в переносимости. И эту задачу решить на С++ невозможно по определению.

Сообщение от IamLost И да, за интерпретацией будущее, кто бы что не говорил. В мире будущего никаких С++ и других архаичных технологий, собранных по принципу "компота" не будет.

Увы, обратная совместимость - страшная штука, ее так просто не преодолеть.
Это не отменяет необходимость компилируемых языков. Как минимум, кроме них писать интерпретаторы/JIT-компиляторы не на чем.
Хотя печальная тенденция писать все подряд на не-компилируемых языках явно прослеживается, с этим не поспоришь.

Сообщение от Fulcrum_013 Реально похоронить плюсы сможет только такой же кардинальный ап плюсов которым, насколько кардинальным апом си были плюсы.

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

Сообщение от Fulcrum_013 А плюсы собирались по принципу выбрасывания всего лишнего. Например сразу же выбросили анахронизм под названием GC.

Наркоман? Плюсы как раз строились по принципу натягиивания всего лишнего в обычный Си. Именно этим они мне не нравятся - уж больно много и бессистемно напихано. Сам Си намного проще.

1

Сообщение от COKPOWEHEU Понятно. Вы утверждаете что ассемблерные вставки не нужны. Вести разумную дискуссию (включая чтение аргументов) вы также не способны.

У вас нет вообще никаких аргументов в том то и дело. Максимум - выдержки из бульварного чтива мифов 50-летней давности.

Добавлено через 42 секунды

Сообщение от COKPOWEHEU Плюсы как раз строились по принципу натягиивания всего лишнего в обычный Си.

Ошибаетесь. Таки путем замены в Симуле всего устаревшего на более прогрессивное. В том числе синтаксиса.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU В основном в переносимости. И эту задачу решить на С++ невозможно по определению.

Только вот переносимость скриптов по определению не может превзойти переносимость универсальных языков. Потому что для того чтобы куда то перенести скрипт сначала нужно перенести на эту платформу интерпретатор.
При этом увы и ах но переносимость между осями абсолютной не будет в принципе - есть разница между АПИ и всегда нужны будут адаптеры для ее сокрытия.

Добавлено через 2 минуты

Сообщение от COKPOWEHEU Высокоуровневые абстракции можно писать на любом языке, хоть на ассемблере.

Аналог в студию на ассемблере плиз.

Добавлено через 4 минуты

Сообщение от COKPOWEHEU Плюсам уже сейчас мешает совместимость с Си,

Это в первую очередь совместимость с апи оси и либами на других языках - т.е. с форматом импорта/экспорта функций. Универсального формата импорта/экспорта классов пока что не существует, и врядли появится - тогда процедурные и функциональные языки потеряют возможность юзать апи оси.
Мало того что вы подразумеваете под типа старыми делами из С? Сырые указатели или что еще?
Без них все равно обойтись не удастся - это как минимум то из чего собираются умные указатели. А заносить это "под капот" категорически нельзя - потеряется кастомизируемость автоматики. То что это в расте куда то упрятали моментом отбросило его в развитии на уровень 60-х.

Добавлено через 12 минут

Сообщение от COKPOWEHEU е уходите от ответа. В bash с момента создания были операции ввода-вывода. То, что вы ими не умеете пользоваться или просто о них не знаете говорит исключительно о ваших знаниях.

Операции ввода вывода есть. Только когда вы говорите о использовании баша речь идет исключительно о хардкодинге списков файлов. И не удивительно - как только начнете юзать ввод-вывод для этих дел это сразу станет абсолютно неюзабельным по сравнению с десктопом. Вот именно потому что данные заносятся путем хардкодинга, и больше ни для чего все эти баши не юзаются, это и не разу не разработка софта а просто подготовка данных.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Поэтому единственный шанс вытеснить С/С++ из их ниши - отбросить совместимость.

Это по определению лишить себя как совместимостью с апи оси так и возможностей кастомизации автоматики.

Добавлено через 24 минуты

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

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

Сообщение от COKPOWEHEU Поэтому единственный шанс вытеснить С/С++ из их ниши - отбросить совместимость.

Это не обязательно. Можно просто реализовать ее по другому. К примеру при помощи возможности включения в код фрагментов на плюсах.

Сообщение от COKPOWEHEU Плюсам уже сейчас мешает совместимость с Си, да и со своим старым кодом.

Вы сейчас имеете в виду что что то мешает в ядре языка, или в стандартной библиотеке?

Добавлено через 32 минуты

Сообщение от COKPOWEHEU Просто потому что достаточно оглянуться вокруг чтобы увидеть опровержения.

Опровержения чему? Тому что скрипты резко уступают плюсам абсолютно во всем, так же как и манаджед, а другие нативные языки в средствах автоматики и создания абстракций? Его нет в принципе.

Добавлено через 7 минут
Привести пример где что то превосходило бы плюсы в разработке софта вы так и не осилили.

0

Сообщение от Fulcrum_013 У вас нет вообще никаких аргументов в том то и дело. Максимум - выдержки из бульварного чтива мифов 50-летней давности.

От того что вы эту чушь в 100500-й раз повторите, истиной она не станет.

Сообщение от Fulcrum_013 Только вот переносимость скриптов по определению не может превзойти переносимость универсальных языков. Потому что для того чтобы куда то перенести скрипт сначала нужно перенести на эту платформу интерпретатор.

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

Сообщение от Fulcrum_013 Аналог в студию на ассемблере плиз.

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

Сообщение от Fulcrum_013 Это в первую очередь совместимость с апи оси и либами на других языках - т.е. с форматом импорта/экспорта функций.

Еще раз: для этого не нужна совместимость на уровне исходного кода. Дергать Си-шные библиотеки можно и из Ассемблера, и из Паскаля, и даже из Labview.
С++ взлетел именно за счет совместимости на уровне исходного кода, а вовсе не за счет какой-то мифической архитектуры, которую вы тут выдумываете. Просто на момент появления языка уже были люди, способные на нем писать и воспринимать новые фишки. А это огромное преимущество для любого нового языка.

Сообщение от Fulcrum_013 Универсального формата импорта/экспорта классов пока что не существует, и врядли появится - тогда процедурные и функциональные языки потеряют возможность юзать апи оси

Вы так говорите будто такая задача принципиально неразрешима. На самом деле единственное что мешает импортировать/экспортировать классы - отсутствие соглашений. Особенно учитывая что на языках высокого уровня эта задача успешно решена. И доступность из Си почему-то не теряется.

Сообщение от Fulcrum_013 Операции ввода вывода есть. Только когда вы говорите о использовании баша речь идет исключительно о хардкодинге списков файлов. И не удивительно - как только начнете юзать ввод-вывод для этих дел это сразу станет абсолютно неюзабельным по сравнению с десктопом. Вот именно потому что данные заносятся путем хардкодинга, и больше ни для чего все эти баши не юзаются, это и не разу не разработка софта а просто подготовка данных.

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

Сообщение от Fulcrum_013 Это по определению лишить себя как совместимостью с апи оси так и возможностей кастомизации автоматики.

Еще раз: ваши "определения" никуда не годятся.
Совместимость на уровне исходного кода никак не связана с соглашением о вызовах.

Сообщение от Fulcrum_013 Это вопросы реализации оптимизатора а не дизайна самого языка.

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

Сообщение от Fulcrum_013 Можно просто реализовать ее по другому. К примеру при помощи возможности включения в код фрагментов на плюсах.

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

Сообщение от Fulcrum_013 Вы сейчас имеете в виду что что то мешает в ядре языка, или в стандартной библиотеке?

Я имею в виду в первую очередь используемую терминологию, сам язык. Скажем, ничего не мешало реализовать полноценную объектную модель, завернуть базовые типы в объекты - но ради совместимости этого делать не стали. Могли отказаться от ужасного препроцессора, от массивов, строк. Да много в Си не слишком удачных решений.

Сообщение от Fulcrum_013 Привести пример где что то превосходило бы плюсы в разработке софта вы так и не осилили.

Если вы надеетесь, что мне надоест тыкать вас носом в конкретные примеры - напрасно.
Bash и другие шеллы для автоматизации системных утилит.
Python, Lua, ... для встраивания в другие программы
Fortran, Python для научных расчетов
Java, C#, скриптовые ... для кроссплатформенной разработки без необходимости перекомпиляции
Специализированные веб-языки
Си, Ассемблер для низкого уровня
Ничего из этого вы так и не опровергли - только игнорировать пытаетесь.

Добавлено через 7 минут
Ах да, главный вопрос: если, как вы говорите, существует идеальный язык, С++, то почему им не пользуются все? Потому что они глупее Fulcrum_013'а? Допустим. Но в отличие от вас, они пишут реальный код, решают реальные задачи - так может лучше послушать их.

0

COKPOWEHEU, тут одно из двух: или он тролль или он думает, что потоки его бреда имеют смысл.. В обоих случаях лучше оставить его в покое, так как он на этих 11 страницах уже выписал весь бред, который он писал в других темах, и начал повторятся. Дальше всё пойдёт по кругу.

0

Сообщение от COKPOWEHEU Fortran, Python для научных расчетов

Пруф в студию.

Сообщение от COKPOWEHEU Специализированные веб-языки

Пруф в студию.

Сообщение от COKPOWEHEU Си, Ассемблер для низкого уровня

Пруф в студию.
Приведите конкретные примеры.
Так понимаю с ними точно так же как с примером высокоуровневой абстракции на асме?

Добавлено через 1 минуту

Сообщение от COKPOWEHEU От того что вы эту чушь в 100500-й раз повторите, истиной она не станет.

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

Добавлено через 7 минут

Сообщение от COKPOWEHEU Могли отказаться от ужасного препроцессора

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

Сообщение от COKPOWEHEU от массивов, строк. Да много в Си не слишком удачных решений.

Вариантов их реализации - вагон и маленькая тележка. Кому какой надо разрабам языка опять же известно быть не может. А по сему жить это должно в библиотечных средствах что позволяет их как легко заменить, так и использовать несколько вариантов их реализации в одном проекте. Отказ от такого подхода - откат назад на уровень 60-х годов прошлого века и урезание универсальности по самые не могу.

Добавлено через 2 минуты

Сообщение от COKPOWEHEU Совместимость на уровне исходного кода никак не связана с соглашением о вызовах.

Что конкретно вас не устраивает и чем конкретно оно мешает? И что вы хотите добавить определитесь для начала.

Добавлено через 2 минуты

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

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

Добавлено через 4 минуты

Сообщение от COKPOWEHEU Мы ведь говорим о низкоуровневых языках, пригодных для написания ядер и драйверов.

Ну дак конкретно определитесь что вам так мешает то.

Добавлено через 58 секунд

Сообщение от COKPOWEHEU а логика ограничена терминологией языка

Логика в тюринг полных языках ограничена исключительно тем набором который можно вычислить на машине тюринга. ТАк что не бредьте.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU Если вы не способны использовать язык иначе, чем с хардкодом всего подряд, это говорит исключительно о ваших способностях. У нормальных программистов такой проблемы не возникает.

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

Добавлено через 2 минуты

Сообщение от COKPOWEHEU Специализированные веб-языки

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

Добавлено через 2 минуты

Сообщение от COKPOWEHEU На самом деле единственное что мешает импортировать/экспортировать классы - отсутствие соглашений.

Как это соглашение согласить для процедурных языков? А для функциональных? Ну для тех в которых понятие класс не существует.

Добавлено через 4 минуты

Сообщение от COKPOWEHEU завернуть базовые типы в объекты - но ради совместимости этого делать не стали

А завернуть их самомтоятельно (менее 100 строк кода) религия запрещает? А теперь рассмотрим такой вопрос - а как именно завернуть? Разрабам языка этого известно быть не может. Одним нужно по одному другим опять же по другому.
Т.е. все в языке сделано в первую очередь для универсального применения - т.е. возможности быстрой и простой подстройки всего и вся к конкретной задаче. И ничего удобнее чем полноценный механизм шаблонов + сишные примитивные типы для такой подстройки быть не может.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU то почему им не пользуются все

А все это кто? 90% индустрии - неквалифицированные, и решают в скопе 1% задач. Остальные пользуют в основном С++.
Подавляющее большинство софта вокруг выполняющие 99+% обработки информации написаны таки на плюсах.

Добавлено через 7 минут

Сообщение от COKPOWEHEU Аналоги пишутся для задачи, а не для конкретного решения. Если хотите увидеть как ваш код будет выглядеть на ассемблере - дизассемблируйте да и все.

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

Добавлено через 12 минут

Сообщение от COKPOWEHEU Нет, для объединения нескольких исходных кодов в одном проекте надо использовать только раздельную компиляцию.

Раздельная компиляция исключает инлайнинг и глобальную оптимизацию. А это ужасный удар по производительности. К примеру для плюсов отключение инлайинга может давать падение производительности до 400 раз, в среднем раз в 40 - это плата за тотальную декомпозицию, сокращающую код и увеличивающую скорость разработки на порядки.
При этом возможность инстанциирования плюсовых шаблонов в новом языке так же как и шаблонов новога языка в плюсовом коде потребует наличие кода шаблонов.
Раздельная компиляция в данном вопросе не применима от слова совсем, во всяком случае в современном ее виде.
Тут поможет разве что полный переход к линктайм кодогенерации.

Добавлено через 13 минут

Сообщение от COKPOWEHEU Fortran

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

Добавлено через 7 минут

Сообщение от COKPOWEHEU Так программы на Питоне или Джаве запускаются на разных ОС вообще без каких-либо усилий, просто потому что интерпретаторы уже написаны.

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

0

Сообщение от Fulcrum_013 Пруф в студию. Пруф в студию. Пруф в студию.

Ну конечно, ведь что-то доказывать должны все кроме вас.

Сообщение от Fulcrum_013 Единственное что вы делаете - это повторяете вопли безмозглых евангелистов

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

Сообщение от Fulcrum_013 Не могли.

Конечно, не могли! Иначе потерялась бы совместимость с Си.
Те языки, которые этим не связаны, препроцессор не используют и ничуть от этого не страдают.

Сообщение от Fulcrum_013 Макросы препроцессора единственное решение

В некоторых случаях возможно. Но даже для модификации исходного кода существуют генераторы и получше чем Си-шный препроцессор. Да в нем даже циклов и нормальных условий нет!

Сообщение от Fulcrum_013 Вариантов их реализации - вагон и маленькая тележка. Кому какой надо разрабам языка опять же известно быть не может. А по сему жить это должно в библиотечных средствах что позволяет их как легко заменить, так и использовать несколько вариантов их реализации в одном проекте.

Угу. Именно поэтому они выбрали ДВА стандарта - ASCIIZ и std::string. Причем первый - как раз наследие Си, которое в С++ не вписывается.

Сообщение от Fulcrum_013 Что конкретно вас не устраивает и чем конкретно оно мешает? И что вы хотите добавить определитесь для начала.

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

Сообщение от Fulcrum_013 Логика в тюринг полных языках ограничена исключительно тем набором который можно вычислить на машине тюринга. ТАк что не бредьте.

Хорошо, покажите как на С++ обратиться к биту переноса. Язык такими терминами не оперирует.

Сообщение от Fulcrum_013 Нормальные программисты баш для разработки софта не используют. Для этого есть на порядок более продвинутые средства.

Конечно. Обычно на bash пишут админы. Правда, на суть высказывания это никак не влияет - разработка средств решения задач пользователя остается программированием. Ну да, для "склеивания" готовых утилит можно много чего использовать, но лучше шеллов с этим мало кто справляется.

Сообщение от Fulcrum_013 Они не разу не специализированны, мало того при переходе веба на современные технологии становятся непригодными от слова совсем. При этом всю непосредственную работу выполняют библиотеки на С/С++ - т.е. эта скриптопрокладка нужна как корове седло.

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

Сообщение от Fulcrum_013 Как это соглашение согласить для процедурных языков? А для функциональных? Ну для тех в которых понятие класс не существует.

Для начала посмотреть как это уже сделали умные дяди. Подсказываю: общего стандарта в данный момент нет, так что реализаций несколько.

Сообщение от Fulcrum_013 А завернуть их самомтоятельно (менее 100 строк кода) религия запрещает? А теперь рассмотрим такой вопрос - а как именно завернуть? Разрабам языка этого известно быть не может. Одним нужно по одному другим опять же по другому.

Ну конечно. Строки они завернули, тут всем сразу ясно как это сделать и какой функционал понадобится, а целочисленные переменные - тут же ступор.
Заворачивать самому, естественно, не вариант - это не будет работать со сторонними библиотеками. А вот разработчики стандарта это сделать (и навязать остальным!) это уже вполне по силам.

Сообщение от Fulcrum_013 А все это кто? 90% индустрии - неквалифицированные, и решают в скопе 1% задач. Остальные пользуют в основном С++.

Как там ваш палец, вкусный? Или вы из него не только бредовые "определения", "статистики" и тому подобное высасываете?
Но даже если закрыть глаза и поверить вашей "статистике", ничего не изменится. Тем самым 90% (а чего не 99% или не 999%?) тоже нужен инструмент для разработки. Или вы теперь будете утверждать что программированием должны заниматься только адские хакеры? Так все равно ваша теория ломается - даже адские хакеры используют и Си, и функциональщину.

Сообщение от Fulcrum_013 В том то и суть что он будет выглядеть по разному в зависимости от конкретизации абстракции.

Вот беда, запретили драйвера на ассемблере писать, они ж будут "по разному" выглядеть. Правда, соглашения о доступе останутся прежними, но кого это волнует, ведь Fulcrum_013 сказал!

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

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

1

Сообщение от COKPOWEHEU Еще раз: для этого не нужна совместимость на уровне исходного кода.

Для этого нужны как минимум сырые указатели. И что вы подразумеваете под отказом от совместимости с сишным кодом? Нативный язык с сишным синтаксисом и семантикой будет хотя бы частично совместим с сишным кодом по определению. А полной совместимости дано нет.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU Ну конечно, ведь что-то доказывать должны все кроме вас.

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

Добавлено через 46 секунд

Сообщение от COKPOWEHEU Вы меня по себе не судите.

Именно по вашим высказыаниям.

0

Сообщение от Fulcrum_013 Бред. Потому что интерпретатор не способен скрыть различие между АПИ оси.

То есть вы утверждаете что никогда не слышали о программах на тех же Питоне, Джаве, Шарпе, которые вполне успешно запускаются на разных ОС без перекомпиляции?

Сообщение от Fulcrum_013 про плюсы в браузере слышали?

Не слышал и не верю в такое. В основном потому что смысла нет: либо выдавать код сразу в высокоуровневом языке чтобы его исполнял клиент, либо использовать промежуточное представление по типу LLVM - тогда в качестве исходного кода можно даже С++ или Бейсик использовать, если время потратить некуда.

0

Сообщение от COKPOWEHEU орошо, покажите как на С++ обратиться к биту переноса. Язык такими терминами не оперирует.

на x64
это платформозависимая операция. На других платформах примерно так же.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Не слышал и не верю в такое

А зря. https://ru.wikipedia.org/wiki/WebAssembly Запад на это уже во всю переходит в вопросах касющихся веб-гуя.

Добавлено через 4 минуты

Сообщение от COKPOWEHEU либо использовать промежуточное представление по типу LLVM

LLVM и используется. И это работает на порядки быстрее JS и весит на порядки меньше. А самое главное имеет пригодную для ООП автоматику в отличии от JS.

0

Сообщение от Fulcrum_013 Для этого нужны как минимум сырые указатели.

И что? В любом низкоуровневом языке есть сырые указатели - и в Ассемблере, и в Паскале, и в Бейсике. Никто из них с Си не совместим на уровне исходного кода.

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

А кто вам сказал что новый язык должен обладать Си-шным синтаксисом? Опять ваши изпальцевые "определения"?

Сообщение от Fulcrum_013 Ну вы же утверждаете что питон типа лучше плюсов для научного счету.

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

Сообщение от Fulcrum_013 Так приведите хоть один пример где питон хотя бы удобнее. Таких примеров за десятилетия существования питона не появилось ни одного.

Тогда почему он еще жив? Более того, тогда почему он гораздо популярнее тех же плюсов?
Как бы вы ни изворачивались, как бы ни подгоняли статистику, мы видим разнообразие языков. Если бы какой-то из них во всем превосходил другие, он бы его просто вытеснил. Впрочем, элементарная логика вам недоступна, это вы уже продемонстрировали.

0

Сообщение от COKPOWEHEU А кто вам сказал что новый язык должен обладать Си-шным синтаксисом?

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

Добавлено через 7 минут

Сообщение от COKPOWEHEU Тогда почему он еще жив? Более того, тогда почему он гораздо популярнее тех же плюсов?

90% разрабов неквалифиицированные. Т.е. вот вы к примеру даже суть понятия абстракция понять не можете. Куда там до их использования а тем более выделения и реализации?
Но и решают эти разрабы скопом 1% задач - продуктивность при таком подходе будет никакой от слова совсем.

Сообщение от COKPOWEHEU Как бы вы ни изворачивались, как бы ни подгоняли статистику, мы видим разнообразие языков. Если бы какой-то из них во всем превосходил другие, он бы его просто вытеснил.

А он их давно вытеснил из среды профессиональной разработки, еще в 90-х а то и ранее. Остальные профессиональные языки держатся на плаву исключительно за счет огромного количества кодовой базы. Причем сверсник плюсов Ада вообще какую то нишу смогла получить только за счет того что разрабатывалась по заказу пентагона, и какими бы горами легаси не облажилась но плюсы ее по тихоньку оттуда выжимают. Единственное место где она еще используется в новых разработках - европейская космическая программа.
А все что создано позже плюсов/ады - это языки для привлечения неквалифицированных раззработчиков к примитивным задачам, на которых профессионалов не хватает. Они по определению уступают профессиональным языкам во всем.

0

Сообщение от Fulcrum_013 if (_readeflags() & CFMask)

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

Сообщение от Fulcrum_013 А зря. https://ru.wikipedia.org/wiki/WebAssembly Запад на это уже во всю переходит в вопросах касющихся веб-гуя.

Это-то известная технология. Но вы говорили про встраивание в веб именно С++, а не байт-кода.

Добавлено через 6 минут

Сообщение от Fulcrum_013 НУ как видим сишный синтаксис таки гораздо удобнее чем алголовский или фортрановский.

А видим мы это потому что Си победил по совокупности факторов. Вот все и стали заимствовать элементы синтаксиса. Особенно в этом преуспел С++.
Объективно же это - вопрос привычки.

Сообщение от Fulcrum_013 90% разрабов неквалифиицированные.

На этот бред я уже ответил, будьте внимательнее.

Сообщение от Fulcrum_013 Т.е. вот вы к примеру даже суть понятия абстракция понять не можете.

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

Сообщение от Fulcrum_013 А все что создано позже плюсов/ады - это языки для привлечения неквалифицированных раззработчиков к примитивным задачам, на которых профессионалов не хватает. Они по определению уступают профессиональным языкам во всем.

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

0

Сообщение от COKPOWEHEU Но вы говорили про встраивание в веб именно С++, а не байт-кода

А во что компилится язык - в какую конкретно систему команд от языка не зависит. Это и называется высокоуровневый.

Добавлено через 4 минуты

Сообщение от COKPOWEHEU Вот вы опять себе противоречите. Сами описали какую-то нишу, где С++ неэффективен и тут же утверждаете что С++ идеален.

Еще раз - неумение использовать фичи языка - это не непригодность языка к задачам. Это непригодность к этим задачам горе-разрабов.
Т.е. они вынуждены использовать менее приспособленные языки в следствие своей абсолютной безграмотности в специальности. Плюсы им не помощник в вопросе повышения продуктивности. Т.е. еще раз - квалификауия это по большому счету способность создавать постановку задачи - т.е. выделять высокоуровневые абстракции. Язык - это всего лишь ручка которой записываются абстракции. Но зачем ручка тому кто не понимает как ей можно писать? Так и шкрябают стилусом по глиняной табличке. Дай им ручку будт шкоябать по глиняной табличке точно так же, еще и руки чернилами перепачкают.

Добавлено через 12 минут

Сообщение от COKPOWEHEU Вот вы опять себе противоречите. Сами описали какую-то нишу, где С++ неэффективен и тут же утверждаете что С++ идеален.

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

0

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

0

Сообщение от Kastaneda Как можно утверждать, что этот язык идеальный?

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

0

0

Сообщение от Kastaneda здесь есть лютый баг, и сходу его совершенно не видно.

В любой программе на любом языке содержащей более 0 логических строк потенциально есть лютый баг. Что из этого?

Добавлено через 7 минут

Сообщение от Kastaneda вот кусок кода, на который было потрачено (не мной) некоторое время на поиск бага

А при чем тут потенциально глючная библиотека/криворукое ее использование к возможностям языка? Язык как раз позволяет легко сменить ее на что либо более подходящее.
Не забывайте что в С++ окромя STL есть еще и С++, в отличии от к примеру пайтона или шарпа.

Добавлено через 12 минут

Сообщение от Kastaneda Как можно утверждать, что этот язык идеальный?

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

0

Fulcrum_013, ну так возьми быка за рога ситуацию в свои руки - присоединяйся к комитету.

0

Croessmah, Не считаю нужным. Демократия в таких делах неуместна - это банальный авторитет большинства. Но наука а тем более техника авторитетов не признает. Доказано и Страуструпом и Ритчи и многими другими.
Особенно показательна в этом плане история алгола. И рождался коммитетом 10 лет и умер практически сразу, а созданный без всяких коллегиальных бредней фортран, который оный алгол должен был типа заменить, и сегодня живее всех живых.

0

Fulcrum_013, я ж предлагаю внедриться, затем возглавить и, впоследствии, развалить данную организацию изнутри.

Добавлено через 1 минуту

Сообщение от Fulcrum_013 ну коммитету ремня надавать у самого руки чешутся уже давно

Сообщение от Croessmah развалить данную организацию изнутри.

Можно ввести, например, еженедельную публичную порку по заднице всех несогласных с Fulcrum_013.
Так сказать, двух зайцев сразу.

0