Да и в Pure C возможно писать практически не используя указатели. В чем разница?

В Pure C нет ссылок. Изменение объекта в функции только по указателям. Да и почему мы вообще о Pure C говорим? У ОПа четка написанно сравнение с C/C++ и указан еще Lazarus. Pure C имхо вообще мало применимая вещь на сегодня (для прикладных вещей). Либо эмбеддед, либо системное программирование, либо легаси. Для современных вещей есть С++ или вообще java/C#/python/etc.

Первый - набор промышленных костылей, который почему то приняли за язык. Второй - красивый и лаконичный промышленный язык.

Толсто ж. Давай перечисли костыли в С++

http://lurkmo.re/I

У меня не открылось, но я по ссылке понял что там. И чо? Это чуть ли не в первых главах K&R расписанно. Только полный говнокодер не знает как это работает. Правила очень четкие и однозначные. Где неочевидность?

Сколько строчен надо для сборки реальной программы на C?

Тебе в реальной программе на Си надо указать очень много чего и все нужно и оправданно, там нет ни одной опции без которой можно было бы обойтись. Либо давай в примерах, какие опции для gcc/g++/vc не нужны?

Наверное зря пацаны рассматривают возможность добавления модулей в С++17, зряя... (это был сарказм)

Да он скажет, что это очередной костыль и для рукожопов, а в «красивом и лаконичном промышленном языкe» это не нужно.

fpc {всякие разные опции, если надо} main.pas

То что модулей не хватает это факт. Но в данном случае механизм gcc позволяет делать статическую линковку с obj файлами полученными со стороны. Каким образом сделать статическую линковку с слевой либой в паскале? При этом что б строчка компиляции не изменилась почти и не изменялся код. Слушаю.

Только полный говнокодер не знает как это работает. Правила очень четкие и однозначные. Где неочевидность?

Ты точно про «i = ++i + ++i» говоришь?

Ты точно про «i = ++i + ++i» говоришь?

Ааа, я не понял. Я думал там просто про разницу ++i и i++. Это вообще по сути использовать нельзя. Вообще. Тебе запретили юзать такое. Зачем пытаться?

Напоминает людей которые использовали memcpy для пересекающихся буферов, хотя это явным образом запрещенно. А потом стали ругать авторов glibc, когда те порядок копирования запретили. Если ты нарушаешь контракт, то кто тут виноват то?

Тебе запретили юзать такое. Зачем пытаться?

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

Язык-то не запрещает, да и компилятор может ничего не сказать

Изменение одного объекта более одного раза в одно точке следование - UB

Надо так писать. Учитесь ЛОРовские флудеры.

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

Pascal — это элитный евроязык. Первый Паскаль разработал учёный человек из Цюриха. Pascal хвалят академики.

Оберон, по-сути диалект Паскаля используют, тихо тссс в российской оборонке. На европейском истребителе стоит прога написанная на Компонентном Паскале. Си-подобные языки используют в Винде, где вы регулярно видите «синий экран смерти.»

Каким образом сделать статическую линковку с слевой либой в паскале?

Элементарно.

С либой: http://www.freepascal.org/docs-html/prog/progsu46.html
С объектником: http://www.freepascal.org/docs-html/prog/progsu43.html

Именно! Только вот в Си неважно что у тебя свой объектник (из другого .c) или сторонний, или статик либа.

Не совсем так. Формат библиотеки/объектника должен совпадать, соглашение о вызове должно совпадать, манглинг должен совпадать.
От Watcom-а отсыпать объектников/библиотек?

А в паскале не должны?=)

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

Так я и намекаю толсто, какая разница, если на онтопичной платформе линкер один и тот же?
А вот Watcom C тоже Си, а поди ж ты :-)
Может в этом вопросе и не в языке вовсе дело?

Тут также. См. ключики -Fo, -Fl.

Так я и намекаю толсто, какая разница, если на онтопичной платформе линкер один и тот же?

В единообразие использования?

Так а в чем разница, если это не компилятора вотчина, а линкера?

Оберон, по-сути диалект Паскаля

Тут еще про аду не хватает пары страниц :)

А вот Watcom C тоже Си

Sybase убила ватку в 2003-м в пользу поварбилдера. «отдав в опенсорц», конешно.

Stable release 1.9 / June 2, 2010;

Это крайняя опенватка.

Open Watcom supports partial compatibility with the C99 standard.

«Шел 2016 год» (с)

