> Но Си вообще непревзойденный эталон языкостроения.

Этому больше не наливать. Колес, травы и прочего - тоже не давать.

> 1) Pascal

Ну епт, вот откуда эта паскалефилия? Люди не читали «Сравнительную оценку языков Си и Паскаль»?

Коллективное бессознательное. Побороть почти нереально.

Люди не читали

Да похрен на эти писания. Программирования штука метафизическая.

Это прям как музыка. Вот sex pistols например, панками необразованными были с улицы, музыка у них примитивная, а революцию в культуре теме не менее произвели.

> Программирования штука метафизическая.

/me .oO( поздно запретили наливать )

ну и статья тоже на вынос, особо доставило вот это:

Охрана = УточнИдент ":" УточнИдент.

Component Pascal и Oberon

Собственно, сабж. Был ли у кого опыт программирования и каковы впечатления. Нужно ли это знать как разработчику?

1. зачем тебе это «знание» нужно? где ты его собрался применять?

2. не нужно это тебе, займись делом, будь прагматиком

3. не слушай фанатиков - это плохо для тебя кончится

>Сравнительную оценку языков Си и Паскаль

Паскаль... Какой паскаль? Где вы сейчас видите стандартный паскаль?

Современные версии паскаля по возможностям мало отличаются от С.

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

Инструмент выбирается по задаче.

Паскаль... Какой паскаль? Где вы сейчас видите стандартный паскаль?

нигде, и, чтобы выражаться конкретно, там ему самое место

Современные версии паскаля по возможностям мало отличаются от С.

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

Инструмент выбирается по задаче.

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

Это прям как музыка. Вот sex pistols например, панками необразованными были с улицы, музыка у них примитивная, а революцию в культуре теме не менее произвели.

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

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

>надёжности, стоимости, читабельности и др. критериях, где использование C бесперспективно.

читабельности

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

надёжности

Ололо, и давно это с ним? Корректность программы на Паскале можно доказать математически? Нет? Значит он ничем не надежнее Си.

стоимости

Единственный верный аргумент. Студенты-программисты «со знанием Delphi» стоят действительно дешевле нормальных программистов Си.

и др. критериях

Озвучьте же и др. критерии.

>>надёжности

Корректность программы

А причем тут математическая корректность программы? Ваши С-шные поделия сегфолтятся на ровном месте, будь они трижды правильные.

стоимости

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

И кстати, Free pascal компилятор - православного gpl, GNAT - вобщем-то тоже.

Озвучьте же и др. критерии.

Успешность

> С-шные поделия сегфолтятся

Что ж вы тогда делаете на этом форуме? GNU/Linux, BSD и QNX не существуют, потому что если бы они существовали, они бы сегфолтились на ровном месте каждые 5 минут и стабильно раз в час вылетали в kernel panic.

С-шные поделия сегфолтятся на ровном месте, будь они трижды правильные

У вас Паскаль головного мозга. Правильная программа не может сегфолтиться. По определению.

стоил б побольше, чем вся ваша экономия на лицензиях.

Простите, на чем? Теперь оказывается, что Сишники экономят на лицензиях. На лицензиях чего? Вы уверены, что вы с планеты Земля?

системы управления пишут не на С

Погуглите RTOS. Посчитайте реализованные на Си. Посчитайте реализованные на Паскале.

Успешность

Вы существуете в параллельной реальности. Счастливо там и оставаться.

> Необязательно пользоваться GCC. Есть другие компиляторы, например, pcc (portable C compiler) и tinycc, оба вроде на порядок быстрее gcc.

Подозреваю, что качество генерируемого кода страдает. Там что-то фатальное на вроде #include.

> У меня два языка выбора для кросс-платформенной разработки - это С и Common Lisp. Для винды также очень хорош Дельфи.

Здесь необычен только лисп.

Common Lisp безусловно интересная штука, но под него должна быть задача. Хотя я тут на днях узнал о сложной GUI-шной программе InspireData, целиком написанной с использованием LispWorks. Внушает трепет. Как я понял, программу написала та контора, которая разрабатывает Clozure CL. Заявляется, что InspireData - самое крупное приложение, написанное когда-либо на Common Lisp.

