LINUX.ORG.RU

О божественном C и введение в него через ed

 , ,


4

2

Бытие (частично) определяет.

*Какая регулярка преобразует for с телом в while с телом ?

*Какой #define макрит for в while?

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

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

Завязывай с барбитуратами и сходи уже по ссылке. Там синтаксис типизированного Си, автором которого таки является DMR.

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

парадокс ситуации в том что ты по ситуации основываешся только на статьи Ритчи - обрати внимание что на сайте нокие не Томпсона и Кернигана теперь нет - они были даже и после 2011 г. - но вот на дистанции 2011- сейчас при переездах архива bell-labs деревья user/kwr user/ken и некоторое другие причастные к той комнате 1120 вроде - (авторские права наверно :) ) - Теперь там нет.

Повторюсь - Ритчи естественно причастен к Си - а начиная с некоторого момента был главным owner ( в терминах unix man тех версий) - но!

существенная часть семантики Си(Ритчи ТМ) была цельнотянута - из мемуара Кернигана и из интервью ему же Томсоном - следует что Томсону… и он занялся другими проектами

т.е язык ( В ли С ли не важно ибо это был ресёч) был обусловленн задачей сделать компилятор компиляторов для фортрана помещающейся в 4К 18битных слов команд той машины - поэтому там же были попытки использовать шитый код (моднаяя ваще тема при дефиците озу) - постепенно при переносе Unix происходило переписывание Unix’а на меннее обусловленный конкретной машиной синтаксис - вот тогда и появились структуры ( без них Томсон с его слов фэйлил) и чанки разного количества битов (8 16 32)

так как в одного Томсон не алё unix - То и Ритчи получил за Unix авард тьюрринга.

то что Томсон не фигурирует как основной автор Сишки - это соответствует природе людей :)

qulinxao3
() автор топика
Ответ на: комментарий от LamerOk

и в любом случае for в сырцах тех лет появляется позже while

  • именно по принципу 80/20 - если частный случай достаточно част его использование облегчают - такова экономика усилий.

т.е синтаксис

for с ; между круглыми скобками

да и ваще

использование синтаксиса

