LINUX.ORG.RU
ФорумTalks

Встречайте очередную замену Си

 ,


0

8

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

https://drewdevault.com/2021/03/19/A-new-systems-language.html

use io;

export fn main() void = {
	const greetings = [
		"Hello, world!",
		"¡Hola Mundo!",
		"Γειά σου Κόσμε!",
		"Привет мир!",
		"こんにちは世界!",
	];
	for (let i = 0z; i < len(greetings); i += 1) {
		io::println(greetings[i]);
	};
};

По сравнению с Си:

  • More robust error handling via tagged unions
  • Improved, Unicode-aware string support
  • Memory safe array, slice, and pointer types (and unsafe versions, if needed)
  • Direct compatibility with the C ABI for trivial C interop
  • A simpler, context-free, expression-oriented syntax
  • A standard library free of the constraints of POSIX or the C standard
★★★

Последнее исправление: dadd (всего исправлений: 1)

Ответ на: комментарий от Psilocybe

foreach (greetings as item)

Максимально безграмотный вариант. Корректный и устоявшийся foreach (item of greetings) тогда уж. Откуда ты эту дичь взял?

WitcherGeralt ★★
()

А где описание самого языка? По ссылке его нет.

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

Не нужно. Во многих случаях надо не просто обойти весь массив. Это поощряет написание кода с break/continue и прочие костыли.

Это подход питона с его прокрустовым ложе отступов.

Как диапазоны проверять?

item >= greetings && item < greetings+len(greetings)
Psilocybe ★★★★
()
Ответ на: комментарий от interrupted

что нибудь о нем имеете рассказать?

Сначала была проприетарная RapidEuphoria ©, протухшая из-за жадности её владельцев. А OpenEuphoria опоздала и не конкурент питону.

впечатления от использования?

Не пользовался, не было необходимости, да и сообщество там небольшое, глянь на ихнем форуме ©.

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

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

deep-purple ★★★★★
()

Пример скучный. Даже не факториал и вычисление чисел Фибоначчи. Но даже и это можно сделать веселее:

let greeting = "Привет!";
greeting[2] = "е";
greeting[5] = "д";

и чтобы оно в их utf-8 правильно вставило.

Или ещё так:

export fn main(object io) void = {
    io.print(...);

И типа можно выводить не обязательно в консоль, а в специально подготовленный для тестов mock-объект.

Kogrom
()

https://drewdevault.com/2021/03/19/A-new-systems-language.html

Пацаны к успеху идут:

https://drewdevault.com/2021/03/03/To-make-money-in-FOSS-build-a-business.html

Я хз, какую он там придумал модель для своего секретного проекта, но без какой-то конкретики нет смысла говорить всерьез про эту опоздавшую лет так на 20 (когда индустрия окончательно ушла на Java/C#) попытку.

Например, из примера не ясно, в каком месте здесь «memory-safe» массив, если перечисление идет по индексам. Или он думает, что сможет всегда вывести соотношение фактической границы массива с вычисленной?

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

Правда на уровне бинарников её скорее всего нет, т.к. формат ELF не поддерживает полноценную модульность без специальных трюков. Полноценная модульность (two-level namespace symbol resolution) есть в PE (EXE, DLL), Mach-O (Mac OS) и исполняемых форматах Оберона

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

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

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

Звучит, как nim. Нет, спасибо %)

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

нет смысла говорить всерьез про эту опоздавшую лет так на 20 (когда индустрия окончательно ушла на Java/C#) попытку.

Какой-то неадекват.

Какая-то индустрия мб до сих пор ушла на C#, Java и прочие тормозные поделия, но системное программирование (и другие применения, где важна производительность или interop с существуюими библиотеками на C) до сих пор на C или плюсах.

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

А Конкурировать с GCC и LLVM в генерации эффективного кода очень трудно. Свой кодогенератор будет генерировать медленный код

По моему поверхностному опыту, написание эффективной генерации LLVM IR само по себе требует много ресурсов и представляет собой эдак половину всей трудоемкости оптимизации. Потому что бэк у LLVM довольно тупой, и даже до весьма очевидных оптимизаций может не догадаться. Не потому, что LLVM кривой, а потому что во-первых у самого IR слабая описательная способность, а во-вторых IR стал такой потому, что в него нужно транслировать из C/C++, у которых тоже слабая описательная способность в плане оптимизаций — прежде всего из-за использования модели машины Тьюринга, от которой в IR отходят, но недостаточно далеко. Потому что машина Тьюринга в общем случае неоптимизируема, нужно высокоуровневое представление, допускающего большую свободу в интерпретации программы.

Вон, Гвидо тоже думал «щас возьму LLVM и сделаю AOT компиляцию питона» — но соснул за обе щеки, потому что LLVM не будет ничего за тебя делать, он может только транслировать уже предоптимизированный код в машинный код.

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

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

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

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

Особенно для мелких функций модульность на уровне машинного кода не имеет смысла

Она имеет смысл потому что можно обновлять модули без перекомпиляции а также потому что модули могут быть написаны на разных языках и использовать несовместимые линкеры (например многие компиляторы Оберона производят свой формат модулей, который можно линковать только в исполняемые файлы (ELF, EXE/DLL), но не в объектные файлы (*.o)).

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

Например всем процессорным разработчикам объединиться и сделать универсальный многоядерный процессор, который будет способен решать любые текущие задачи и в качестве языка взять С, добавить туда чего не хватает и жить спокойно ещё лет 50?

У вас оксиморон получился. Си и многозадачность не сочетаются.

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

Дрю Деволт

Но он же отбитый наглухо

Во, мне тоже так показалось. А какие у тебя причины так считать?

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

Миллион макак хипстерков не напишут нужный в 21 веке ЯП, как минимум в этом десятилетии, даже если их бесплатно кормить на фултайм

Я напишу, но меня никто не будет кормить.

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

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

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

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

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

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

системное программирование (и другие применения, где важна производительность или interop с существуюими библиотеками на C) до сих пор на C или плюсах

Или поголовно на плюсах. А на сихе поддерживается только наследие. На CLR/JVM ушла именно прикладуха, которая до того писалась на низкоуровневых языках, в том числе на Си. Потому что комерсы готовы в любое время дня и ночи получать гарантию надежности в обмен на уменьшение производительности в 2-3 раза.

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

там что нету i++?

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

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

Она имеет смысл потому что можно обновлять модули без перекомпиляции а также потому что модули могут быть написаны на разных языках и использовать несовместимые линкеры (например многие компиляторы Оберона производят свой формат модулей, который можно линковать только в исполняемые файлы (ELF, EXE/DLL), но не в объектные файлы

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

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

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

В чём проблема? Один модуль — один бинарник. У каждого модуля своё пространство имён.

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

В случае статической линковки всё тоже самое. Статическая и динамическая линковка логически ничем не отличается если не использовать загрузку модулей в рантайме (dlopen).

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

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

Неужели я правильно угадал и мои навыки таки кому-то в индустрии нужны, кроме как написания модулей для ядра Linux?

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

Это тяжело сделать нормально

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

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

В чём проблема? Один модуль — один бинарник. У каждого модуля своё пространство имён

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

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

Ты представляешь, как это будет динамически грузится?

Да. Оберон так и работает. Каждый исходник компилируется в отдельный динамически загружаемый исполняемый файл. Таких модулей загружаются сотни и более и всё быстро стартует и работает. Причём даже на очень слабом железе таком как Apple Macintosh 128K или ранних 32 битных процессорах.

При загрузке для каждой переменной найди символ

O(log(n)). Бинарный поиск в отсортированном массиве символов.

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

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

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

Кроме сети. Внезапно. :)

Legacy. И в новых протоколах часто используется little endian. При желании можно сделать C++ обёртку int32be и т.п., которая будет автоматически конвертировать endian при присваивании и передаче.

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

Legacy. И в новых протоколах часто используется little endian.

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

При желании можно сделать C++

С++-то тут при чём? Я про plain C.

Речь про то, что есть например, структура, которая целиком отправляется в сеть. Сахарок на уровне препроцессора типа (HTON)структура не помешал бы.

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

Я про plain C.

Не нужен. У вас какие-то взаимоисключающие параграфы: то вы хотите plain C, то препроцессорный сахарок.

Сахарок на уровне препроцессора типа (HTON)структура не помешал бы.

Этот сахарок уже есть и называется C++.

Сахарок на уровне препроцессора типа (HTON)структура

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

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

Не нужен.

Когда покажете хоть одну мало-мальски используюемую ОС на чём-то кроме сишечки, тогда приходите. По секрету скажу - была одна такая, Epoc32 AKA Symbian, да вот только издохла уже достаточно давно. Да и мякотка работающая непосредственно с железом в ней была написана таки на plain C.

Этот сахарок уже есть и называется C++.

Это уже не сахарок, это почти другой язык.

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

Когда покажете хоть одну мало-мальски используюемую ОС на чём-то кроме сишечки

Windows. C++ там активно используется. В ядре не так активно, но тоже используется.

Это уже не сахарок, это почти другой язык.

Это расширение Си, значительная часть кода на Си компилируется как C++. Весь функционал C++ опционален, что нужно, тем и пользуются. И ваше предложение ((HTON)структура) — это уже значительное изменение, так что по вашим же словам это станет другим языком.

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

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

Препроцессор может например развернуть (HTON)host в net.field1 = hton_type1(hostfield1); net.field2 = hton_type2(host.field2)..... Всё проще будет. Препроцессору при этом и не надо знать про типы. Ну или в самом компиляторе.

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

В плюсах:

for (auto item : greetings);

Ну и обычный (сишный) массив так ясное дело так не итерируется, только объекты vector array map

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

net.field1 = hton_ type1(hostfield1);

Препроцессору при этом и не надо знать про типы.

Опять взаимоисключающие параграфы.

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

Это расширение Си

Но большая часть C++ нафиг не нужна там, где нужен plain C.

значительная часть кода на Си компилируется как C++.

А незначительная часть - не компилируется. Два компилятора для одного языка - неразумно.

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

Но большая часть C++ нафиг не нужна там, где нужен plain C.

Не пользуйтесь, вас никто не заставляет. Надо автоматическое конвертирование endian — пользуйтесь только им.

А незначительная часть - не компилируется.

Это легко чинится.

Два компилятора для одного языка - неразумно.

Открою страшную тайну: компилятор C и C++ уже давно один, просто это разные режимы. Компилятора чистого Си кроме примитивного TCC вы уже не найдёте.

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

type1 - это всего лишь текст, написанный перед именем поля.

Там может быть много чего написано, в том числе void **ptrs, __attribute__(...), int (Function*)(void *arg) или ещё что нибудь. Нужен полноценный синтаксический анализ языка.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)

Дрю Деволт

Имя показалось знакомым в контексте NIH.
И оказывается, да: он один из переписывателей интернета в проекте Gemini Gemini-клиент Lagrange 1.2

Есть подозрение на новый штамм вируса Поттеринга.

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

Там может быть много чего написано

Да, геморрой, и хотя адреса функций передавать по сети - весьма сомнительное занятие, суть понятна, и главное - с вложенными структурами проблема у препроцессора будет. Значит нужна конструкция компилятора, сделанная по типу какого-нибудь typeof должна быть.

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

Открою страшную тайну: компилятор C и C++ уже давно один, просто это разные режимы.

Вот только в одном режиме он ругается на то, что в другом режиме вполне допустимо.

Компилятора чистого Си кроме примитивного TCC вы уже не найдёте.

Ещё sdcc есть. :)

Stanson ★★★★★
()

а кто это такой и чем знаменит, напомните плз

Harald ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.