С11 нет, x64 нет, «STLport»«нетЪ!»(с) Мсье знает толк в труположестве :)

Изменение одного объекта более одного раза в одно точке следование - UB

А теперь почитай внимательнее то, на что отвечаешь.

Просто у него манглинг весьма специфичный, до сих пор помнится :-) хоть и времени сколько прошло...

Тут еще про аду не хватает пары страниц :)

Спасибо, вот только мы в МакДоналдс не ходим.

Нененене, чо из песни слова выкидывать. Сказали уж про «диалект»

А теперь почитай внимательнее то, на что отвечаешь.

Ну про i++ + ++i все знают.

Короче, если нужен один серьёзный проект одним бинарным файлом по принципу «всё своё ношу с собой», то Freepascal очень неплох (вплоть до того, что в большинстве случаев можно будет обойтись безо всего - даже без libc и libm).

И это скорее «+», нежели "-".

Сложно сказать. Смотря для чего. Если для создания единственного проекта с единственным исполняемым файлом (или же чего-то на уровне busybox, т.е. всё в одном, но надо вызывать по-разному), то оно самое то (если, конечно, всякой ненужной ерунды в исполняемый файл не войдёт). Если же для создания набора мелких утилит, каждая - в своём отдельном исполняемом файле (кстати, unix-way), то однозначно минус. Да, его можно обойти (если вклиниться между компиляцией и компоновкой), я даже набросал кое-что, но оно никому не интересно. Ветка с пакетами (то же, но без хаков) уже больше года как висит без дела в не особо рабочем состоянии.

Опять же - решаемо. А тай - OpenSource, запили штатное средство, раз тебя так напрягает. Люди спасибо скажут.

Только ответил.

Сложно сказать. Смотря для чего. Если для создания единственного проекта с единственным исполняемым файлом (или же чего-то на уровне busybox, т.е. всё в одном, но надо вызывать по-разному), то оно самое то (если, конечно, всякой ненужной ерунды в исполняемый файл не войдёт). Если же для создания набора мелких утилит, каждая - в своём отдельном исполняемом файле (кстати, unix-way), то однозначно минус. Да, его можно обойти (если вклиниться между компиляцией и компоновкой), я даже набросал кое-что, но оно никому не интересно. Ветка с пакетами (то же, но без хаков) уже больше года как висит без дела в не особо рабочем состоянии.

Иными словами всё можно сделать, если понимать матчасть, чтд.

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

Такой язык как Pure C портят не «макры», а прокладка между клавиатурой и стулом. Ни разу ничего не портило. Как вы их используете - это вопрос, который и является корнем зла.

Потому что есть модули. Это сразу и описание файла (некий аналог include) и код. Причём модуль более или менее целостный. Зачем нужны паровозы, когда есть тепло- и электровозы? Хотя да, иногда необходимость есть. Но, как правило, отнюдь не для связывания других кусков.

И что вам это даст в Pure C? Да и вообще, хотя бы откройте Wiki: Мо́дуль — функционально законченный фрагмент программы. Во многих языках (но далеко не обязательно) оформляется в виде отдельного файла с исходным кодом или поименованной непрерывной её части. Некоторые языки предусматривают объединение модулей в пакеты. Иными словами, файлы подключаемые через инклюд тоже можно назвать модулем. А вот то, что вы описали - просто один их подходов.

Что практически невозможно в паскале. Хотя да, если специально постараться, может что-то и получиться.

Так вы так и не назвали внятной причины ненависти к include. Вы случаем не PHP-шник? Они обычно так себя ведут и не любят «инклюды», т.к. в их языке они могут доставить проблем, т.к. они все криворукие макаки.

Не только. Можно, например, { и } на begin и end заменить. Но это так, для интереса.

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

http://lurkmo.re/I

Вот и дожил. Lurk кидают как справку по тому, что хотят сказать. Можно все же изложить проблему?

А нужна ли эта масса ключей? В Паскале почти все ключи дублируются директивами компилятора. Если, всё-таки, эти ключи нужны - то хватит одной строчки скрипта, начинающейся с FPC. Сколько строчен надо для сборки реальной программы на C?

Понятно, так и запишем - человек не может осилить компилятор.

Кстати, в том же Delphi ключи компилятора dcc далеко не всемогущи. Например, подключить пакеты через ключи dcc - нетривиальная задача (если это вообще возможно).

