Опубликовано видео докладов slcon3 (suckless conference 2016)

я лучше бы на такую конфу сходил

а чо ж не сходил?

Так тонко, что аж жир сочится :)

Вообще, использование информации о типах из dcu помогает (не нужны precompiled headers), но там те же самые проблемы с шаблонами и define-константами что в C и C++. А автокомплит по dcu будет на уровне kwrite пока из 4-х сломанных файлов проекта не починишь хотя бы 3.

В общем, для достижения описанных тобой целей надо препроцессор убирать и шаблоны выкидывать, а не звездочки заменять. Да, и ты еще забыл про begin/end и точку в конце модуля :)

я лучше бы на такую конфу сходил
а чо ж не сходил?

Er spricht nicht Deutsch. Verstehst du mich.

готовность scc / Simple C Compiler и его преимущества перед GCC

И как? Готов? Зачем нужен?

На самом деле этот вопрос в докладе опущен. Чувак сказал, что scc лучше, чем tcc, потому что в tcc код некрасивый. А про GCC только сказал что-то типа «ха-ха, ну вы понели...»

Er spricht nicht Deutsch. Verstehst du mich.

У них же серьезная международная конференция. Официальный язык - английский.

Просто интересно - создание каких инструментов невозможно для Си?

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

у тебя паскаль головного мозга.

Эти симптомы есть у многих лучших инженеров. Например Robert Pike, который книги писал совместно с Brian Kernighan.

Но есть много дегенератов которые почему-то думают что понимают недостатки языков основанных на Pascal.

С идеален, не трогай его

Так считают только идиоты.

Модульный, компонентный Паскаль более совершенный инструмент, чем язык Си

То есть всё дело в модулях и компонентах? Это даже для 80-х уже звучало смешно.

В языке Си же, знаки «равенства» и «присваивания» нарушают математические соглашения.

Но не создают значимых проблем с позиций инженерной теории.

Звучит, как оправдание. Сказал бы честно, что люди привыкли. Кстати, это не вина самого языка Си, это вина американского образа мышления. Фортран был таким же.

У них же серьезная международная конференция. Официальный язык - английский.

Данке юнге. Ми етого ни снали.

То есть всё дело в модулях и компонентах? Это даже для 80-х уже звучало смешно.

«Смеётся тот, кто смеётся последним». Прочитай про язык «Компонентный Паскаль».

«Смеётся тот, кто смеётся последним».

Ну да, всего-то нужно подождать подольше.

Прочитай про язык «Компонентный Паскаль».

Зачем? В нем есть что-то новое и интересное по сравнению с C++, Java, Scala, Ocaml, Rust и прочими живыми языками?

Просто интересно - создание каких инструментов невозможно для Си?

Всё что связано с IDE.
Для начала нужно получить информацию о том что вообще компилируется. Какие файлы? В какой последовательности? Какие определения препроцессора активны и в каких частях кода?

Статически получить эту информацию невозможно. Вся этa информация содержится в разных системах сборки проектов.
Единственный правильный подход это назвать программу анализатор именем компилятора(soft link) и пропустить компиляцию проекта через этот анализатор который вместо компиляции будет собирать всю информацию в процессе.
Так делает RTags. Но в RTags ещё есть режим который анализирует stdout во время компиляции, где ищет с помощью regexp строки которые напоминают строку вызова компилятора(gcc, cc, опции), потом использует средства CLang. Так же должно быть работает и Netbeans для C но без CLang.

Проекты могут компилироваться и несколько часов.
Aнализаторы приходится делать с хаком для typedef, во время парсинга передавать в лексер информацию о всех встреченных typedef в коде. Иначе невозможно отличить имя переменной от псевдонима типа(typedef), все встреченные typedef должны накапливаться в отдельном массиве, и лексер проверяет этот массив когда встречает любое название в коде, если этот символ есть в массиве накопленных typedef'ов, значит это не токен имени переменной а название типа.
https://en.wikipedia.org/wiki/The_lexer_hack

Для начала нужно получить информацию о том что вообще компилируется. Какие файлы? В какой последовательности? Какие определения препроцессора активны и в каких частях кода?

Всё это определяется. См. любую современную IDE для Си.

Статически получить эту информацию невозможно.

Допустим. И что?

Проекты могут компилироваться и несколько часов.

Большая часть этих часов тратится в оптимизаторах.

Aнализаторы приходится делать с хаком

Это печально, но не более.

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

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

В случае со стандартным C, программисты нередко используют консервативный сборщик мусора(Hans Boehm) потому что не уверены в ручном управлении памятью на данном этапе развития проекта. Тоже такой хак.

Всё это определяется. См. любую современную IDE для Си.

И я описал как это определяется. Это жопа, но так как есть ощущение «ламповости» от C, у меня в том числе, то на это обычно закрываются глаза.

