LINUX.ORG.RU

Зачем нужен стандарт ISO для языков программирования?

 ,


1

3

Привет, ЛОР!

Почти в каждом местном сраче про Rust кто-нибудь пишет, что недостатком Rust в сравнении с C и C++ является отсутствие стандарта ISO. Ради интереса, я взял список самых популярных языков программирования (https://pypl.github.io/PYPL.html) и проверил, для каких из них есть стандарт ISO или стандарт вообще.

Довольно неутешительные для любителей стандартизации результаты я собрал в табличку. C и C++ по ссылке выше идут как один язык, но я разделил их. Для Delphi стандарта нет, но я упомянул стандарт для Pascal.

Language        Standard
--------        --------
Python          No
Java            Partial API only (https://www.iso.org/standard/54004.html)
Javascript      Non ISO, ECMAScript
C#              ISO withdrawn (https://www.iso.org/standard/42926.html)
PHP             No
C               ISO/IEC 9899
C++             ISO/IEC 14882:2017
R               No
Objective-C     No
Swift           No
TypeScript      No
Matlab          No
Kotlin          No
Go              No
VBA             No
Ruby            https://www.iso.org/standard/59579.html
Scala           No
Visual Basic    No
Rust            No
Dart            No
Perl            No
Abap            No
Lua             No
Ada             ISO/IEC 8652
Groovy          No
Julia           No
Cobol           ISO/IEC 1989:2014
Haskell         No
Delphi          No, Pascal ISO 7185:1991

Если не считать C, C++ и Ada, актуальных стандартов ISO нет ни у одного живого языка. Cobol и Pascal практически мертвы. Java и C# пытались стандартизировать, но от этой идеи вроде как все отказались. Плюс у них по сути по одной реализации, так что всем плевать.

В случае же с C и C++ наличие стандарта ISO никак не помогло никому. Более того, на эти стандарты разработчики компиляторов во многом кладут болт и часто реализуют их не полностью (история с export в C++, например). Плюс, наличие стандартов никак не мешает несовместимости между реализациями.

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

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

Скажи, ЛОР, по твоему мнению есть ли вообще смысл в этой бесполезной бюрократической возне? Какие есть вообще преимущества в стандартизации языков? Ну кроме как получать профит от продаж копий стандарта, потому что они стоят несчадных денег.

Глядучи на историю Ада Стандарты нужны для взимодейсвия с гигантскими бюрократическими струкутрами конкурирующиих поставшиков неведомой фигни. А если посмотреть C#/Java то идея конкуренции на почве одного языка успела сдохнуть. А там где у нас одна реализация и та никому нафиг не нужная открытая то и без надобности.

antares0 ★★★ ()
Ответ на: комментарий от Crocodoom

Отделение языка как такового от реализации.

Для C и C++ отделить не получилось, я регулярно в коде вижу ifdef для какого-нибудь компилятора. А жирные проекты типа Linux kernel вообще поддерживают максимум один компилятор официально.

hateyoufeel ★★★★★ ()
Ответ на: комментарий от cobold

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

Ясен хрен. Вопрос в том, зачем нужно заморачиваться с ISO и долбить новые стандарты по 10 лет.

hateyoufeel ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

У Python 3 много реализаций, нужна стандартизация?

Документ, описывающий желаемое поведение, необходим, иначе как понять что баг а что нет? Но, мне кажется, это не обязательно должен быть статичный талмуд на 100500 страниц, как у C++. Мне нравится подход, применяемый в Rust и Haskell, где есть RFC, описывающие желаемое поведение, и, в случае с Haskell, раз в ~10 лет эти RFC компилируются в один документ, который берётся за новую точку отсчёта.

hateyoufeel ★★★★★ ()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

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

anonymous ()
Ответ на: комментарий от demidrol

В языках описания аппаратуры без стандартов вообще никак.

Почему? И почему это обязательно должен быть стандарт ISO?

hateyoufeel ★★★★★ ()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от anonymous

Это проблема проектов закладывающихся на нестандартные расширения «компилятора», а не стандартизации.

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

hateyoufeel ★★★★★ ()

SQL… Вот некоторые сетевые протоколы, сначала производители лепили свои какие то расширения, а потом пришли к пониманию, что нужен общий стандарт. И отказались от проприетарных расширений

В очередной версии SQL наверняка все эти расширения причешут под что-то общее и от своих вариаций откажутся, либо оставят для совместимости

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от Crocodoom

Отделение языка как такового от реализации.

А зачем? У Go, Perl и Rust по факту всего одна реализация (ну, используемая хоть кем-то). Им это не мешает.

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от I-Love-Microsoft

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

В случае с сетевыми протоколами никто не пишет пакеты руками.

В очередной версии SQL наверняка все эти расширения причешут под что-то общее и от своих вариаций откажутся, либо оставят для совместимости

ХАХАХАХАХАХАХАХАХАХАХА!

hateyoufeel ★★★★★ ()
Ответ на: комментарий от anonymous

Но на руби стандарт есть: https://www.iso.org/standard/59579.html

Спасибо. Не знаю, как я это пропустил. Но, в любом случае, стандарту уже 8 лет, он under review, и реализация с тех пор сильно ушла вперёд.

И как теперь доверять твоему списку?

Доверяй но проверяй!

hateyoufeel ★★★★★ ()
Ответ на: комментарий от hateyoufeel

under review

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

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 2)
Ответ на: комментарий от kirk_johnson

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

Окей, понял. С другой стороны, интересно вот, какой в случае Ruby в этом смысл?

hateyoufeel ★★★★★ ()
Ответ на: комментарий от hateyoufeel

Вопрос в том, зачем нужно заморачиваться с ISO и долбить новые стандарты по 10 лет.

Может с ISO и не нужно заморачиваться, но альтернатива в виде «нахер нам стандарт не нужон» это еще хуже. Фактически такой подход запрещает альтернативные реализации, потому что за эталонной реализацией угнаться невозможно, и даже эталонно её воспроизвести трудно. Как яркий пример питон, где все альтернативные реализации загнулись. По понятным причинам корпорации тоже не горят желаниям стандартизировать свои поделки. А вот реально нужные (сейчас и в прошлом) языки, у которых нет одного хозяина, стандартизированы. Потому что это всем выгодно.

anonymous ()
Ответ на: комментарий от hateyoufeel

Окей, понял. С другой стороны, интересно вот, какой в случае Ruby в этом смысл?

Да никакого особо, просто процедура поддержки в актуальном состоянии. Вдруг там кто-то оператор «nigger» сделал, а так теперь нельзя говорить.

kirk_johnson ★☆ ()

Стандарт – отвязка от единственной реализации. Когда мозиллопеды меняют свой ЯП на лету Петя из 3-го А не успевает за ними обновлять свою реализацию под ГСС. Таким образом Мозилла Инк защищается от насмешек всего третьего А.

anonymous ()
Ответ на: комментарий от anonymous

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

У питона есть референс. Другое дело, что пилить ещё один питон оказался неблагодарным занятием.

kirk_johnson ★☆ ()
Ответ на: комментарий от hateyoufeel
  1. кто говорил про ISO?

  2. цена ошибки при проектировании асика (как правило) несравнимо выше, чем при написании софта.

Зачем стандарты – да просто монополистам (Cadence, Synopsys да Mentor) так проще договориться.

demidrol ★★★★★ ()
Последнее исправление: demidrol (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от kirk_johnson

Вдруг там кто-то оператор «nigger» сделал, а так теперь нельзя говорить.

В ассемблере для него есть мнемоника NEG. Только для белых парней.

anonymous ()
Ответ на: комментарий от hateyoufeel

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

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

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

anonymous ()
Ответ на: комментарий от hateyoufeel

Зачем нужен стандарт ISO для языков программирования?

Документ, описывающий желаемое поведение, необходим

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

недостатком Rust в сравнении с C и C++ является отсутствие стандарта ISO

Это кто такую чепуху сморозил?

anonymous ()
Ответ на: комментарий от kirk_johnson

Другое дело, что пилить ещё один питон оказался неблагодарным занятием.

Попыток было много. Но альтернативы всегда отстают, и в мелочах хромают по совместимости. Потому что код на питоне пишется под конкретную версию cpython, а не под версию стандарта. Это как js без ecmascript, была бы полная жопа, и никакой вам мозилы, и хром бы не родился.

anonymous ()
Ответ на: комментарий от demidrol

кто говорил про ISO?

Смотри заголовок.

Зачем стандарты – да просто монополистам (Cadence, Synopsys да Mentor) так проще договориться.

Ну понятно. Интересно, а вендоры поставляют свои расширения? Или у всех абсолютно одинаковые Verilog/VHDL и код без проблем переносится?

hateyoufeel ★★★★★ ()
Ответ на: комментарий от fsb4000

Using gcc on Linux

is_clang = false will make the build use system gcc on Linux. There are no bots that test this and there is no guarantee it will work, but we accept patches for this configuration.

Ну да. Т. е. по факту gcc тоже вполне работае. Впрочем, как и clang на «Linux kernel»

anonymous ()

Как известно на ЛОР много «критикующих».
Наверное они знают «как лучше»?
Или просто - … «Гусарам молчать!»?

Владимир

anonymous ()
Ответ на: комментарий от kirk_johnson

А зачем? У Go, Perl и Rust по факту всего одна реализация (ну, используемая хоть кем-то). Им это не мешает.

Есть gcc-go, llvm-go тоже есть, но Пайк поступил грамотно предоставив AST, SSA и прочую лабуду в stdlib. Llvm-go используется когда нужно WASM, где есть C-бинды.

kostyarin_ ★★ ()
Ответ на: комментарий от kirk_johnson

У Go, Perl и Rust по факту всего одна реализация (ну, используемая хоть кем-то). Им это не мешает

Конкретно расту помогает наличие того самого ИСО на кресты, благодаря которому(в том числе) есть llvm

anonymous ()

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

У delphi нет стандарта, как как он сам реализация языка, которая давно уже обросла так, что мало напоминает то, что приведено в стандарте pascal и самими pascal не является.

Visual Basic - тоже самое по отношению к BASIC.

Соответственно, если нет даже намёка на конкурирующие реализации (gcc-go сложно назвать конкурентоспособным), то какой-либо стандарт на этот язык никому не нужен.

Из свежих ещё есть стандарт Fortran 2018.

grem ★★★★★ ()