> Скалу не пробовал? Или Окамл, на худой конец.

Пробовал Скалу и F#.

По Скале. Как-то задалбывает искать доки по методам коллекций. А всё типажи (traits), из-за которых наследуется реализация. Непонятно выглядят Iterator и Iterable примерно с одинаковым набором методов. Перебор.

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

Теперь по Окамлу. Мне очень не хватает в стандарте вычислительных выражений как в F#. Что-то непонятное со сборщиком мусора на многоядерных процессорах. Необычное ООП.

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

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

:lol: когда Вы уже закончите детский сад в котором Вас учат (?) читать и таки осилите прочитать что я Вам говорил то Вам персонально, смею надеяться, станет ясно что я нигде не аргументировал за использование си, я лишь указал что Вы бессвязно выражаете мысли

и да, Вы правы - паскаль куда более деревянный язык чем си, а когда мне надо будет надёжность и читаемость я возьму яву, в оставшихся 0,5% случаев я буду использовать ada или tcl :)

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

А причем тут математическая корректность программы? Ваши С-шные поделия сегфолтятся на ровном месте, будь они трижды правильные.

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

Ну, тогда пример языка с хорошим дизайном - в студию.

* ooc

* crack презентация

* D, внезапно. Дизайн неплохой, проблемы с реализацией инструментария и «2 версии всего».

* Vala

* Nimrod

Почему я считаю дизайн этих языков хорошим? Потому что у любого языка будет как минимум одна главная проблема, проблема раскрутки, курицы & яйца, проблема bootstrapping-а. Есть язык, весь такой из себя замечательный. И есть правильные библиотеки и программы, на этом языке, и неправильные (на любом другом языке, начиная с Си). То есть, нужен какой-либо FFI. Почему он нужен? Потому что виртуальная машина языка, реализованная либо в его компиляторе в нативный код, либо в интерпретаторе (если он есть) сильно разная, сильно отличается от стандартной си-машины: соглашениями вызова функций, представлением значений, ссылок, типов, используемым набором абстракций (вроде функции/классы и методы/дженерики и интерфейсы). То есть, FFI нужен для взаимодействия с Си машиной. На нём описывается обёртки, транслирующие чужие Си-соглашения в родные. То есть, нужен маршалинг данных из чужих Си в родные и наоборот, и API обёрток, желательно, сгенерированный автоматически из Си-функций.

В этих языках такие обёртки не нужны. FFI не нужен. Потому что языки транслируются прямо в Си, либо своим компилятором, либо через LLVM. И прозрачно линкуются с уже готовыми Си-библиотеками: в D есть import c.stdc.*, линковка с Си ABI, в Crack: import из C хедеров, остальные транслируются в Си, позволяя вызывать сишные функции прозрачно (для Nimrod, емнип, нужны минимальные обёртки).

Есть, правда, виртуальная машина SEAM из Alice/SML, с правильным дизайном: дюже абстрактная, и в неё можно плагинами подключать что различные GC, что FFI/соглашения вызова, что произвольные языки (виртуальная машина языка может быть реализована как плагин SEAM).

То есть, такой вот критерий «правильности дизайна» : виртуальная машина языка, реализованная в интерпретаторе или в компиляторе — правильная, если в неё прозрачно втыкается любая Си библиотека, и код на этом языке и код на Си линкуется легко и единообразно.

> BlackBox поддерживает модель графического интерфейса, основанную на составных документах, состоящих из объектов-контейнеров, различным образом комбинирующие в себе иерархию других графических объектов. Если говорить по-простому - это редактируемый GUI/он-же_тулкит с неограниченной вложенностью графических объектов.

это что, что-то вроде Compound document в Win32 API? формат бинарный? как у него с расширяемостью, сериализацией (что нужно сделать для поддержки сериализации своих данных?)

Что-то мне подсказывает, реализация такой простой штуки как подсчет факториала будет на обероне сущим кошмаром.

То есть, такой вот критерий «правильности дизайна» : виртуальная машина языка, реализованная в интерпретаторе или в компиляторе — правильная, если в неё прозрачно втыкается любая Си библиотека, и код на этом языке и код на Си линкуется легко и единообразно.

