LINUX.ORG.RU

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

Исправление wandrien, (текущая версия) :

Я днём прочитал новость про сабж на опеннете и как раз думал, что вечером на ЛОРе обсудим :D

Я почитал в общих чертах про TrapC и Fil-C, и я не понял нишу для этих языков. На мой взгляд, это академические проекты без будущего. Объясню, почему я так считаю.

«Простой Си-подобный язык с легковесным рантаймом и сборкой мусора» уже существует и называется Go. Я думаю, усилиями Google Go уже занял все возможные ниши, где именно такой язык был востребован.

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

Я не вижу для этого причин кроме разве что чисто субъективной «у Си такой хороший синтаксис».

Но с моей точки зрения, синтаксис Си как раз не хорош. Хорош был именно сам язык как концепция и также набор компиляторов к нему, что позволило доминировать в определённой нише на протяжении долгого времени. В то время как конкуренты по полунизкоуровневому программированию оставались на этапе концептов или очень узкоспециализированных решений (Паскаль, Модула и т.п.)

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

А теперь возвращаесь к анализу языков:

Выше по треду была упомянута дихотомия Оустерхаута.

На мой взгляд, существует язык, который относительно успешно умудряется сочетать в себе обе стороны дихотомии, расплачиваясь за это жирным рантаймом, но покрывая при этом очень большие области прикладного программирования, в том числе и гейм-дев. Это C#. Технически он не «скриптовый», но умудряется местами довольно эффективно покрывать часть этой ниши. До такого монстра TrapC очень далеко, и у них никак не могут пересекаться ниши.

Далее в скриптовой стороне дихотомии сейчас тотально преобладают JS и Python.

В «системной» стороне, кроме самого Си, ниши поделили C++, Go, и вот теперь еще — Rust.

Попытки создать Си-подобный язык с продвинутыми статическими гарантиями были давно, я помню несколько проектов начиная с 00-х. Но выстрелить в итоге смог только Rust, от остальных попыток сейчас даже названий никто не помнит.

Как по мне, этот новый ЯП просто некуда тут вставить. Нет запроса, который можно было бы удовлетворять.

А на что может быть запрос?

Я вижу два направления, где это возможно.

Первое.

Это язык, который «концептуально прост», но при этом имеет мощные средства типизации и/или метапрограммирования, компилируясь при этом в код с минимумом ран-тайм издержек. То есть ЯП, который попытается конкурировать с Си++ и Rust за счёт более «простого и ясного» кода без существенной потери выразительных средств (или даже с увеличением выразительности, чем чёрт не шутит). На самом деле, в этой нише постоянно возникают различные любительские проекты, которые пытаются эту задачу как-то решить. То есть у людей не только есть запрос, но и постоянно присутствует впечатление, что задача решаема. Что «можно почти так же — но проще». Так это или нет — покажет время.

Второе — более реалистичное. И где также идёт активная работа разных компаний.

Это развитие компиляторов самого Си. То есть задача не в том, чтобы сделать «ЯП похожий до степени смешений, но отличающийся». А сделать более мощные средства контроля семантики кода и аннотации этой семантики. Чтобы ворох UB, которые молча проглатывают современные компиляторы, можно было более эффективно ловить и контроллировать. Как в компайлтайме, так и в рантайме, в зависимости от того, что это конкретно за виды UB или ошибок. Чтобы в зависимости от потребностей разработчика, при отладке ПО всё это контролировалось опциями сборки или прагмами в самом коде.

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

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

Исправление wandrien, :

Я днём прочитал новость про сабж на опеннете и как раз думал, что вечером на ЛОРе обсудим :D

Я почитал в общих чертах про TrapC и Fil-C, и я не понял нишу для этих языков. На мой взгляд, это академические проекты без будущего. Объясню, почему я так считаю.

«Простой Си-подобный язык с легковесным рантаймом и сборкой мусора» уже существует и называется Go. Я думаю, усилиями Google Go уже занял все возможные ниши, где именно такой язык был востребован.

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

Я не вижу для этого причин кроме разве что чисто субъективной «у Си такой хороший синтаксис».

Но с моей точки зрения, синтаксис Си как раз не хорош. Хорош был именно сам язык как концепция и также набор компиляторов к нему, что позволило доминировать в определённой нише на протяжении долгого времени. В то время как конкуренты по полунизкоуровневому программированию оставались на этапе концептов или очень узкоспециализированных решений (Паскаль, Модула и т.п.)

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

А теперь возвращаесь к анализу языков:

Выше по треду была упомянута дихотомия Оустерхаута.

На мой взгляд, существует язык, который относительно успешно умудряется сочетать в себе обе стороны дихотомии, расплачиваясь за это жирным рантаймом, но покрывая при этом очень большие области прикладного программирования, в том числе и гейм-дев. Это C#. Технически он не «скриптовый», но умудряется местами довольно эффективно покрывать часть этой ниши. До такого монстра TrapC очень далеко, и у них никак не могут пересекаться ниши.

Далее в скриптовой стороне дихотомии сейчас тотально преобладают JS и Python.

В «системной» стороне, кроме самого Си, ниши поделили C++, Go, и вот теперь еще — Rust.