Всё это определяется. См. любую современную IDE для Си.

И я описал как это определяется. Это жопа

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

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

Это печально, но не более.

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

И работать с печалью мало кто хочет. Обычно люди занимаются аутотренингом убеждая себя - «меня это не волнует, всё и так хорошо, я не трачу своё время впустую». Хотя есть такие которые вообще не задумываются и адаптируют javascript для server side.

Или же работа с таким сопровождением: http://www.youtube.com/watch?v=znc3XnSdGFA

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

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

Ты пока не ответил.

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

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

Статический анализатор.

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

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

Вау. Что такое «статический сборщик мусора»? Сборщик мусора, работающий без запуска программы?

Вау. Что такое «статический сборщик мусора»? Сборщик мусора, работающий без запуска программы?

Ручное управление, но при использовании статического анализатора который указывает где точно необходимо вмешательство программиста по управлению памятью, или где есть вероятность.
Наверное изначально невозможно доказать 100% надёжность такого метода в императивном языке(и можно ли в чисто функциональном), но это полезный метод в для системных языков.

В Rust это зашито в синтаксис на низком уровне и во многом ограничивает. Но ещё предстоит осознать преимущества и недостатки такого подхода с ростом объёмов кода и его поддержки.
Статический анализатор мог бы определять качество кода всего проекта по заданным критериям или даже стандартам критериев, автоматический аудит кода. Высокоуровневые характеристики кода, как эффективность типов данных по статистическому анализу их использования в проекте, даже таких простых комбинаций типов как в C. Это одно из направлений AI по сути.

Вау. Что такое «статический сборщик мусора»? Сборщик мусора, работающий без запуска программы?

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

Да, наверное, это невозможно для Си. Но возможность этого не продемонстрирована и для Паскаля. Если учесть, что Rust ( и ранее Cyclone) для этого понадобилась новая нетривиальная система типов, думаю, в Паскале такой сборщик тоже невозможен.

В Rust это зашито в синтаксис на низком уровне

Ты постоянно путаешь синтаксис и семантику.

Детская лексика как-то мешает прислушаться к юным дарованиям, а это и вовсе позволяет поставить диагноз:

http://git.suckless.org/scc/tree/cc1/stallman.msg

Это скорее накладывает даже теоретические ограничения, так что многое даже реализовать не пытаются

Что реализовать не пытаются? Парсеры пишут, семантические анализаторы пишут, а с появлением libclang вовсе о чем тут говорить. Да, черезжопно, медленно и лет на 20 позже чем где-то в Паскале, но оно ж в продакшн пойдет, как иначе ;)

А вот лично ты сколько значимого софта написал, которым пользуются люди? На паскале или ещё чем-нибудь

В любом случае, в C много недостатков, их исправить легко, там нет задач которые хотя бы заставляют остановиться и долго думать. Единственное препятствие - legacy.

SCC, Simple C Compiler никак не адресует эти недостатки.

Ты постоянно путаешь синтаксис и семантику.

Тогда не «зашито в синтаксис», а является частью стандарта языка. В синтаксис добавлены элементы которые облегчили бы семантический анализ. Мутабельность mut, &mut.
В C квалификатор типов const является частью синтаксиса, но семантика не определена стандартом как указывается в описании компилятора SCC, потому они просто игнорируют квалификаторы типов.

Компилятор это семантический парсер.
Парсер который проверяет PEP8 для Python, неглубокий(shallow) семантический парсер, или вообще несемантический парсер.
Возможные статические анализаторы которые я приводил в пример - глубокие семантические анализаторы.

Семантический анализатор Sparse для Linux работает со специальными аннотациями в препроцессоре определяющими разные __attribute__(для GNU C). Тоже оболочка во время компиляции(CC = cgcc в Makefile). Скорее всего примитивный анализ изолированных участков.

На паскале или ещё чем-нибудь

На C, python/cython, elisp. Но денег больше всего когда-то принёс PHP. Там самые большие деньги приносит Wordpress, просто на конвейерной основе, люди пользуются. Когда узнаёшь что такой «конвейер» приносил некоторым по $1300-$2000 в неделю(не в США, из дома), как-то печально становится из-за того что в своё время не взялся за этот конвейер и не создал базу клиентов и партнеров регулярно поставляющих заказы на «конвейер».
Никакие не Symfony2 и Laravel, хотя тоже есть ниша.
Программирование не самый лучший вариант в эти времена. Кто раньше это понял(до 2009), сейчас каждый год-два покупает новую квартиру что бы сдавать в аренду. Один раз скопив капитал.

blablabla, embedded pascal in your brains ...

Эталонный NIH. Такие лапочки :)

Большая часть этих часов тратится в оптимизаторах.

А вот кстати спорный вопрос. Берем hello world на Qt и делаем gcc -E, получается простыня более мегабайта. И все это приходится обрабатывать для каждого модуля проекта (т.е. десятки и сотни раз).