команда(

не отличимая без знания контекста от вызова

функция(

многое сообщает о утилитарности мобильного языка переноса килерапликухи UNIX

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

парадокс ситуации

Нет никакого парадокса, кроме твоих маняфантазий.

ДМР был соучатником в разработке Би. КТ был соучатником в разработке Си. Но в целом авторство на Би (= реализация) для двух платформ за КТ. Авторство на первую реализацию Си - за ДМР. Буковки по ссылке - это преимущественно ДМР.

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

VCF East 2019 – Brian Kernighan interviews Ken Thompson https://www.youtube.com/watch?v=EY6q5dv_B-o

Вышла книга Брайана Кернигана «UNIX: A History And A Memoir» Вышла книга Брайана Кернигана «UNIX: A History And A Memoir»

в интервью в шутливом рассказе «комп не серьёзен если у него нет фортрана» обьяснено впихунье невпихуемого с успешным впихиванием.

так же во многих местах Томпсон утверждал о том что они с Ритчи настолько идентично писали код - что на «следующий день» уже не ясно кто же автор ( автор обычно тот кто писал не так ли ?)


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

так что Томпсон никогда не и скореее всего никогда и вдальнейшем не скажет что Ритчи меньший автор компилятора того языка которым распрострялся Unix

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

AST в 1972+- у Томпсона?

Назови мне компилятор Си, который не пользуется AST? У Си сложная в разборе граматика, потому примерно половину-четверть компиляции у GCC обычно занимает именно превращение текста в AST.

byko3y ★★★★
()

О божественном C и введение в него через ed

«Не произносите имя Божье всуе».

Владимир

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

поэтому синтаксис Сишки очень g/re/p-френдли - для блочного полу и полностью автоматического транслированния. - т.е регулярка(с расшириностями подобна якству) могла и на асме ваяться. тем отцам не привыкать

Редкостная бредятина. Си в фундаменте не является контекстно-независимым, потому регулярками в принципе не парсится, ему нужен минимум LALR. Он может парсится перловыми регулярками, потому что перловая «регулярка» не является регулярным выражением, а является тьюринг-полным языком, с рекурсиями и бесконечным состоянием.

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

Назови мне компилятор Си, который не пользуется AST

tcc

Да. Потому TCC не может делать оптимизаций, кроме как на уровне выражения.

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

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

«Можно» - это такой-себе аргумент. Можно аккуратно ездить на машине без тормозов, но с тормозами ездить намного удобнее и безопаснее. Писать компилятор без AST будет сложнее, как и сложнее будет подстраивать под разные диалекты. По этой причине создатели серьезных компиляторов четко разграничивают этап разбора текста с этапом генерации промежуточного представления. Это примерно как MVC - можно было бы писать интерфейсы без него, но отлаживать и поддерживать такой код будет значительно сложнее.

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

«Можно» - это такой-себе аргумент.

«Такой-себе аргумент» - такой-себе аргумент.

Можно аккуратно ездить на машине без тормозов, но с тормозами ездить намного удобнее и безопаснее.

А еще можно и ручные парсеры писать, а не выписывать удобную и безопасную грамматику. Oh, wait…

Писать компилятор без AST будет сложнее

Неправда.

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

А кто сказал, что у первых компиляторов C и ТСС нет этапа с промежуточным представлением? Просто это не обязательно AST. Это может быть и стек, и parser tree.

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

Смотря какие интерфейсы имеются в виду.

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

ща плотнее ознакамливаюсь с историей Pascal -0 -4 -P0 -P4 и как оно плесенораспространялось и есть некоторое зерно в утверждение Вирта что килерапликуха Unix для языка Си

(bootstrappable.org](http://bootstrappable.org/) , bootstrapping.miraheze.org, pascal p5 p5, p6

для начала

ещё был какой-то Тимохин с клоном турбопаскаля, ссылку потом найду

P4 и прочие занятны тем, что самодостаточны и раскручены сами-на-себе.

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

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

Это типичная жертва комитета. Примерно пересказываю процесс создания фичи:

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

Перешептывание в зале «Что он несет? Вы слышали когда-то про гипопотамов с марса?». Встает кто-то самый смелый, и грит:

- Да вы же поехавший, какой к черту марс, какие гипопотамы? Я их никогда не видел, и мои коллеги не видели. Зачем пытаться работать с расчетом на непонятно что?
- Давайте по существу, пожалуйста, поконструктивнее. Вы не разобрались в вопросе, и кроме как «вы же поехавшие» вам нечего ответить. Это не тот уровень разговора, который ожидается в комитете по стандартизации. Если у вас есть конкретные замечатения - мы будем рады их услышать.

Проходит месяц, проходит другой, никто так и не понял, что же это за гипопотамы - фича остается в стандарте. Так были убиты Algol 68, PL/I, Ada, так превращены в говно стандарт C и SQL - сами C и SQL остались, потому что есть такая штука, как фактический стандарт, который живеет всех живых и не имеет отношения к комитетному бурлению говен.

Теперь конкретные замечания, по сути. Продвинутые возможности препроцессора в PL/I используются в 0.1% случаев, а создают половину всех проблем, поскольку простые возможности макросов применяются повсеместно. Безконтрольное, неограниченное метапрограммирование создает большие проблемы в поддержке проекта, в совместимости на разных платформах.

вот сравнение PL/I и Cи с точки зрения проектных решений. так вот, с этой точки зрения сишечка сосает присвистывая

Это сравнение мочи с говном. Почему ты не хочешь сравнить PL/I с паскалем? Это я уже не говорю, что автор статьи - мудак, и делает очень поверхностное сравнение, типа «вот тут в языке Си порядок слов важен, а в PL/I - не важен, значит, PL/I лучше», «в Си нет встроенного I/O, а в PL/I - есть». Да, есть некоторые хорошие замечания: пример с передачей по ссылке я сам привожу в критике Си, поскольку в фортране, коболе, паскале передача по ссылке есть, но K&R ничего об этом не слышали.

byko3y ★★★★
()
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от SZT
FOR(int i = 0, i < 10, i++, {
    printf("test %d\n", i);
})

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

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

AST в 1972+- ?

Регулярка overkill в большинстве случаев. К тому же не даёт возможности detailed errors.

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

А кто сказал, что у первых компиляторов C и ТСС нет этапа с промежуточным представлением? Просто это не обязательно AST. Это может быть и стек, и parser tree

Parser Tree - это Concrete Syntax Tree, потому очень близко к AST. По причине этой близости я с легкостью готов признать, что мой ответ был неточен, и я бы переформулировал его как «Писать компилятор без синтаксического дерева будет сложнее».

Тот же питон транслирует исходники в стэковую машину (смотри Parser/parser.c), но для метапрограммирования и просто разбора исходников в комплекте есть парсер в AST - именно потому, что в таком виде с кодом можно начинать работать програмно. Компиляторы Си по сути занимаются метапрограммированием, когда инлайнят функции, разворачивают циклы, скаляризуют составные структуры - для этого им нужно удобное представление кода.

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

Смотря какие интерфейсы имеются в виду

Любые интерактивные интерфейсы. Даже банальное консольное приложение, которое читает ввод у пользователя и выдает строку в ответ - в нем обрабатываемые данные хранятся в отдельной «модели», а механизмы отображения (печать текста, printf) отделены от механизмов ввода (scanf). И пусть схожесть слов printf и scanf вас не смущает - это соверенно разные функции.

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

есть некоторое зерно в утверждение Вирта что килерапликуха Unix для языка Си

Можно предоставить пруф для этого высказывания?

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

У Си сложная в разборе граматика

Да нет.

граматика

Грамотей.

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

Писать компилятор без AST будет сложнее

Достаточно построить не́древовидную структуру.

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

P4 и прочие занятны тем, что самодостаточны и раскручены сами-на-себе

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

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

Достаточно построить не́древовидную структуру

Это какую? LLVM IR еще можно записать как массив массивов, но любой более-менее высокоуровневый язык такого уже не позволяет.

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

Это какую? LLVM IR еще можно записать как массив массивов, но любой более-менее высокоуровневый язык такого уже не позволяет.

С чего бы это нет, если точка входа всего одна. А как референсы строить между элементами – дело 150-ое. Имеет смысл – scope, entity и собственно entry, если есть. Строй какие хочешь структуры из этого – порядок следования только в скриптухе имеет значение.

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

язык ( В ли С ли не важно ибо это был ресёч) был обусловленн задачей сделать компилятор компиляторов для фортрана помещающейся в 4К 18битных слов команд той машины

Tiny Pascal/People's pascal влезал в 16 к. Претензия руководства к K&R была в том, что они наклепали какое-то говно, которое не влазит в ресурсы целевой машины того времени. Но каким-то образом ты умудрился это интерпретировать как «они изначально разрабатывали сверхмаленькую программу».

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

Это какую? LLVM IR еще можно записать как массив массивов, но любой более-менее высокоуровневый язык такого уже не позволяет.

С чего бы это нет, если точка входа всего одна. А как референсы строить между элементами – дело 150-ое. Имеет смысл – scope, entity и собственно entry, если есть. Строй какие хочешь структуры из этого – порядок следования только в скриптухе имеет значение.

Ты так и не ответил, что будет вместо дерева. Если не держать связи между элементами, то программа, анализирующая эти структуры, сама будет вынуждена достраивать эти связи, и в итоге мы все равно приходим к дереву, как к естественной интерпретации текстовой формы кода. Вот питон и TCC не строят дерево. Что между ними общего? Они не делают оптимизации кода.

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

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

то что Сишка LALR не было в тех задании за отсутствием такового.

факт в том что Сишка(для ригористов доРитчи сишка) - автором re-механизма. синтез идей всё такое.

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

Си с теоретической кочки - ужас ужас - оттого(не достаточное но необходимое - ибо теория как оказалась не полна) и взлетел

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

который не взлетел - эталонно первый был самокомпиляцией с ручной трансляцией в cdc6000 асм.

кста «Паскаль создавался до Си, потому» –центрично и а-темпорально

по конусам-Миньковского и Паскаль и Си творились независимо - а вот проникновение массовое в универы - сначала Паскаль (в разных вариантах - но взлётный с P-code ) а затем вытеснение более близким к железу Си - по журналам тех лет видно что лаг где-то в 5 лет был для публики.

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

у Томпсона в интервью Кернигану зарисовка как из драйвера к быстрому «hdd»-вентилятору-вертикальному «самозародилась» UNICS с оверлеизацией пользоватальской реализации языка разработки -

«там» же языки ( в более поздних терминах dsl) клепались по необходимости - эволюция sh…

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

"типизированнный" С, ну как же, лол

т.е язык ( В ли С ли не важно ибо это был ресёч) был обусловленн задачей сделать компилятор компиляторов для фортрана помещающейся в 4К 18битных слов команд той машины - поэтому там же были попытки использовать шитый код

если прослеживается линия наследования идей, C > B > BCPL > дальше сложно, ну хоть тот же PL/I, и компилятор компиляторов TMG, например.

то в BCPL например, с типизацией всё плохо (BCPL упрощённый CPL, который потомок Алгол 60, и у него, CPL, тоже с типизацией всё плохо). потом появляется «типизация» в C, но тоже какая-то недоделанная, прилепленная наспех.

например, если переменные не описаны, они получают тип int (классический K&R). указатели так и не типизированы полностью: поскольку для проверки возможности присвоения используется sizeof, а sizeof указателей разных типов одинаков => можно присваивать указатели на яблоки указателям на апельсины, и компилятор это проглотит.

потом наспех попытались это исправить. но остался указатель на void. приведением к которому всё равно всё ещё можно алиасить.

вот в том же PL/I, например, сделано правильно – указатели типизированные. и через DCL 1 W , 2 X, 2 Y, 2 Z можно заалиасить union: W структуры и X,Y,Z desctructuring-bind из отдельных полей, в совокупности одинаковых со структурою размеров.

то есть, не нужно приводить типы указателей – это пустое. нужно сразу переменные по адресу указателя (контролируемые переменные) алиасить, а указатели оставить в покое, пусть совместимость их присваивания проверяет компилятор, у него голова железная, и не устаёт.

в Аде то же самое повторяется: указатели опять типизированы. и указателям на яблоки нельзя присвоить указатели на апельсины, это существенно разный тип. через субтипы и типы диапазоны можно. или ручным приведением, которое должно быть явным (а не как в С) – тоже можно.

так что С как бы «типизированный». и как бы нет – в смысле указатели не типизированные-то, и автоматически приводятся к совместимым по присваиванию типам, к тому же указателю на void, например. ещё по историческим причинам этот косяк из B и BCPL тянется.

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

Си с теоретической кочки - ужас ужас - оттого(не достаточное но необходимое - ибо теория как оказалась не полна) и взлетел

Аргумент инвалид, потому что целая гора ужас-ужас-языков не взлетели. Си был прогрессивен потому, что упал в пустую нишу. 95-98% институтского мудачья занималось высокими материями, создавая свои аналоги кобола-фортрана-алгола, с модульностью, безопасными указателями, встроенной инкапсуляцией ввода-вывода, и просто бесконечным кол-вом встроенных в язык конструкций (аля кобол). Также существовали совсем уже абстрактные астронавты с лиспом, где метаметапрограммы создавали метапрограммы, создающие программы. Хочешь заниматься системщиной? Даже просто написать свой компилятор - добро пожаловать в мир ассемблера. «Мы выше грязной системщины» - говорят те же люди, которые в 2020 году создают вот такой мусор:
From CIL to Java bytecode: Semantics-based translation for static analysis leveraging
Automated urban train control with hybrid Event-B: ‘Tackling’ the rugby club problem
Beyond connected cars: A systems of systems perspective

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

И вот откуда ни возьмись в это время в Bell Labs появляются задроты, которые умеют писать реальный софт. И они говорят «да вы задостали со своими фантазиями, нам нужен язык, на котором можно просто писать софт, ОС-и, компиляторы, системные утилитки, в конце-концов». Они на скорую руку клепают что-то, отдаленно напоминающее язык программирования. Потом приходят другие люди, смотрят на эту картину, и удивляются «ух ты, а так можно было?». Паскалю понадобилось еще лет 5-10, чтобы выйти по системщине на тот же уровень, поскольку паскаль тогда больше напоминал жаву, нежели Си, то есть, язык для виртуальной машины, абстрагированной от платформы — время было потеряно, Си уже окопался, и выбить его из ниши было сложнее. Сложнее, но вполне возможно — где-то до 2000 года борьба продолжалась. Borland признало поражение в 2003, с выпуском Delphi 8, не имевшим поддержки паскаля.

byko3y ★★★★
()
Ответ на: "типизированнный" С, ну как же, лол от anonymous

да не был Си типизированым - а если когда либо и стал - то больше в маркетинговом смысле - мода на слова-маркеры такая -

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

как в том анекдоте - в чём измеряется сила тока и в том анекдоте напряжение

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

кста «Паскаль создавался до Си, потому» –центрично и а-темпорально

Я не понял, есть что возразить? В 1967 создан BCPL, потом в 1969 создан B, а в 1972 только появился C. Algol W создан в 1966, паскаль - в 1970. Очевидна разница в пару лет, но, в любом случае, паскаль был раньше, и потому не мог быть написан на Си.

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

вот тогда и появились структуры ( без них Томсон с его слов фэйлил) и чанки разного количества битов (8 16 32)

я не вполне понимаю, что metaprog понимает под «структурой условного выбора типа» и «типами типов» (типами высшего порядка? зависимыми типами? обобщённо алгебраическими, GADT?), но могу предположить что это GADT с типами-суммами (tagged or disjoint unions) или coproduct type (variant type) или даже типы произведения (кортежи, туплы и записи), хрен его знает, metaprog’а со своей собственной терминологией, и чего он там понимает под «циклом по СУВТ» и зачем (имхо, ему нужна какая-то интроспекция и рефлексия по этим destructuring-bind DCL 1 ALLSTRUCT, 2 onefield, 2 secondfield, 2 thirdfield полям: foreach field in (onefield,secondfield, thirdfield) и желательно CTFE, конечно же.

или ему достаточно в духе WinAPI структур где первое поле sizeof всего, а потом заалиасено с union, и бесконечного размера запись, отреж «догадайся мол сама» сколько вешать в граммах, «условно выбирая тип» по содержимому первого поля с размером (это что за тип теоретически правильный? disjoint union или coproduct, variant type)?

но и так понятно что осилить корректную типизацию структур заалиасенных, да ещё с транзитивностью указателей (например, с транзитивностью иммутабельности в D заместо нетранзитивной константности в C++) могут не только лишь все.

мало кто корректно это может делать.

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

история ваще клёвый жанр литературы.

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

пустой ниши - скажем аккуратно не было

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

у Томпсона в интервью Кернигану зарисовка как из драйвера к быстрому «hdd»-вентилятору-вертикальному «самозародилась» UNICS с оверлеизацией пользоватальской реализации языка разработки

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

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

в последнем абзаце очень ексСССР точка наблюдения

в первой половине 80ых системный софт писался больше на Паскаль-языках ( Ада +- в этом поддереве) как ни очевидно

С форм Пиндосия Pascal from даже не страна Нато

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

Граф

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

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

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

как в монти пайтоне монахи святого грааля – эдакое долбославие

anonymous
()
Ответ на: "типизированнный" С, ну как же, лол от anonymous

если прослеживается линия наследования идей, C > B > BCPL > дальше сложно, ну хоть тот же PL/I, и компилятор компиляторов TMG, например

Она намного сложнее. Каждый отдельный разраб тянул попавшиеся под руку идеи в свои разработки, а в каждом проекте разработчиков часто было больше одного. Это в алголе 60, паскале, C можно еще разобраться по показаниям свидетелей, а с комитетными поделиями это гиблое занятие, потому можно даже не поднимать этот вопрос.

вот в том же PL/I, например, сделано правильно – указатели типизированные. и через DCL 1 W , 2 X, 2 Y, 2 Z можно заалиасить union: W структуры и X,Y,Z desctructuring-bind из отдельных полей, в совокупности одинаковых со структурою размеров

Как минимум в паскале то же есть. Наследованию структур это не помогает, однако.

так что С как бы «типизированный». и как бы нет – в смысле указатели не типизированные-то, и автоматически приводятся к совместимым по присваиванию типам, к тому же указателю на void, например. ещё по историческим причинам этот косяк из B и BCPL тянется

Это тянется с ассемблера, вообще-то.

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

сорян за.

есть «Хроники Дебила» и сиквелы

в сиквелах два исходных героя-товарища известны как добрый Герой и его архивраг злодей Шаман.

Си и Паскаль и Форт и Смолток и вагон ещё интересных творений эпохи ~1970-~1975 гг ….

о чём информирует утверждение @Паскаль не мог быть написан на Си ибо Си позже@

наряду с очевидной истиностью - истина .

о ценности (с точки утверждающего) реализации Паскаля на Си

в песках времени есть реализации Си на Паскале кстати.

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

у Си против Паскаля было несколько преимуществ за рамками программирования как такового

Поясни.

пустой ниши - скажем аккуратно не было

Ну и какая же альтернатива была, кроме асма?

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