тогда называем Lua и все Ваши примеры идут курить бамбук

в Lua уже есть cover из ooc, AST макросы из Nimrod, и что-то помимо метатаблиц для расширения?

в Lua уже есть cover из ooc, AST макросы из Nimrod, и что-то помимо метатаблиц для расширения?

для невнимательных и непомнящих:

То есть, такой вот критерий «правильности дизайна» : виртуальная машина языка, реализованная в интерпретаторе или в компиляторе — правильная, если в неё прозрачно втыкается любая Си библиотека, и код на этом языке и код на Си линкуется легко и единообразно.

с чего Вы теперь дополнительные требования вводите?

>Что-то мне подсказывает, реализация такой простой штуки как подсчет факториала будет на обероне сущим кошмаром.

Факториал.

>в Lua уже есть cover из ooc, AST макросы из Nimrod, и что-то помимо метатаблиц для расширения?

У Nimrod есть «cover из ooc»? Или хотя-бы треды? Или у ooc есть «AST макросы из Nimrod»? Если язык (ну да - «реализация») компилируемый - он может не отставать от си более чем в два раза? А если интерпретатор (даже байкода внутри вм) - язык может быть гибче чем tcl / lua и с jit-ом?

треды в Nimrod есть: http://force7.de/nimrod/posix.html#1010 , при этом есть AST макросы: http://force7.de/nimrod/macros.html http://force7.de/nimrod/tut2.html#macros
Батареек вообще много: http://force7.de/nimrod/lib.html
Язык компилируется через Си (можно и наоборот, делать Си из Nimrod: http://force7.de/nimrod/c2nim.html)
FFI расширяемый и более удобный: http://force7.de/nimrod/manual.html#foreign-function-interface

но FFI в Nimrod всё равно пока ещё нужен — предоставить своё API с маршаллингом. Поэтому круче такое FFI, где маршаллинг не нужен из-за того, что код на языке транслируется в прозрачный код на Си и прозрачно линкуется си компилятором.

«cover из ooc» https://github.com/nddrylliog/the-ooc-language/blob/master/covers-vs-classes.md — это что-то вроде интерфейсов в Go. Аналогичное классам, но гибче.
Вот ooc уже ближе к «правильному FFI», чем Nimrod. Обёртки в основном делаются для covers, а си функции можно вызывать и просто так.

Если язык (ну да - «реализация») компилируемый - он может не отставать от си более чем в два раза?

а он отстаёт? Суть в том, что что ooc что Nimrod транслируется в си, и работает с сопоставимой с си скоростью, но с более вкусными фишками

А если интерпретатор (даже байкода внутри вм) - язык может быть гибче чем tcl / lua и с jit-ом?

как связано интерпретатор/компилятор/jit и гибче/не гибче? одно от другого не зависит. В каком смысле гибче? Гибче может быть, да.

это не дополнительные требования, это прямые фишки языка, cледующие из его спецификации (covers в ooc, AST макросы в Nimrod).
И эти фишки должны прозрачно применяться не только для родного кода, но и для чужого Си кода. То есть код на языке и на Си должен быть взаимозаменяемым, с учётом всех фишек языка.
А вот применение метатаблиц для эмуляции ООП в Lua — это уже костыль рантайма Луа, а не фича языка Lua.

> Если язык (ну да - «реализация») компилируемый - он может не отставать от си более чем в два раза?

может. Тут вопрос, почему реализация тормозит по сравнению с си, и где она тормозит. Если делаем к примеру микробенчмарк с фибоначчи, засекаем время, то такой бенчмарк по операциям делает вызов функции,ветвление, сравнение с хвостом рекурсии, вычисление N-1, N-2, сложение. Тормозит какая-то операция из этих, из-за того, что в одном случае (Си) это обычные unboxed значения, cdecl соглашения, сравнение с нулём, а в другом — это примитивы виртуальной машины языка. Тормоза где-то в реализации такой виртуальной машины.
Поэтому, когда код прозрачно транслируется в примерно то же самое, что собрал бы и си компилятор (т.е., примитивы не очень сложны) тормозов должно стать меньше.

А если интерпретатор (даже байкода внутри вм) - язык может быть гибче чем tcl / lua и с jit-ом?

дело не просто в том, что гибче. А в том, что такая гибкость должна стоить дёшево с точки зрения примитивов.

это не дополнительные требования

для танкистов прямыми словами - эти требования Вы не заявляли и вот внезапно они у Вас всплыли - какого болта?

это прямые фишки языка, cледующие из его спецификации (covers в ooc, AST макросы в Nimrod).

bah-blah-blah, об этом Вы не упоминали и нечего теперь в кусты смотреть и ждать оттуда поддержки

То есть код на языке и на Си должен быть взаимозаменяемым, с учётом всех фишек языка.

это ещё что за новости? снова дополнительные условия?

А вот применение метатаблиц для эмуляции ООП в Lua — это уже костыль рантайма Луа, а не фича языка Lua.

спасибо, я уже понял что чукча не писатель :) это гигантская фича языка Lua, и применяется она не только для «эмуляции ООП» FYI

