C vs. C++

Мне, например, слегка бомбит что не могу вместо крестов взять какой-нибудь OCaml/F#, но брать вместо крестов си - совсем уж маразм.

Да и кресты, кстати, движутся примерно в сторону ML, так что бомбит с каждым стандартом всё меньше %)

Те, кто между ужасным и удовлетворительным выберет удовлетворительное.

И в 99% это будут не кресты. Разве что дано железо, под которое нет gcc (и Ады со спарком) или llvm с растом, а компилятор крестов каким-то чудом есть, но такое случается очень редко.

Я про другое: разные хаскели мало кому интересны по понятным причинам.

Судя по взлету elm, typescript, reasonml, scala, интересу к F* и Coq со стороны всяких tls-описателей и проч функциональщине в мейнстрим языках, вполне интересно. Да и речь не про популярность, само собой для любого вменяемого биза всегда будет быстрее и дешевле нанять пыхокодеров писать веб магазин, нежели искать каких лисперов.

Бери вместо крестов JS.

Все можно написать на почти чем угодно, это не аргумент

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

Типы данных позволяют писать правильные программы перекладывая значительную (ЗНАЧИТЕЛЬНУЮ) часть работы на компилятор.

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

OCaml, Rust, Scala, Java, ruby, Haskell, Ada/Spark, F#, C#, F*, CL, racket, SML в зависимости от задачи.

Про то, что люди кой-чего на Си уже написали пруфы надо?

Ты лучше посмотри, что на си _не_ написали. И не напишут. Его несколько побольше.

В си я любые данные по битам разобрать могу

Ты и в эрланге искоробки можешь.

не как мне разрешит компилятор

strict aliasing

Везде, где требуется набор операций, специфичный для структуры данных, уместно и ООП. Да, его можно реализовать и в Си, даже с наследованием, но код будет более многословный, менее надёжный и хуже читаемый.

А ещё у обоих сегодняшних боксёров общий недостаток — отсутствие модульности, вместо которой до сих пор костыли на препроцессоре из середины 70-х. В C++17 вроде как хотели запилить модули, но яйца оказались недостаточно стальными.

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

посиди в ирке на каналах #c и #c++ на фриноде, тебе там за сутки напишут на 10 лет вперед

brainfuck тоже Тьюринг-полный, почём не пишешь? KISS же - всего 8 операторов.

А я уж переживал что не вспомните. Уж лучше бы ассемблер.

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

И кому же эта фича нужна?

Тем, кому нужно жанглировать данными. Драйверописателям, например. Ну и прочая обработка информации. Архиваторы годные есть не на си?

Если типы данных тебе мешают, то ты просто сделал паршивую архитектуру. Ограниченя накладываются не «потому что можно» и не что бы толкать тебе палки в колёса, а что бы разрешить только те действия, которые имеют смысл.
Примеры то хоть приведи где система типов тебе мешала.

Ты лучше посмотри, что на си _не_ написали. И не напишут. Его несколько побольше.

Я бы поспорил. И чего на си(++) не написали и не напишут? Веб страницы? Сценарии оболочки?

В си я любые данные по битам разобрать могу

Ты и в эрланге искоробки можешь.

Да везде можно. Где нельзя — можно прикрутить сишную функцию.

Но скажи мне: ты щас положа руку на сердце скажешь что драйвера лучше писать на эрланге, чем на си?

А ещё у обоих сегодняшних боксёров общий недостаток — отсутствие модульности

что ты имеешь в виду?

Возможность жанглировать байтами ≠ Легаси.
Факт отсутствия (Не проверял) архиваторов не на C говорит о том что люди не хотят изобретать колесо заново/ломать совместимость, а вовсе не о том что архиваторы больше не на чем писать. Вот что принципиально мешает написать/переписать архиватор/драйверы/прочую_обработку, например, на Rust? Не считая драйверов, что мешает сделать архиваторы/обработку на $LANGUAGE_NAME?

И в 99% это будут не кресты

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

Да и речь не про популярность

Речь про то, что вот эта unsoundness - мейнстрим, который никого не пугает. На агрумент против C++ (особенно в сравнении с си) не тянет.

Ограниченя накладываются не «потому что можно» и не что бы толкать тебе палки в колёса, а что бы разрешить только те действия, которые имеют смысл.

Не поспоришь.

Примеры то хоть приведи где система типов тебе мешала.

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

C＋＋ ужасен, Си тоже не фонтан, но более понятный, а идеал Go и Limbo.

который никого не пугает.