Это правда больше к вопросу почему pure C GTK компилится реактивно а C++/Boost/Qt/KDE десятки секунд тратит на каждый модуль. В pure C с этим получше, но у паскаля, явы и додиеза обычно шустрее выходит, т.к. все нужное осталось в объектнике/class-файле или что там использовалось. И не надо 9000 раз парсить stdio.h.

Для решения проблемы парсинга over900 stdio.h уже сделали во всех компилерах preprocessed headers. Если юзать С, это будет не медренее паскаля, по логике все тоже самое. Вот только мало кто этим заморачивается.

В Rust это

Мне кажется, у нас сформировалась новая специальная дисциплина: кто-то по старинке все ещё соревнуется в скорости скатывания рандомных тредов в обусждение гитлера, но ведь rust как универсальный аттрактор дискуссий ничем не хуже? :D

И, чтобы не вставать два раза, реквестирую твоё авторитетное мнение по https://eigenstate.org/myrddin/

но ведь rust как универсальный аттрактор дискуссий ничем не хуже? :D

Это не я, это он.

реквестирую твоё авторитетное мнение по https://eigenstate.org/myrddin/

Указатели есть, функции выделения/освобождения памяти вижу, контроля за памятью не вижу (хотя особо не искал); «спека» языка <1000 строк, написана в 2012 году. Мое авторитетное мнение сводится к «еще одна заброшенная игрушка, любопытная, но не более».

Интересно взглянуть на мужиков лет 30 +/-, которые, как в юности, общаются в терминах «сосёт», «не сосёт», «отсосёт» и т.д.

Сравнил россию и цивилизованную западную страну. У них это в разы проще, и это хорошо.

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

Но сейчас я о другом, у меня такое впечатление сложилось, что Паскаль для Windows удобен, а чистый Си удобен для Linux. Средний паскальщик разве не пользователь экосистемы Windows.

но ведь rust как универсальный аттрактор дискуссий ничем не хуже?

Suckless, SCC(Simple C Compiler). Почитать что в C sucks по их мнению, и в этом контексте сразу появляется Rust как одно из решений, пока не проверенных.

https://eigenstate.org/myrddin/

Лучше исправить C добавлением модульной системы как в TurboPascal/FreePascal/Golang, и минимальным изменением синтаксиса для обозначения типов и указателей. Это позволяет поддерживать существующий код через его преобразование без изменения его семантики. Как результат компиляторы быстрее на порядки, настоящие IDE, и другое. Всё остальное уже по желанию, улучшенные структуры с методами и перегрузка операторов для структур.

Это одна цепь рассуждений от SCC, особенно когда есть ещё и TCC.

изменением синтаксиса для обозначения типов и указателей

а зачем, кроме паскализма? вот компилятору не пофигу как будто, * там или ^

Он просто явно влюбился в паскаль) Синтаксис ему поменяй, модули дай. Про Precompiled Headers в С скромно умолчал, хотя от .tpu это ничем не отличается - проприетарный формат каждого отдельного компилера с метаинформацией. Про модули в новых си стандартах уже давно думают, только вот по нормальному и стандартизировано это сделать не так просто.

а зачем, кроме паскализма? вот компилятору не пофигу как будто, * там или ^

Как бонус для улучшения читабельности.
Не только другой символ, но ставить его перед типом, а для dereferencing ставить после имени переменной. В C наоборот. И сложные указатели трудно читать по спирали.

Для многих символ «*» слишком ментально перегружен, но можно и оставить.
Функции должны объявляться ключевым словом как в Golang, func(или def).
Функция и один указатель на неё тождественны, тип возврата в конце.

char *str[10]; // std C
//
^char str[10];

char *(*fp)(int, float*); //std C
//
typedef fp = func (int, ^float) ^char;

void (*signal(int, void (*fp)(int)))(int); // std C
//
typedef f_int_void = func (int) void;
typedef signal = func (int, f_int_void) f_int_void;

Получать адрес переменной лучше символом «@» вместо «&». Означает «at», «по какому адресу».

Так правильнее для массивов, как в Golang, добавляет токен «var»:

char *str[10]; // std C
//
var str [10]^char;

Как бонус для улучшения читабельности.

ставить его перед типом

для dereferencing ставить после имени переменной

Функции должны объявляться ключевым словом

тип возврата в конце

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

чисто для «чтобы синтаксис там был не такой, как сейчас»

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

Да, во FreePascal уже всё есть что надо.
В Golang исправлено.

Инженерные ошибки закреплённые в legacy давлеют над психикой, потому что всё сделано на C и многие не понимают в чём проблема с подстановкой текста для компиляции миллионов строк кода. Когда уже есть готовый продукт как Linux то важность такого достижения психологически перекрывает все сомнения относительно недостатков языка даже у перфекционистов. Но начинать новое сложно. Жизнь Торвальдса связана с C, «дедушка старый, ему всё равно».