Факториал.

Прости меня, но это не факториал, а жалкие потуги школьника его написать.

Сразу две проблемы:

* На лицо переполнение стека.

* Но скорее всего, раньше этого кончиться разрядность несчастного LONGINT.

Незачет, в общем. А вот на Си это пишется легко и непринужденно.

покажи... :)

Вы хочете читабельности? Выбирайте LOLCODE!

Вы хочете идеально спроектированный язык? Вам нужен HQ9+!

Мне интересно какой выход придумает наш компонентпаскалевец. Мой же код будет подсказкой.

>* На лицо переполнение стека.

* Но скорее всего, раньше этого кончиться разрядность несчастного LONGINT.

Дык, это был пример типовой для любых языков.

Для тех, кому мало стандартных возможностей, есть Библиотека компонентов:
Lib - Engineering & Scientific library
Maths - Arithmetic Precision
Maths - Calculations
Maths - Formula Drawing & Writing
...
А для «си-гурманов» есть даже ручное управление выделяемой памяти: UtilStorage.

>Мне интересно какой выход придумает наш компонентпаскалевец.

Я рекурсию применяю редко, итерация - «наше всё!»
P.S. И в жизни факториал «нинужын» (c) :)

Цитатка

Very often programmers and language translators are not the same person. This is easier for doing the translation outside the BlackBox in an Excel table. CpcLangMapper allows you to transform rows of alias/language pairs from Excel tables into a BlackBox (Subfolder)Strings.odc document or vice-versa. CpcLangMapper enhances the possibilities of CpcLanguageCpc by introducing transformation of languages between MS Excel and BlackBox.

Закапывайте.

Чорт, сходу не нагуглил.

Удивительно, я думал какой-нибудь FFI будет, а тут всё свое. Кому-то CP действительно очень нужен.

Ух-ты, про *print-case* не знал. Вот ведь ламер я, а :-) А жизнь-то налаживается!

> повешенный на предвыделенную память менеджер кучи со сборкой мусора

(в рамках системы навигации) великолепно показывает себя на железе с > требованием мягкого RT

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

>ooc
Очередной Go? Нахуя?

crack

название говорит само за себя

D

Дизайн говно. «С++ с нормальным дизайном» по определению не может быть «с нормальным дизайном». Потому, что «С++». Авторы - просто наркоманы-экспериментаторы(хотя, правильнее сказать, просто наркоманы). Один Александреску чего стоит.

Vala

У этого недо-C# дизайн хороший? Ну, всмысле, охотно соглашусь, что не настолько плохой, как у полноценного C#. Но, блядь!

Nimrod

Это вообще пиздец. Что-то невнятное и с паскалевским синтаксисом. Чем оно лучше лиспа? Паскалевским синтаксисом? Или там очередная ебанутая на всю голову реализация «типизированного» AST? А, что? Efficient? А если с SBCL сравнить?

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

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

Неправда, Хаскель очень нужен

Вы уже осилили погуглить блоки Ruby?

http://webcache.googleusercontent.com/search?q=cache:Vcre6VRWapgJ:oberoncore....