В tls мире очень даже пугает. В аэроспейсе тоже. В финансовом мире тоже люди пробуют окамлы с хаскилями и скалами. Мир движется в сторону изощренных и sound систем типов. Раньше отсутствие параметрического полиморфизма людей не пугало, сечас это норма. Завтра нормой будет система типов а-ля скала/окамл (см раст и 20 стандарт С++), послезавтра — полноценный dependent types. Мир не стоит на месте.

Факт отсутствия (Не проверял) архиваторов не на C говорит о том что люди не хотят изобретать колесо заново/ломать совместимость, а вовсе не о том что архиваторы больше не на чем писать

А я об этом и говорю. Си — далеко не идеален, но все написано на си. Мир так устроен. И глупо с этим не считаться.

Вот что принципиально мешает написать/переписать архиватор/драйверы/прочую_обработку, например, на Rust? Не считая драйверов, что мешает сделать архиваторы/обработку на $LANGUAGE_NAME?

принципиально — ничего. но не пишут же. Почему? А потому что так сложилось.

Хотя что ещё считать драйвером.

Шаблоны - никто не пользует.

Ты идиот? Имя Standard Template Library тебе о чём-нибудь говорит? vector<int> ни разу не видел?

Перегрузка операторов - вообще дурь какая-то: не понятно чего ожидать от полюса или минуса.

Ожидай от них семантики сложения и вычитания, внезапно.

Очевидный ответ - объекты , а так уж они нужны? .. И чем оно лучше, чем если бы я запилил структуру и набор функций для работы с ней?

Наследованием и полиморфизмом. RTFM

Я имею в виду модули как логические единицы программы, а не просто файлы для раздельной компиляции. #include не парсится компилятором, он просто включает одну простыню текста в другую простыню текста.

Если ты, скажем, в объектном паскале забудешь написать uses, ты предсказуемо получишь сообщение об ошибке — модули не обладают транзитивностью. В си и крестах при пропущенном #include результат зависит от фазы Луны, поскольку в одной системе простыни из сторонних библиотек могли быть включены друг в друга, а в другой нет.

Ещё из-за отсутствия модульности приходится применять левые системы сборки, стражи компиляции и др. Я уже молчу про скорость сборки, это в 2018 году не самая большая проблема (обычно).

А есть вероятность, что я не толстый, а просто любопытный?

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

А я об этом и говорю. Си — далеко не идеален, но все написано на си. Мир так устроен. И глупо с этим не считаться.

Не всё, но многое. Написано не потому что C лучше сейчас, а потому что тогда ничего лучше не было.

принципиально — ничего. но не пишут же. Почему? А потому что так сложилось.

И в этом нет ничего хорошего.

Ну так я далек от лозунгов в стиле «кресты форева». Если можно взять язык лучше - замечательно. Но есть задачи (и много), где нужен максимально быстрый и/или экономный по памяти язык. И тут их остается пара-тройка, и из них только кресты тянут на современный язык с мощной инфраструктурой.

см 20 стандарт С++ Мир не стоит на месте

И это опять же агрумент за кресты. В них всё больше инструментов контроля, у сишников - всё то же «нормальные программисты не ошибаются».

Шаблоны - никто не пользует.

Шаблоны без вариадиков и третсов действительно ниочём. Но вот начиная с c++11 темплейты стали очень мощной штукой.

Перегрузка операторов — вообще дурь какая-то: не понятно чего ожидать от полюса или минуса.

«Аргументы по-умолчанию и перегруженные функции — вообще дурь несусветная: не понятно чего ждать от вызова функции». Так что-ли?

Алсо в плюсах есть std::thread, std::chrono, std::optional и куча других приятных вещей. Кроссплатформенне, унифицированне, офигенне.

Молодец. Приз 🏆 за самый тупой пост года.

И тут их остается пара-тройка, и из них только кресты тянут на современный язык с мощной инфраструктурой.

Ада, раст. У крестов нет инфраструктуры по меркам 2018 года.

Functional reactive programming

Пробовал в реальности?

Напомню, что сравниваем с си. У крестов почти вся их инфраструктура и еще много своего.

Но если считать что это значит «нет», то к чему вообще вспоминать аду и раст?

язабан

Пробовал в реальности?

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

современный веб уй пишется в этой парадигме

На чем пишешь?

биндинги к гуевым либам в функциональных языках

А в не функциональных?=)

На чем пишешь?

На камле.

самое УГ перечислил. Хуже только boost

Толстовато. Даже не интересно получается, обсуждалось, ЕМНИП, много раз.

P. S. Попробуй что-то вида C++ vs Rust или что там сейчас котируется