Попытки создать Си-подобный язык с продвинутыми статическими гарантиями были давно, я помню несколько проектов начиная с 00-х. Но выстрелить в итоге смог только Rust, от остальных попыток сейчас даже названий никто не помнит.

Как по мне, этот новый ЯП просто некуда тут вставить. Нет запроса, который можно было бы удовлетворять.

А на что может быть запрос?

Я вижу два направления, где это возможно.

Первое.

Это язык, который «концептуально прост», но при этом имеет мощные средства типизации и/или метапрограммирования, компилируясь при этом в код с минимумом ран-тайм издержек. То есть ЯП, который попытается конкурировать с Си++ и Rust за счёт более «простого и ясного» кода без существенной потери выразительных средств (или даже с увеличением выразительности, чем чёрт не шутит). На самом деле, в этой нише постоянно возникают различные любительские проекты, которые пытаются эту задачу как-то решить. То есть у людей не только есть запрос, но и постоянно присутствует впечатление, что задача решаема. Что «можно почти так же — но проще». Так это или нет — покажет время.

Второе — более реалистичное. И где также идёт активная работа разных компаний.

Это развитие компиляторов самого Си. То есть задача не в том, чтобы сделать «ЯП похожий до степени смешений, но отличающийся». А сделать более мощные средства контроля семантики кода и аннотации этой семантики. Чтобы ворох UB, которые молча проглатывают современные компиляторы, можно было более эффективно ловить и контроллировать. Как в компайлтайме, так и в рантайме, в зависимости от того, что это конкретно за виды UB или ошибок. Чтобы в зависимости от потребностей разработчика, при отладке ПО всё это контролировалось опциями сборки или прагмами в самом коде.

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

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

Исходная версия wandrien, :

Я днём прочитал новость про сабж на опеннете и как раз думал, что вечером на ЛОРе обсудим :D

Я почитал в общих чертах про TrapC и Fil-C, и я не понял нишу для этих языков. На мой взгляд, это академические проекты без будущего. Объясню, почему я так считаю.

«Простой Си-подобный язык с легковесным рантаймом и сборкой мусора» уже существует и называется Go. Я думаю, усилиями Google Go уже занял все возможные ниши, где именно такой язык был востребован.

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

Я не вижу для этого причин кроме разве что чисто субъективной «у Си такой хороший синтаксис».

Но с моей точки зрения, синтаксис Си как раз не хорош. Хорош был именно сам язык как концепция и также набор компиляторов к нему, что позволило доминировать в определённой нише на протяжении долгого времени. В то время как конкуренты по полунизкоуровневому программированию оставались на этапе концептов или очень узкоспециализированных решений (Паскаль, Модула и т.п.)

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

А теперь возвращаесь к анализу языков:

Выше по треду была упомянута дихотомия Оустерхаута.

На мой взгляд, существует язык, который относительно успешно умудряется сочетать в себе обе стороны дихотомии, расплачиваясь за это жирным рантаймом, но покрывая при этом очень большие области прикладного программирования, в том числе и гейм-дев. Это C#. Технически он не «скриптовый», но умудряется местами довольно эффективно покрывать часть этой ниши. До такого монстра TrapC очень далеко, и у них никак не могут пересекаться ниши.

Далее в скриптовой стороне дихотомии сейчас тотально преобладают JS и Python.

В «системной» стороне, кроме самого Си, ниши поделили C++, Go, и вот теперь еще — Rust.

Попытки создать Си-подобный язык с продвинутыми статическими гарантиями были давно, я помню несколько проектов начиная с 00-х. Но выстрелить в итоге смог только Rust, от остальных попыток сейчас даже названий никто не помнит.

Как по мне, этот новый ЯП просто некуда тут вставить. Нет запроса, который можно было бы удовлетворять.

А на что может быть запрос?

Я вижу два направления, где это возможно.

Первое.

Это язык, который «концептуально прост», но при этом имеет мощные средства типизации и/или метапрограммирования, компилируясь при этом в код с минимумом ран-тайм издержек. То есть ЯП, который попытается конкурировать с Си++ и Rust за счёт более «простого и ясного» кода без существенной потери выразительных средств (или даже с увеличением выразительности, чем чёрт не шутит). На самом деле, в той нише постоянно возникают различные любительские проекты, которые пытаются эту задачу как-то решить. То есть у людей не только есть запрос, но и постоянно присутствует впечатление, что задача решаема. Что «можно почти так же — но проще». Так это или нет — покажет время.

Второе — более реалистичное. И где также идёт активная работа разных компаний.

Это развитие компиляторов самого Си. То есть задача не в том, чтобы сделать «ЯП похожий до степени смешений, но отличающийся». А сделать более мощные средства контроля семантики кода и аннотации этой семантики. Чтобы ворох UB, которые молча проглатывают современные компиляторы, можно было более эффективно ловить и контроллировать. Как в компайлтайме, так и в рантайме, в зависимости от того, что это конкретно за виды UB или ошибок. Чтобы в зависимости от потребностей разработчика, при отладке ПО всё это контролировалось опциями сборки или прагмами в самом коде.

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

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