У меня просто нет слов. И ЭТО еще называется «текстовый формат».

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

>треды в Nimrod есть: http://force7.de/nimrod/posix.html#1010

не унифицированы между разными ОС - самому писать? Или можно под офтопиком pthreads использовать? Я не про абстрактную возможность - я про готовый функционал. На счёт pthreads в posix - я увидел только базовую поддержку библиотеки. Что на счёт колбэков в нимрод из разных тредов - работает? Как вообще на счёт safe-кода - всем стандартным библиотекам можно доверять? И да, их не так уж и много.

«cover из ooc»

ну т.е. в нимроде нет - т.е. либо «интерфейсы», либо «AST-макросы»

Суть в том, что что ooc что Nimrod транслируется в си, и работает с сопоставимой с си скоростью, но с более вкусными фишками

ECL тоже транслируется в си - в результате тормозит не то что больше си, а и больше sbcl, а со сборкой со всеми библиотеками рантайм у него практически как у sbcl получается. Так что «не доказательство»

как связано интерпретатор/компилятор/jit и гибче/не гибче?

«элементарно, Ватсон!» Если я и соглашусь терпеть vm, то это должно давать что-то существенное: гибкость, «рефлексию», gc, макросы-шмакросы, «паттерн-матчинг», функции (безымянные) + классы + типы + AST + хз что как FCO (лень фантазию мучить), (про треды, уникод, оптимизацию «подхвостовой рекурсии» и ffi даже не вспоминаю) и в довесок jit чтобы всё это не тормозило как баш

Это Никлаус Вирт и его особая, велосипедная магия.

>> Если язык (ну да - «реализация») компилируемый - он может не отставать от си более чем в два раза?

может.

теоретически - да. практически - где результаты?

А в том, что такая гибкость должна стоить дёшево с точки зрения примитивов.

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

> 1) *print-case*
А, ну я понял, почему я о нём не знал. Видимо, знал, но забыл, потому что он безполезен, когда *readtable-case* = :preserve. Я предпочитаю camelCase, а не dotted-identifiers, кроме того, для генерации кода на других языках предпочтителен *readtable-case*=preserve. В этом случае, независимо от *print-case*, все встроенные символы при печати начинают ТОРЧАТЬ. Извините за офтопик.

> Впрочем, слава богу, системы управления пишут не на С.

Их уж точно пишут не на Паскале. Если же посмотреть, на чем написаны LynxOS или VxWorks, то мы увидим... правильно, Си. А уж насколько часто эти ОС использовалась в системах управления - это просто словами не передать. Сюда же и QNX.

А на Си, кстати, написано много систем управления, пусть и не для самолетов (в данном случае имеются в виду системы управления, работающие на микроконтроллерах).

>> Ну, тогда пример языка с хорошим дизайном - в студию.

* ooc

* crack http://mindhog.net:1921/pub/CrackScriptingLanguage/slide-000.html

* D, внезапно. Дизайн неплохой, проблемы с реализацией инструментария и «2 версии всего».

* Vala

* Nimrod

Все эти языки уже обоср^Wраскритикованы даже в этом треде :) И, насколько я знаком с Vala, он (именно как язык) - вторичная лажа.

>>Vala

У этого недо-C# дизайн хороший? Ну, всмысле, охотно соглашусь, что не настолько плохой, как у полноценного C#. Но, блядь!

бенчмарки неплохие: http://code.google.com/p/vala-benchmarks/wiki/BenchResults , где-то между C++ и обычным Си.

Чем оно лучше лиспа? Паскалевским синтаксисом?

скорее, питоновским. А семантика — понамешано между паскалем, питоном, трансляцией в си, сахаром и т.п.

А, что? Efficient? А если с SBCL сравнить?

по какому показателю сравнивать? Я так думаю, бенчмарки Nimrod должны быть где-то на уровне Vala, потому что идея та же самая: трансляция в Си и компиляция си компилятором.

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

а чего пилить нормальный GC, когда есть Boehm. А чего пилить конпелятор, когда есть трансляция в Си с каким-то качеством. Сразу сел и поехал, и тоже типа язык.
А вот философия, это да, сложно — тут думать надо.