Я промолчу, просто оставлю это тут (http://www.delphiplus.org/articles/delphi/use_bpg_for_batch_compilation.html) - если правильно понял задачу.

Допустим, есть проект в одном каталоге с десятком файлов кода (не включая заголовки). В С - функция main находится в одном из них (main.c). В паскале - аналогичный (main.pas) начинается с program, остальные - с unit. В паскале достаточно

fpc {всякие разные опции, если надо} main.pas
В gcc
gcc {общие опции} -c u1.c
gcc {общие опции} -c u2.c ...

В чем сложность я так и не увидел. Разные функции инструмента. Ну напишите на bash обёртку, чтобы было как в FPC. Я так собственно во времения сидения на Pure C и сделал.

Да, это очевидно, но если почитать тему, то не раз и не два невозможность собрать проект одним gcc считался за недостаток.

Среди кого? Вот я написал не так давно сложный генератор последовательности чисел на списках на Python3.5, т.к. есть библиотеки под него - он будует запускаться только под Python3.5. И это во всём адекватном мире считается нормой. Только аналитики ЛОР'а считают иначе.

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

Извините, конечно. Но проект (если не брать ЯП, а взять С++) на Qt будет весить тоже много. Delphi и Lazarus тянут за собой фреймворк. Pure C не тянет ничего. Вот и все. А так - можно в того же Delphi отключить вообще всё, тогда исполняемый файл будет не большой.

В С++ почти все указанные проблемы просто неактуальны. Есть умные указатели, множество контейнеров, исключения, свои потоки ввода вывода (хотя вот они то и говнецо, printf лучше). Я работая на С++ работаю с указателями КРАЙНЕ редко. Оно здесь не надо.

А при чем тут указатели, контейнеры, исключения, пототки и т.п.? Я об ООП говорю, по Алану Кею. Всё перечисленное - набор костылей и велосипедов, которые «качественно отличают С++ от Pure C».

В заголовочном сообщение автор явно сравнивает с C/C++, прямым текстом. Значит надо писать на С++, а не на Си. И приводить аргументы про указатели и \0 завершающиеся строки просто глупо.

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

Далее - процитирую автора: «Итак, если всё вместе - начнём с недостатков С». Если человек не умеет формулировать свои мысли - это печально. Это мне напоминает старый анекдот, когда парень сказал привет, а девушка уже решила что он ее послал на хутор бабочек ловить. И вы такую безграмотность оправдываете. Понимаете ибо, такой же образ мышления. Нельзя говорить, скажем язык Модула, а иметь ввиду Oberon.

В заголовочном сообщение автор явно сравнивает с C/C++, прямым текстом. Значит надо писать на С++, а не на Си. И приводить аргументы про указатели и \0 завершающиеся строки просто глупо.

Ты стебешься? Серьезно не понимаешь чем плохи инклуды? Наверное зря пацаны рассматривают возможность добавления модулей в С++17, зряя... (это был сарказм)

Нет, не стебусь. Я не понимаю, чем инклюды при правильной геометрии рук могут помешать человеку. А посонам передай зря С++17 пилят - он не нужен.

А при чем тут указатели, контейнеры, исключения, пототки и т.п.? Я об ООП говорю, по Алану Кею. Всё перечисленное - набор костылей и велосипедов, которые «качественно отличают С++ от Pure C».

Так вроде везде такое ооп и в java и в c#, а о языках которые никому не нужны, пожалуйста, не надо.

Я не понимаю, чем инклюды при правильной геометрии рук могут помешать человеку.

Ясно-понятно. И выше никакой конкретики, одно лишь слово «костыль». Ты реально надеешься на адекватные ответы сам таковых не давая?

«Каждый москаль любит Паскаль, а мы уси пишем на Си»

ps ответ стар и совершенно очевиден

Delphi и Lazarus тянут за собой фреймворк.

Да, но дело не только в нём. Один System тянет уже немало. А если подключить Classes, откуда хорошо если берётся десятая часть, то размер Hello, World вырастет до 200-300 Кб. Безо всякого фреймворка LCL.

Далее - процитирую автора: «Итак, если всё вместе - начнём с недостатков С».

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

Такой язык как Pure C портят не «макры», а прокладка между клавиатурой и стулом. Ни разу ничего не портило. Как вы их используете - это вопрос, который и является корнем зла.

Лично я - преимущественно адаптируя имеющийся код (или его кусок) к чему-то. Вот тут - портит, и ещё как. Понятно, что если автор внимателен (не про меня), усидчив и делает всё для достижения своей цели (но не для дальнейшего использования), ему «ни разу» ничего «не испортит». А вот на слегка отличающейся платформе... Или если надо найти, чего-таки этому макросу (ну пусть недомакросу) не хватает (всего лишь для сборки)... Увы, задача отнюдь не такая простая.

Иными словами, файлы подключаемые через инклюд тоже можно назвать модулем. А вот то, что вы описали - просто один их подходов.

Назвать можно что угодно чем угодно. По сути, include + .o (или кусок .a/.so/.dll) - это аналог более или менее цельного модуля (пусть он даже включает два файла - но один явно связан с другим). Но это при условии, что всё линкуется идеально правильно. А до стадии линковки (до которой может пройти десяток машин и пользователей) - это две совершенно несвязанные (кроме мозга программиста, инструкции, которой обычно нет, и правил сборки, которые могут легко нарушиться, а могут быть ещё не написаны) вещи. И если одно не соответствует другому... Короче, тут всем ясны последствия.

Вы случаем не PHP-шник? Они обычно так себя ведут и не любят «инклюды»,

Честно - нет. Паскалист-любитель, а с 99-го - и линуксоид-любитель. Что потребовало минимального понимания языка С. И неоднократных попыток «гибридизации» результатов компиляции (впрочем, застал я и p2c). Других языков - ну, кроме, разве что, примитивного интерпретатора бейсика (не путать с VB) и совсем из детства - мнемокода i8080/КР580 (успешно уже забытого, кроме, может что JMP это C3, CALL - это CD, а RET - С9 - или уже я и это забыл?) - я не знаю.

Опять же - никаких аргументов по пункту.

#include <stdio.h>

#define c 5*

void main(){ int i=10;

printf(«%i \n»,c+i);

}

Допустим, я просто хотел определить константу, но в конце сточки #define я «случайно» (впрочем, мог бы и на самом деле случайно, я вот такой) поставил звёздочку. Если бы я подобное сделал в Паскале (const c=5*;), компилятор бы поругался только так. А что в Си? Компилятор даже не заикнулся! Зато результат вычислений весьма впечатляет. Или такой пример нереален? Так усложните код - и он вполне станет реальностью.

Понятно, так и запишем - человек не может осилить компилятор.

Зачем его «осиливать»? Его просто и банально надо использовать. Не знаю, как другие, а FPC просто отталкивает от использования ключей, кроме как для конкретной задачи. Почему? А потому, что, по большому счёту, свой набор ключей нужен каждому модулю (их же могли писать совсем разные люди). А компиляция часто идёт не по модулям в отдельности, а по файлам. Нет, конечно, -dRELEASE - это можно и нужно, но вот -S2 уже лучше не делать, а вставить {$mode objfpc}. Потому как отдельным модулям может понадобиться и -Sd (или {$mode delphi}).

Я промолчу, просто оставлю это тут

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

В чем сложность я так и не увидел. Разные функции инструмента.

Да, разные. Только строк во втором случае больше. Значительно. А bash-скрипт надо писать каждый раз свой (ну нет, можно, конечно, собрать *.c в один бинарник, но где гарантия, что все они нужны и вообще сочетаемы? А что ещё к ним надо прилинковать из стандартного? А если код писался давно или кем-то другим?). В паскалевской программе (без наворотов) 1 файл, начинающийся с program = 1 строка для компилятора. А в путях может быть что угодно, кроме разных исходников с одинаковыми именами.

Посмотрел я на этот ваш Оберон  — полупустые дублирующие друг друга страницы, дохлые FTP-сервера, какие-то кривые вендосборки в лучших традициях ZverCD, а в заголовках документов гордо красуется «Microsoft Word Document». Короче говоря, воздух пропитан густым запахом дауншифтинга и импортозамещения.

Оберон, по-сути диалект Паскаля используют, тихо тссс в российской оборонке.

Oberon-07М бесплатен для некоммерческого использования. Для использования в коммерческих целях необходимо приобрести лицензию, которая стоит 250 рублей для каждого разработчика.

http://exaprog.com/rus/licence.html

Вот этот чудик, видимо, там и пишет. За 250 рублей, лол.

Да, но дело не только в нём. Один System тянет уже немало. А если подключить Classes, откуда хорошо если берётся десятая часть, то размер Hello, World вырастет до 200-300 Кб. Безо всякого фреймворка LCL.

0. Сегодня это не аргумент. Жесткие диски большие, размер мало значения имеет, особенно для прикладного ПО. 1. Можно свести программу к минимуму, используя только работу с памятью.

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

Просто аналитик ваших ответов - не делает как я понял различий между Pure C и C++. Ваши аргументы относятся к Pure C (как понял по контексту), о чем я и сказал.

Лично я - преимущественно адаптируя имеющийся код (или его кусок) к чему-то. Вот тут - портит, и ещё как. Понятно, что если автор внимателен (не про меня), усидчив и делает всё для достижения своей цели (но не для дальнейшего использования), ему «ни разу» ничего «не испортит». А вот на слегка отличающейся платформе... Или если надо найти, чего-таки этому макросу (ну пусть недомакросу) не хватает (всего лишь для сборки)... Увы, задача отнюдь не такая простая.

Тут слогасен, но это скорее проблема - как я и говорил прокладки, программиста. Или даже экосистемы, т.к. макросы в Pure C у меня оставили впечатление, что они предназначались лишь для повышения удобства (там где хочется) и подстройки вариаций кода под платформы. Некие глобальные if'ы уровня платформы для компилятора).

Назвать можно что угодно чем угодно. По сути, include + .o (или кусок .a/.so/.dll) - это аналог более или менее цельного модуля (пусть он даже включает два файла - но один явно связан с другим). Но это при условии, что всё линкуется идеально правильно. А до стадии линковки (до которой может пройти десяток машин и пользователей) - это две совершенно несвязанные (кроме мозга программиста, инструкции, которой обычно нет, и правил сборки, которые могут легко нарушиться, а могут быть ещё не написаны) вещи. И если одно не соответствует другому... Короче, тут всем ясны последствия.

Ну а что тут сказать, в целом оба файла - принадлежат к одной экосистеме. А вы рассматриваете случай когда нечто выдрали с экосистемы и теперь удивляетесь почему оно не работает. Если взять Java-класс и отодрать его от JVM с попыткой завести без последней - то он тоже будет непонятно чем и не понятно зачем нужен.

Честно - нет. Паскалист-любитель, а с 99-го - и линуксоид-любитель. Что потребовало минимального понимания языка С. И неоднократных попыток «гибридизации» результатов компиляции (впрочем, застал я и p2c). Других языков - ну, кроме, разве что, примитивного интерпретатора бейсика (не путать с VB) и совсем из детства - мнемокода i8080/КР580 (успешно уже забытого, кроме, может что JMP это C3, CALL - это CD, а RET - С9 - или уже я и это забыл?) - я не знаю.

Тогда понятно, претензий к незнанию матчасти нет. А что побудило заняться пограммированием? И почему именно паскаль? И linux=) Паскаль под виндами себя чувствовал лучше тогда, все же был Delphi только под оффтопиком.

