История изменений

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

Вы просто расписали часть того, о чем я не писал. И вся ущербность о который вы говорите проистекает из-за того что вы смотрите с позиции оторванности использования препроцессора от языка, а они должны использоваться вместе, тогда препроцессор действительно дает буст языку, потому что подстановка по тексту и обработка программы как текста это было неплохим решением проблемы даже не смотря на то, что она происходит вообще не в рамках языка и ничего о языке не знает, просто не стоит об этом забывать используя эту функциональность. В этом то и дело, что паскаль не мог предложить такого же механизма. Но я могу согласиться с тем, что паскаль опережал С того времени именно с позиции попыток думать наперед, и думать в рамках развития языка и попыток сделать его не только удобным, но и написание на нем кода безопасным. С намеренно оставляет все эти моменты гибкими, дело тут вовсе не в том, что ричи, томпсон и керниган были какими-то недалекими людьми, они просто сделали язык который в реалиях той разработки и той аппаратуры был гибче и проще в использовании. А вирт же выстраивал язык который будет именно помогать не делать распространенных ошибок. Вообще этот доисторический холивар не имеет смысла. Тут просто принцип Quod licet Jovi, non licet bovi и наоборот, нарушить вы его конечно можете, но все это будет смотреться как козе баян.

Претензия не принимается, паскалевы безопасные строки работают в том числе с нулевыми накладными расходами, и даже быстрее сишных строк на таких штуках, как конкатенция строк.

Такие строки воспроизводятся в С. Нультерминированные куда более естественные с позиции работы железа. Ну и делать вывод на основе конкатенации о том что они вообще лучше, ну такое себе.

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

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

Эту проблему пришлось решать, реализуя некорректные и опасные оптимизации в компиляторах (volatile, strict aliasing) — будто язык был недостаточно опасен без них.

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

Не знаешь, потому что твою программу скомпилируют на машине с «char» длиной 9 байт.

Выдуманный довод с char в 9 байт. С таким же успехом тогда может существовать реализация паскаля и железа где размерности не соответствуют ожиданиям.

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

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

В паскале проверка границ чисел была с самого начала.

Не знаю о какой проверке вы говорите, но переполнение так прекрасно работает, также как и везде.

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

Конечно можно, и конечно заимствовали. Все у друг друга заимствуют идеи. Реализация не имеет особой роли, если вы под заимствованием подразумеваете ее.

И как ты помешаешь мне сделать array[invalid_index]? В принципе, можно заставлять пользователя весь доступ делать через функции get/set. Но когда ты потом посмотришь на такую программу на Си, а потом на аналог на паскале, то однозначно скажешь, что такой Си не нужен.

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

А что разворачивать? Можно включить проверку границ строк, границ массивов, в том числе динамических. Ничего этого нету В Си в принципе.

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

Да, я сейчас проверил — как минимум в FPC добавили Си-подобное обращение к указателям. Тогда мой аргумент был некорректен. С другой стороны, в паскале все-таки принято использовать более безопасные способы работы с данными, чем арифметика с указателями.

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

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

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

Здрасти, а полтреда у нас о чем была? Парсинг языка инструментами — это абсолютно обязательное действие для программ сложнее hello world.

Ну возможно у вас пол треда об этом было, но парсинг языка это узконаправленная задача, делать какие-то выводы о языке и его применимости на основе этого тоже довольно странная вещь. Это попытка отрицать что есть куча сложного большого по на С где никто не парсит С, о каких hello world речь?

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

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

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

Вы просто расписали часть того, о чем я не писал. И вся ущербность о который вы говорите проистекает из-за того что вы смотрите с позиции оторванности использования препроцессора от языка, а они должны использоваться вместе, тогда препроцессор действительно дает буст языку, потому что подстановка по тексту и обработка программы как текста это было неплохим решением проблемы даже не смотря на то, что она происходит вообще не в рамках языка и ничего о языке не знает, просто не стоит об этом забывать используя эту функциональность. В этом то и дело, что паскаль не мог предложить такого же механизма. Но я могу согласиться с тем, что паскаль опережал С того времени именно с позиции попыток думать наперед, и думать в рамках развития языка и попыток сделать его не только удобным, но и написание на нем кода безопасным. С намеренно оставляет все эти моменты гибкими, дело тут вовсе не в том, что ричи, томпсон и керниган были какими-то недалекими людьми, они просто сделали язык который в реалиях той разработки и той аппаратуры был гибче и проще в использовании. А вирт же выстраивал язык который будет именно помогать не делать распространенных ошибок. Вообще этот доисторический холивар не имеет смысла. Тут просто принцип Quod licet Jovi, non licet bovi и наоборот, нарушить вы его конечно можете, но все это будет смотреться как козе баян.

Претензия не принимается, паскалевы безопасные строки работают в том числе с нулевыми накладными расходами, и даже быстрее сишных строк на таких штуках, как конкатенция строк.

Такие строки воспроизводятся в С. Нультерминированные куда более естественные с позиции работы железа. Ну и делать вывод на основе конкатенации о том что они вообще лучше, ну такое себе.

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

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

Эту проблему пришлось решать, реализуя некорректные и опасные оптимизации в компиляторах (volatile, strict aliasing) — будто язык был недостаточно опасен без них.

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

Не знаешь, потому что твою программу скомпилируют на машине с «char» длиной 9 байт.

Выдуманный довод с char в 9 байт. С таким же успехом тогда может существовать реализация паскаля и железа где размерности не соответствуют ожиданиям.

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

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

В паскале проверка границ чисел была с самого начала.

Не знаю о какой проверке вы говорите, но переполнение так прекрасно работает, также как и везде.

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

Конечно можно, и конечно заимствовали. Все у друг друга заимствуют идеи. Реализация не имеет особой роли, если вы под заимствованием подразумеваете ее.

И как ты помешаешь мне сделать array[invalid_index]? В принципе, можно заставлять пользователя весь доступ делать через функции get/set. Но когда ты потом посмотришь на такую программу на Си, а потом на аналог на паскале, то однозначно скажешь, что такой Си не нужен.

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

А что разворачивать? Можно включить проверку границ строк, границ массивов, в том числе динамических. Ничего этого нету В Си в принципе.

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

Да, я сейчас проверил — как минимум в FPC добавили Си-подобное обращение к указателям. Тогда мой аргумент был некорректен. С другой стороны, в паскале все-таки принято использовать более безопасные способы работы с данными, чем арифметика с указателями.

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

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

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

Здрасти, а полтреда у нас о чем была? Парсинг языка инструментами — это абсолютно обязательное действие для программ сложнее hello world.

Ну возможно у вас пол треда об этом было, но парсинг языка это узконаправленная задача, делать какие-то выводы о языке и его применимости на основе этого тоже довольно странная вещь. Это попытка отрицать что есть куча сложного большого по на С где никто не парсит С, о каких hello world речь?

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

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