сколько раз c++ son null из-за параноидальной типизации. Часто сильно портит жизнь, заставляя писать многобуков, лишние касты. Особенно неоднозначность бесит. Когда 2 перегрузки оператора на в некоторых случаях применимы, возвращают одно и то же - для одного компилятора это нормально, для другого неоднозначно

Kotlin, Java, Ruby, Python, Julia

Из этого ЯП - только Java и Python. Один калечнее другого

Когда 2 перегрузки оператора на в некоторых случаях применимы, возвращают одно и то же - для одного компилятора это нормально, для другого неоднозначно

Пример?

https://travis-ci.org/FWGS/hlsdk-xash3d/jobs/409508253
https://travis-ci.org/FWGS/hlsdk-xash3d/jobs/409508252

И тут их остается пара-тройка, и из них только кресты тянут на современный язык с мощной инфраструктурой.

Ада

Просто из любопытства - какая такая инфраструктура есть а Ada?

Ну ok.

Тогда, в общем и целом, на C++ на порядок проще и безопасней писать. За освобождением ресурсов не надо следить потому что RAII. Ошибки за каждой функцией не нужно проверять потому что исключения. Есть стандартная библиотека в которой есть хотя бы строки.

Итого, банальная программа расчёта медианы, описанная на естественном языке как «открыть файл, прочитать из него сколько в нём есть чисел, отсортировать, вывести средний элемент». На C++ будет написана 1 в 1 так же, оставаясь корректной (т.е. с обработкой ошибок, с освобождением утечек и с освобождением ресурсов), на C она разрастётся раз в 10, потому что тебе как минимум нужно будет написать руками вектор на realloc, проверять за каждым вызовом open, malloc, realloc, read код возврата и обрабатывать ошибки, освобождать все выделенные ресурсы, руками парсить содержимое файла и т.д., а потом отлаживать ошибки которые ты во всём этом допустил.

Шаблоны - никто не пользует.

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

Перегрузка операторов - вообще дурь какая-то

Подумай головой, как ты без перегрузки операторов будешь работать с комплексными числами, длинной арифметикой, векторами или матрицами. Строить кашу из вложенных вызовов банальных функций сложения-умножения? С перегрузкой ты напишешь a * b + c * d для любых типов объектов, это будет понятный поддерживаемый код в котором не получится допустить ошибку.

не понятно чего ожидать от полюса или минуса

Это детские страхи. Сами по себе операторы не переопределятся, а там где их переопределили их определили с вполне конкретной целью. А вот в C, напомню, вообще ничего ожидать ни от чего нельзя, поскольку убогость языка фикится макросами, а с ними банальный MIN(a, b) может привести к чему угодно.

gnat с полноценной системой сборки, spark, ravenscar, нормальная стандартная либа с тасками, контейнерами, примитивами синхронизации, decimals, ну всякое вендерспецифик от производителей компиляторов.

gnat с полноценной системой сборки, spark, ravenscar

Из этого всего на инфраструктуру тянет разве что система gnat. Ravenscar - ЕМНИП, набор прагм; SPARK - отдельный язык.

нормальная стандартная либа с тасками, контейнерами, примитивами синхронизации, decimals

Сейчас это и в Си++ есть.

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

Учитывая, что float — вообще по сути не числа, использовать с ними перегрузку вообще не камильфо. Вообще работать никто не мешает, см lapacke и cblas.

Booбще перегрузка аля ООП (C++, всякие питоны) это тихий ужас. Правильней объявлять какие-то интерфейсы, вроде тайпклассов или трейтов, вроде Ord, PartialOrg, Applicative, и писать реализации для конкретных типов.

SPARK - отдельный язык.

frama-c — тоже отдельный язык?

Спарк — просто верификатор на SAT+coq (когда сат не справляется), который проверяет, что пре и пост условия выполняются и программа не кидает исключений. Для сишки есть ее прямой аналог, фрама.

Ravenscar — формализованный набор прагм, как опенмп.

Нет ужаса autotools/cmake — уже победа, я считаю.

Сейчас это и в Си++ есть.

В си++ есть децималс в стандартной либе? В крестах есть только низкоуровневые примитивы, вроде барьеров и атомиков, не? Есть там очереди всякие, каналы, и проч. [1] или все руками писать?

[1] https://en.wikibooks.org/wiki/Ada_Programming/Tasking

В этом вся ирония плюсов. Именно те вещи, которые делали из них «better c», получились самыми УГ. Ну а дальше они сами себя закопали в куче говн.

sound систем типов

скала/окамл (см раст

Мир не стоит на месте.

Видел тут недавний пост про web? Так вот, хипстерки, когда стоит это хорошо :)