#include <stdio.h>

#define c 5*

void main(){ int i=10;

printf(«%i \n»,c+i);

}

Допустим, я просто хотел определить константу, но в конце сточки #define я «случайно» (впрочем, мог бы и на самом деле случайно, я вот такой) поставил звёздочку. Если бы я подобное сделал в Паскале (const c=5*;), компилятор бы поругался только так. А что в Си? Компилятор даже не заикнулся! Зато результат вычислений весьма впечатляет. Или такой пример нереален? Так усложните код - и он вполне станет реальностью.

Абсолютно не реален. * как символ имеет в Си особое значение. Поэтому к ней относятся очень внимательно. Как и к define, т.к. баги «макры» ищутся сложнее, дольше - их пишут внимательнее.

Зачем его «осиливать»? Его просто и банально надо использовать.

Нельзя использовать то, что не умеешь использовать. Просто использовать можно для самообучения и то до определенного предела. Чтобы работать с инструментом - надо уметь с ним обращаться.

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

Ну правильно, зачем без повода что-то делать.

Почему?

Т.к. инструмент = задача.

А потому, что, по большому счёту, свой набор ключей нужен каждому модулю (их же могли писать совсем разные люди). А компиляция часто идёт не по модулям в отдельности, а по файлам. Нет, конечно, -dRELEASE - это можно и нужно, но вот -S2 уже лучше не делать, а вставить {$mode objfpc}. Потому как отдельным модулям может понадобиться и -Sd (или {$mode delphi}).