Потому SCC странный. Название suckless не раскрыто.
Но ладно там C, можно мириться. Но в случае с C++ всё тяжелее обстоит. Он частично почти везде уже, в GCC, в Blender.

Это не вопрос вкуса как некоторым кажется, синтаксис меняется в результате конкретных инженерных решений.

^ от * как с инженерной точки зрения отличается?

тип возврата в конце, а не в начале, разыменование после имени переменной, а не до него - что «инженерно» изменят?

Про Precompiled headers голословное заявление. Сам же за инженерный подход, ну так и в чем же разница? Паскаль геренит tpu, С геренит gch. Ну и почему разницы не должно быть заметно? Вся разница паскалевской модульности уходит, возьми strace и убедись. Вот то что это костыль - это да, в частности потому что tpu одного компилятора не подойдет к другому, нет стандарта. Вот о нем и думают в новых стандарте, но так и не додумали пока. Это только вершина айсберга, проблем там много,

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

Строго говоря такого языка как Паскаль нет. Вернее был такой ЯП в 1970 гг.

^ от * как с инженерной точки зрения отличается?
тип возврата в конце, а не в начале,

Изменение символа не единственное изменение.
Надо почитать lexer hack, если не понятно, то надо учиться, как работает парсер.

Ну давай, модифицируй и показывай свое чудо http://www.quut.com/c/ANSI-C-grammar-y-2011.html http://www.quut.com/c/ANSI-C-grammar-l-2011.html . Не забудь уместиться в пару десятков кб.

Паскаль геренит tpu, С геренит gch.

Раздельная компиляции была уже в конце 80-х в TurboPascal.
Каждый файл во FreePascal это unit, модуль.
Программист определяет интерфейс модуля, зависимости от других units. Примерно как import в Python.
Каждый unit компилируется в .ppu файл(portable pascal unit). Во время компиляции проверяется каждый ppu по графе зависимостей между ними. В unit могут быть секции инициализации и деинициализации, это не какой-то файл текстовой подстановки.
Структура проекта/программы часть языка, синтаксиса. Не нужен Makefile(только для административных действий).
Функции создания/чтения .ppu файлов это часть стандартной библиотеки.
Generics сохраняются в .ppu как некоторое macro, и проигрывается для генерации кода когда нужно для каждой специализации(specialize).

Ассемблерные блоки тоже часть синтаксиса языка(asm ... end;). Вариант ассемблера выбирается. В этих блоках можно использовать имена переменных определённых за пределами блока.
Это означает что в коммерческих или специализированных продуктах можно делать ставку на ассемблерную простую оптимизацию вместо неявной оптимизации в компиляторе(но она тоже проводится).

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

Теперь попробуй объяснить своими словами этот коммент для TYPEDEF.
А потом сказку продолжим, в принципе всё что я постил ранее в треде, но будет уже понятнее.

storage_class_specifier
	: TYPEDEF /* identifiers must be flagged as TYPEDEF_NAME */
	| EXTERN
	| STATIC
	| THREAD_LOCAL
	| AUTO
	| REGISTER

Всё это может привести к некоторым решениям в Golang, почему типы лучше указывать после переменной, справа. Другой эффект от этого, что можно избавиться от «правила спирали» сложных опеределений в C: http://c-faq.com/decl/spiral.anderson.html

Короче.
Когда пишешь компилятор, вот этот storage_class_specifier, надо определять что это псевдоним типа как где-то было указано в typedef кода. Лексер должен сформировать токен именно такого типа TYPEDEF_NAME. Но лексер по идее не обладает контекстной информацией, он же просто сканирует текст образуя терминальные символы(токены) для парсера.

Простое решение это собирать в свой массив все встреченные typedef. Лексер видит слово, и ищет его в этом массиве, если оно там есть, значит это typedef, и формирует токен TYPEDEF_NAME. А собирает все эти typedef в массив парсер, лексер просто проверяет. Такая связь жесткая получается, нет разделения.

CLang откладывает это на отдельную семантическую фазу как я понимаю. После прохода по всей программе, он начинает сопоставлять все эти storage_class_specifier и искать их в базе всех typedef.

Проблема здесь также в том что в C нет никакой информации как компилируется программа, зависимости между файлами. Ивестно только что файлы используют цепочки headers как интерфейс, и в этих цепочках много нондетерминизма(ifdef) который зависит от последовательности включения этих файлов, которая может быть разной в отдельных файлах. Вся информация о проекте содержится только в сторонней системе сборки, Makefile.
Как-то полноценно работать с кодом можно только в компиляторе, если у компилятора есть система плагинов и она реализована так что можно всякие дела делать.