Ну вот, сами говорите о необходимости ключей и сами же их необходимость отрицаете.

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

Это пример, которого вы утверждаете нет, добыт за 30 секунд в яндексе (специально не стал использовать для задачи поисковики, чтобы приравнять вероятность к среднестатистическому рукожопу). Далее - это возможность и OpenSorce. Сделай удобнее, напиши утилиту для LAzarus, авторы которого посчитали это менее необходимым, чем то, что они сейчас пилят. Проблемы так и не увидел.

Да, разные. Только строк во втором случае больше. Значительно.

И что? Это проблема?

А bash-скрипт надо писать каждый раз свой (ну нет, можно, конечно, собрать *.c в один бинарник, но где гарантия, что все они нужны и вообще сочетаемы? А что ещё к ним надо прилинковать из стандартного? А если код писался давно или кем-то другим?).

Напишите скрипт на tcl, он позволит реализовать сложную логику и даже прикрутить без особых туда интерфейс на Tk.

В паскалевской программе (без наворотов) 1 файл, начинающийся с program = 1 строка для компилятора. А в путях может быть что угодно, кроме разных исходников с одинаковыми именами.

Это везде так. Проблемы так и не понял

Вот: https://ru.wikipedia.org/wiki/BlackBox_Component_Builder

И не благодари, анонимус, тут живые сборки, в разделе ссылки

На гите: https://github.com/aixp/BlackBox

Элита. Понты. Все.
Да, не наброс, а вброс, учи матчасть.

Посмотрел я на этот ваш Оберон — полупустые дублирующие друг друга страницы, дохлые FTP-сервера, какие-то кривые вендосборки в лучших традициях ZverCD ... Короче говоря, воздух пропитан густым запахом дауншифтинга и импортозамещения.

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

Oberon-07М бесплатен для некоммерческого использования. Для использования в коммерческих целях необходимо приобрести лицензию, которая стоит 250 рублей для каждого разработчика.

И тут передёргивашь. Конкретно этот компилятор написал россиянин. Вообще, Oberon-07 предназначен только для процессоров ARM-машин.

Oberon-07 надо уважать по той простой причине, что его спецификацию написал самолично Никлаус Вирт.

Почему не принято для Linux писать что-то на FreePascal?

Фигня. Забей. Всё субъективно. Делай как считаешь нужным сам. Никто не знает твою ситуацию лучше тебя. А если кто-то говорит 'фу, да оно же на %name%, нахера ты так сделал' — скажи ему что он мудак, и ты будешь прав.

не технологии делают программиста клёвым, а задачи которые он решает

Pure C не тянет ничего. Вот и все.

glibc - libc.so.6: version `GLIBC_X.YZ' not found :) Совсем ничего, дадад, в идеальном юникс-вее, который протух и нинужен. Одни статик-линкованые ничего эвривер. Токо это ничего для практического использования малопригодно без того ничего, которое оно с собой не тянет.

«Каждый москаль любит Паскаль, а мы уси пишем на Си»

ps ответ стар и совершенно очевиден

Неужто Шевченко?

зря С++17 пилят - он не нужен.

Сказал чувак с «сильвер буллет» в никнейме. Инклуды он не понимает чем плохи, прямизна рук... Тоньше не пробовал?

Нет, не стебусь.

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

зря XXX пилят - он не нужен.

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

Тогда понятно, претензий к незнанию матчасти нет. А что побудило заняться пограммированием? И почему именно паскаль? И linux=) Паскаль под виндами себя чувствовал лучше тогда, все же был Delphi только под оффтопиком.

Ну дадад, Kylix с кроссплатоформенным QLX искаропки ты не застал, в силу возраста или снобизма :) Тогда понятны твои претензии на знание матчасти и одновременно «непонимание проблем». Не взлетело оно по причинам никак не связанным с «комфортом дельфи под виндами». Скорее с упоротостью манагеров Борланда, которые пролюбили рынок и команду Хейлсберга в карты проиграли Майкрософту.

«а мы уси пишем на Си»

Со словами «а мы хохлы пишем на» какое-нибудь слово рифмуется?

На такое способен только тот, кто подрачивает на быдло американских языках, типа: java, си++ и прочее гавно.

╔═══════════════════════╦═══════════════════╗
║ Старая добрая Америка ║ Гнусные европейцы ║
╠═══════════════════════╬═══════════════════╣
║ Fortran               ║ ALGOL             ║
║ UNIX                  ║ Linux             ║
║ С                     ║ C++               ║
║ Dylan                 ║ Python            ║
║ Scheme                ║ Racket            ║
║ Common Lisp           ║ Clojure           ║
║ Tcl                   ║ PHP               ║
║ Tk                    ║ Qt                ║
╚═══════════════════════╩═══════════════════╝

God bless America!