Спецификация языка BitC, версия 0.4

спасибо за новость. Похоже что я из BitC много позаимствую..

Прикольно, что это немного похоже на то что мы недавно начали делать http://www.sf.net/projects/kernfach

> BitC - языка программирования, обладающего "низкоуровневой" природой Си и семантикой Схемы и ML.
нахуа?
И для Scheme/Lisp, и для ML (в лице OCaml) уже есть очень хорошие
компиляторы, иногда обгоняющие сишные. Сейчас, при наличии
Yacc/Bison/Lex/Flex и кучи соответствующей литературы сделать новый
язык как 2 пальца об асфальт, вот и ваяют.
Ниши конкретно у этого языка нет.

А вот такой язык, который бы обладал бы удобным (читай, привычным)
синтаксисом (типа C или Python), очень эфективно бы переводился в код для современных архитектур с SIMD операциями, легко позволял бы параллелить вычисления и был бы достаточно высокоуровневым и "секурным" (без указателей, авт. сборка мусора и т.д.) - вот он бы свою нишу нашел IMHO. Недаром NVidia сделала свой Cg, который позволяет напрямую работать с архитектурой GPU и недаром производители DSP добавляют специфические расширения к C, например, для операций с насыщением и т.д.
В-общем, нужен современный заменитель фортрана, который, кстати, до сих пор эффективней компилируется, нежели C, именно из-за отсутствия указателей и других низкоуровневых конструктов. В принципе, тот же C c интринзиками, словом restricted, OpenMP и внешним сборщиком мусора (типа GC) похож на этот мой идеал, но все-таки он недостаточно высокоуровненый. Или к C# что-то типа интринзиков и векторных операций добавить, благо что стандарт на этот язык сейчас открыт - хотя этот язык и так уже немаленький.

> Сейчас, при наличии Yacc/Bison/Lex/Flex и кучи соответствующей литературы сделать новый язык как 2 пальца об асфальт

а ты случайно не Каротин, который выдал что 90% компилятора это парсер?:) В этом BitC (Yacc/Bison/Lex/Flex)'ам делать особо нечего..

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

> а ты случайно не Каротин, который выдал что 90% компилятора это
> парсер?:) В этом BitC (Yacc/Bison/Lex/Flex)'ам делать особо нечего..

Нет, я не Каротин и я догадываюсь, что в языках с Lisp-подобным синтаксисом (к которому я не привыкну никогда) парсер очень простой и его можно написать руками, но утверждаю, что в большинстве случаев первые версии многих "новых языков" можно сделать очень быстро, практически целиком поместив реализацию в .y файлы и задавая действиями необходимые производимые вычисления или преобразования в исполняемый байткод (как правило, для стековой машины). А вот потом, когда начинается доводка скорости, наращивание "мяса" и вылавливание багов - вот тут интерес авторов быстро улетучивается, тем более что community у таких языков очень малочисленные в первое время и может присутствовать недостаток интереса. А вот тот язык, который я описал, при наличии уже довольно хорошей реализации, сразу нашел бы пользователей и раскрутился бы достаточно быстро, особенно если хороший интерфейс к C/C++ сделать.

Мне в-общем не жалко, пусть ребята делают, их время, не мое (в конце концов, это-ж живой experience, который потом на интервью на работу можно упомянуть), только без толку это все...

> Дык у этого языка ниша та же, что у C-- - промежуточный язык для компиляторов и язык системного программирования...

Для системного программирования можно использовать любой язык, даже необязательно компилируемый, который имеет интерфейс к ОС. Вот на Питон написан инсталятор и конфигурационные утилиты для Redhat, portage для Gentoo, bittorrent, кажется, и еще куча системных вещей - что, это не язык для системного программирования?
Насчет промежуточного языка для компилятора - это неотъемлемая часть самого компилятора, поэтому что-то внешнее и инородное здесь приживется с нулевой вероятностью. Например, я уверен, что в обозримом будущем GCC на что-то подобное не перейдет. А до коммерческих компиляторов просто не допустят.
И вообще, с развитием GCC компиляторный бизнес сильно сузился - и это правильно, можно взять готовый отличный frontend с хорошим оптимизатором промежуточного языка, написать файлик с описанием своей аржитектуры и вуяля. Вот это действительно прогресс в системном ПО и реальная польза от open source.

Видать, маловато ты в языках разбираешься. СлабО на одном только Yacc сделать Хиндли-Миллнера? А суперкомбинаторный лямбда-лифтинг?

посмотри D - может это то что ты ищешь? http://www.digitalmars.com/d/

Под системным программированием в данном случае понимается то, что в ядре ОС. Тут Питонам определённо не место...

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

2Mauhuur

> Видать, маловато ты в языках разбираешься. СлабО на одном только Yacc
> сделать Хиндли-Миллнера? А суперкомбинаторный лямбда-лифтинг?

Ну во-первых не слабо, если ты предоставишь мне реализацию на C, хотя я и не знаю всех эти терминов - я говорил про .y файлы, а не про чистый Yacc. Улавливаешь разницу? В .y можно
с помощью %% %% окружить произвольный С-шный код, а в нем дописать всю необходимую поддержку.
Во-вторых, язык для меня - средство, а не самоцель. И владею я теми языками, с которыми работаю, в совершенстве - то есть, могу выразить ими любую свою "алгоритмически выразимую" мысль. Можно сделать хорошую
программу, использовав небольшую часть языковых средств, а можно вывалить на пару страниц кода весь стандарт C++, чтобы потом тебя прокляли те, кто с этим кодом будет работать.
А слабо тебе написать на любом языке шахматную программу, которая
будет играть хотя бы на уровне GNU Chess? А ведь в GNU Chess и во многих других хороших программах почти наверняка не используется
lambda-исчисление в явном виде и другие функциональные навороты. Стали
ли эти программы от этого хуже или менее полезными? Мы не знаем, зато знаем, что на чисто функциональных языках и от "теоретиков программирования" хороших больших программ практически не создано.
Так вот.

2lg:

> посмотри D - может это то что ты ищешь? http://www.digitalmars.com/d/
Спасибо. Смотрел я его как-то, но чем-то он мне не понравился. И суда по тому, что мало его кто пользует, не только мне. Может быть, стоит мне еще вглянуть.

Размечтался... На C Хиндли-Миллнера - это дикое извращение, лучше сразу удавиться.

Для вывода типов по алгоритму Хиндли-Миллнера надо анализировать всё выражение (AST) и при этом знать типы ранее определённых функций. На этапе получения самого AST (то есть - в .y) ты это не вставишь - нужен второй проход (а потом - ещё и третий, и четвёртый).

И я абсолютно уверен, что ты никогда не напишешь простого и короткого компилятора даже для самого примитивного языка на Си - всё, что ты сделаешь, будет на порядки менее читабельным, чем то, что я сделаю на Haskell или даже на Лиспе. Да ещё тебе потребуются всякие там дурные внешние препроцессоры вроде Yacc-а, тогда как мне хватит самого языка.

Про GNU Chess - там нет никакой алгоритмической сложности. И даже такую простую вещь можно в десятки раз короче переписать на правильном языке - бОльшая часть кода GNU Chess - это описание эвристик. Каждая из них - простая, но их много, и все - однотипные. Идеальное место, куда надо присобачить DSL.

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

Нет! Не слушай этого совета! Писать надо на том что даёт тебе хлеб (когда женишся - ты это поймеш :)) а всякие там лиспы / хаскели / *МЛ-и - оставь как хобби - если тебя это прёт (Но помни! Нормального человека радуют в жизни совсем другие вещи ;) ).

-- boshik

не понравилься он тебе скорее всего тем что нет свободного компилера :(

2Mauhuur:

> Под системным программированием в данном случае понимается то, что в ядре ОС. Тут Питонам определённо не место...
что в данном случае понималось, видимо изменилось в ходе дискусии, ну да ладно - видели новость, что автор tcc его встроил в ядро и может компилировать его на ходу. Кто запрещает встроит интерпретатор Питона в ядро (или jit-компилятор, как Python+Psyco) и писать части ядра, например, драйвера, на Python? "Есть многое на свете друг Горацио, то что не снилось даже мудрецам" (Shakespire)

> Про промежуточные языки - иди, посмотри на C--, вразумись малость. Про GCC речи и нет - но вот многие другие компиляторы сильно выиграют от такой вот более высокоуровневой, чем C, целевой платформы. В общем, ты очень сильно узко мыслишь - языки для тебя ограничиваются тем убогоньким набором, который есть в GCC, а про другие - и слышать не желаешь.

Во-первых, лучше обойтись без наездов. Что-то по этому поводу я написал в предыдущем посте. На С-- посмотрел, и посмотрел, кто использует его - все это проекты, где C-- был выбран сначала, и ни один из этих языков существенной роли, кроме как в жизни их создателей, не играет (Ну Lua для игр немного используется). Ну и слава богу - безопасные тестовые площадки. Вот как только некий доброволец переведет какой-нибудь широкораспространенный компилятор на этот замечательный target язык и докажет с цифрами в руках, что это хорошо, возможно, что к C--, BitC и прочим проявят какой-то интерес. А на убогоньком GCC написано столько софта и сделаны настолько сложные алгоритмы, включая компиляторы всяких экзотических языков для широко (но, возможно, неглубоко) мыслящих, что страшно подумать.

Надо отличать искусство программирования от программистского ремесла, а также от программирования - как прикладной науки. Люди, относящиеся к программированию как искусству, пишут emacs, Python и пр. А ремесленники за деньги в очередной раз переписывают один и тот же модуль расчета прибыли от продажи, например, трусов сначала на VB, потом на Java, а теперь уже и на С#

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

> Ты будешь таки смеяться, но я зарабатываю на хлеб себе и семье, программируя на Лиспе, Хаскелле, и много чём ещё.
> Просто я - не кодеришко, которого посадили на Жабе сточить по спекам, и ни шагу в сторону, а программист - и задачи решаю не в пример более сложные, чем тот же GNU Chess.
> С Жабой я бы их никогда не решил - жизни бы не хватило.

Здорово, нет, правда здорово. Если эти языки (собственно, насчет Lisp'а я и не сомневался) приносят кому-нибудь хлеб насущный, то это уже неплохо - значит, есть какая-то от них польза.
Я осмелюсь попросить хотя-бы одну ссылку на какой-нибудь результат этого труда, но, честно говоря, даже не надеюсь. Я, в общем, верю вам на слово - но посмотреть хочется, независимо от этого, особенно если на Хаскелл - ни разу не видел софта, сделанного на нем, а тем более за деньги.

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

2 Mauhuur

В данном контексте полностью поддерживаю Вас и Вашу позицию. Просто слишком много
стало "программистов", которые путают системное программирование с работой в системе...
Для таковых и написание инсталлятора - задача системного программирования :-))

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

2R_Valery:

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

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

> Я осмелюсь попросить хотя-бы одну ссылку на какой-нибудь результат этого труда,

Да, это снова я, только зарегестрировшись.
В-общем, тут товарищи (free_serj) подсказали, в каком направлении копать. Я и не знал, что с "самим" связался :) Да, список софта нашел и приличный (в основном касательно OCaml), но вроде это все академическое программирование, не продукты? И, в-общем, я бы не сказал, что по сложности это существенно превосходит шахматные программы. Да, эвристик в шахматных программах много, но любая стоящая программа включает в себя множество подобных вещей и реальная сложность часто ими и определяется. Возможно, функциональные языки позволяют компактно и выразительно записать общие идеи и "правила" используемые в программе, но в реальных программах, как и в реальной жизни, встречается много "исключений", и надо просто это все аккуратно закодировать - часто засчет большого объема кода и кропотливой работы. Вот тут, на микроуровне, достоинства функциональных языков уже не так важны, как удобство синтаксиса и общие ценности высокоуровневых языков, как-то автоматическое управление памятью, обработка исключений и т.д.
И на макро-уровне, уровне модулей и общей архитектуры большой программы все языки, поддерживающие модули и ООП также примерно одинаковы.

2 V_P

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


Да просто по причине того, что всё перечисленное Вами работает УЖЕ в системе ( я имею
ввиду как минимум предварительно загруженное её ядро). На мой взгляд к, системному
программированию относятся те программы, которые работают в качестве составных частей ОС.
Т.е. модули ядра и пр. Вы не согласны? :-)

Правда, некоторые товарищи администраторы считают, что "тонкая" настройка системы -
есть системное программирование. :-))

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

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

Но, покажите мне хоть один драйвер, написаный целиком на Перл. :-)))

> компилятор к системным программам, я подозреваю, потому что он
грузился вместе с операционной системой


Покажите, в какой момент инсталяции RH Linux грузится какой-либо инсталятор? :-)))

Простите, инсталятор воспринимать как компилятор. Очепятка...

>А вот такой язык, который бы обладал бы удобным (читай, привычным) синтаксисом (типа C или Python), очень эфективно бы переводился в код для современных архитектур с SIMD операциями, легко позволял бы параллелить вычисления и был бы достаточно высокоуровневым и "секурным" (без указателей, авт. сборка мусора и т.д.)

Хм... А про Java вы слышали?

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

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

бедняги. а они в общество защиты ... обращаться не пробовали?

>Да просто по причине того, что всё перечисленное Вами работает УЖЕ в системе ( я имею ввиду как минимум предварительно загруженное её ядро). На мой взгляд к, системному программированию относятся те программы, которые работают в качестве составных частей ОС. Т.е. модули ядра и пр. Вы не согласны? :-)

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

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

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

>Али мои понятия устарели?

нет, они просто нуждаются в тюнинге... ;-))

2uglock:

> Хм... А про Java вы слышали?
Ну он не совсем свободный, эффективность компиляторов до сих пор сомнительна, по сравнению с C и Fortran - я говорю не о тупых (т.е. неоптимизированных) искусственных бенчмарках, а о реальных вычислительных программах. Параллельности на микро-уровне нет - есть классические потоки и механизмы синхронизации, а чего-то типа OpenMP нет. В общем, с точки зрения указанных критериев он ничем не лучше того же C#, а может и похуже будет.

2R_Valery:

> Но, покажите мне хоть один драйвер, написаный целиком на Перл. :-)))
> Покажите, в какой момент инсталяции RH Linux грузится какой-либо [компилятор]? :-)))

можно очень долго спорить о некотором предмете, если изначальные определения этого предмета у спорящих разные.
Я использую то определение системного программирования, которое я усвоил в различных книгах, в том числе довольно известной книжке Л.Бек'а. "Введение в системное программирование". С позиции этого определения под системное программирование попадает все что используется для функционирования системы, различные компиляторы и т.д. Разделение программ на системные и прикладные очень условно. Например, если рассматривать архитектуру ОС с микроядром, то драйвера устройств можно рассматривать как прикладные программы. А в случае крохотных встраиваемых систем вообще вся программа, или прошивка, может рассматриваться как монолитный блок - ОС + прикладная программа, взаимодействующая с пользователем.

Даже если говорить про тот же Linux, и смотреть, как он грузится, что описано у Айвазяна, то можно заметить, что это тоже не единовременный процесс и многие драйвера грузятся попозже и в УЖЕ работающую систему.
А некоторые, для USB устройств, например, грузятся гораздо позже, если вообще в этом возникнет необходимость.

Компилятор может грузится вместе с Redhat - см. новость про TCC где-то с месяц два назад.

>Ну он не совсем свободный,

a) скора будет

b) Все равно буржуи платят.

>по сравнению с C и Fortran - я говорю не о тупых (т.е. неоптимизированных) искусственных бенчмарках, а о реальных вычислительных программах.

Ну для вычислений и нада пользоваться Фортраном. Java в осовном щас применяеться на web-серверах в виде сервлетов и JSP. Вот для этого там есть нормальная кластеризация и т.п.(Сейчас тока тестирую это дело.)

> эффективность компиляторов до сих пор сомнительна, по сравнению с C и Fortran - я говорю не о тупых (т.е. неоптимизированных) искусственных бенчмарках, а о реальных вычислительных программах.

Числодробление - это далеко не все.

ARia

2uglock
> Ну для вычислений и нада пользоваться Фортраном.
На фортране далеко не уедешь если в сторону от матриц свернуть, хотя
фортран 90, конечно, уже гораздо читабельней и современней, чем 77.
Структуры в нем сложные, типа графов, создавать по прежнему сложно.
Языков не для вычислений сейчас навалом, речь о том, что хочется
получить что-то среднее между C++, Java, Matlab, Python & Fortran, на
котором писать было бы приятно, но в то же время и работало бы это
быстро. В принципе, Python с модулем Numeric тоже неплох, но
синтаксических удобств немного не хватает, ну и потом footprint
большой - цельный интерепертатор + еще отдельный большой модуль. А
хочется получать относительно компактный исполняемый файл + несколько
тоже небольших runtime библиотек. И желательно, чтобы он сразу
определял возможности системы, как-то доступные иструкции, размер
кеша, кол-во процессоров, и выбирал почти оптимальный вариант для
такой конфигурации. Кстати та же Java после jit работает достаточно
быстро и потенциально допускает настройку под аппаратную конфигурацию, но жрет кучу ресурсов и медленно грузится (т.к. работает jit)
- вот хочется и этих недостатков избежать.

2ARia:
> Числодробление - это далеко не все.
согласен. И даже согласен с тем, что и программирование и компьютеры вообще это далеко не все. Просто для кого-то цислодробление это основное направление работы, а основной инструмент (fortran) уже сильно устарел.

Гы, тут что-то одно - или посмотреть, или деньги. ;)

А вообще - советую НИКОГДА не судить ни о каком инструменте по его популярности (если бы все так поступали - то и линуха бы не было!). Оценивай объективно - не будь обывателем, будь ЧЕЛОВЕКОМ!

Про серьёзные коммерческие применения Хаскелля - железячники-ембеддщики много чего порассказали бы - оптимизация и верификация железа, компиляторы под доморощенное железо, и т.п. Для меня Хаскелл - средство быстрого прототипирования (ну да, таки потом оно на Лисп или Java переписывается).

Тот же MLDonkey - нисколько не академический, и очень даже продукт.

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

Про "микроуровень" - при программировании на серьёзном языке нет нужды лезть на микроуровень. Какой censored станет программировать, к примеру, красночёрное дерево, если оно уже есть? Или тот же qsort...

Про синтаксис - вменяемые языки позволяют выбрать ЛЮБОЙ синтаксис, какой нравится, а не ограничиваться тем censored, что какой либо Гослинг или Страус выродил в муках.

Те, для кого Фортран устарел, давно юзают что либо вроде связки Mathematica/Maxima/Axiom -> автоматическая генерация кода на Фортране. То есть - и все преимущества компиляторов Фортрана доступны, и ручками на убогом языке писать ничего не приходится.

2 anonymous (*) (28.01.2005 12:39:36)

Дык! Можно и компилер загружать... При необходимости... Но часто ли такая необходимость
возникает?

>Например, если рассматривать архитектуру ОС с микроядром, то драйвера
устройств можно рассматривать как прикладные программы.

Подход действительно _разный_. Скажите, может ли в принципе существовать _работающая_ система
без модулей поддержки (драйверов, как вы понимаете), скажем контроллера диска? Или памяти?
Мы действительно учились в разное время и по разным учебникам. ;-) Посему, в моём
понимании, к системному программированию относится написание программ, способствующих
обеспечению работоспособности машины. Причём, в широком понимании. Вы, наверное, знаете о том,
что работоспособность персонального ПК и терминала обеспечивается совершенно разными
способами... И если Вы согласны с вышесказанным, то динамически подгружаемые модули
ядра Вы никак не отнесёте к прикладным программам.
Так и инсталятор, задача которого - всего лишь дефолтный тюнинг системы, в свете
всего высказанного мною выше, никак нельзя отнести к классу системных задач.

>Компилятор может грузится вместе с Redhat - см. новость про TCC
где-то с месяц два назад.

А попробуйте установить Генту без компилятора. :-)) При всём при этом, компилятор для меня
был и остаётся прикладной программой. Хоть и очень важной.

Системе, в которой нет контроллера диска, не нужен и драйвер этого контроллера (e.g. Symbian).

Да, по Беку и прочим компиляторы всяческие - относятся к системному программированию. Однако - нынче ситуация очень сильно изменилась, и столь чёткого определения, как раньше, дать не получится. Проще ограничить понятие системного программирования ядром ОС и драйверами.

2 Mauhuur

>Да, по Беку и прочим компиляторы всяческие - относятся к системному
программированию. Однако - нынче ситуация очень сильно изменилась, и
столь чёткого определения, как раньше, дать не получится.

Так тут я полностью согласен! И с последующим тоже.

2 MiracleMan (28.01.2005 11:47:34)

>нет, они просто нуждаются в тюнинге... ;-))

Очень даже возможно... ;-))

2Mauhuur:
> Проще ограничить понятие системного программирования ядром ОС и драйверами.
А еще проще вообще никак системное и прикладное ПО не разграничивать.
Потому что никаких пользы от этого разграничения нет - одна путаница.
Для какого-нибудь enterprise программиста SQL сервер будет являться настоящей системной программой, потому что ниже он не опускается и целиком "живет" в этой среде. А для web-программиста такими системными программами возможно будут http-сервер и браузер. Раньше действительно, были два уровня - система, и прикладные программы, потому что на большее ресурсов компьютера не хватало. А сейчас можно строить обширные иерархии. Например, берем
linux. Запускаем vmware - прикладную программу, под vmware запускаем другую ОС - винду. Под виндой запускаем эмулятор nintendo - тоже со своей какой-никакой ОС. Прикладная программа, под которой можно запустить ОС - является ли она одновременно системной или нет? Или запускаем emacs, хоторый по сути дела является настоящей лисп-машиной, и сидим в нем не выходя многие месяцы (периодически уходя в hibernate), запуская компиляторы, отладчики, браузеры, читая почту, даже редактируя тексты.
Например, взять человека, до этого с компьютерами не работавшего, и настроить ему комп, чтобы при загрузке автоматически запускался emacs - он и будет считать его Системой, а lisp, соответственно - языком системного программирования.

Дык эта, emacs - и есть ОС. Собственно, его предок - ОС на Лисп-машинах... ;)

R_Valery:

Ну в таком ключе, когда вы сами определяете, что для ВАС является
системной программой, а что нет, и дискутировать невозможно.
Вот например, я могу считать, что без тетрис, написанного скажем на
Питоне, для МЕНЯ система не работоспособна. А то что вы называете ОС -
опять же для меня, не более чем программа, подготовливающая машину к
запуску самой важной для меня программы - тетрис, соответственно ее
роль - прикладная :)

Еще насчет работоспособности - если моя звуковая карта не определится,
или wireless карточка не подцепится (при этом обычная сетевая будет
работать нормально), или ACPI работать не будет (что
часто сейчас под Linux и случается) - что, работоспособность системы
будет нарушена (опять же, в широком смысле)? Нет, можно обойтись,
тогда получается, что часть драйверов, следуя вашей собственной
логике, можно считать прикладными программами. А вот если при этом,
скажем, мой любимый текстовый редактор начнет вдруг глючить, то опять
же, в широком смысле, работоспособность системы (то есть способность
системы выполнять работу, которую дает ей пользователь) нарушится,
соответственно редактор вдруг становится системной программой.

2Mauhuur:
> Дык эта, emacs - и есть ОС. Собственно, его предок - ОС на Лисп-машинах... ;)
Вот до чего доспорились, теперь emacs считается ОС :)
тогда легко заключить что M$ офис тоже (поскольку в офисах под виндой люди проводят в нем не меньше времени, чем под linux'ом в emacs), соответственно, Lisp, VBA & Python (последний, за компанию, ну и в Zope это основной язык) считаем языками системного программирования, а любую программу, способную украсть внимание пользователя на несколько часов - системной.

Дык на Лисп-машинах он и был ОС, а Лисп - единственным доступным языком системного программирования. Ну, не сам emacs, точнее, а его идеологический предок...

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

> Про шахматы - ещё раз - алгоритмической сложности там нет.
> Сам алгоритм туп - NP-обход вглубину с ограничением по фиксированному
> набору эвристик. Я такие задачи решал для оптимизации - шахматы тут и
> рядом не валялись по количеству вариантов и по недоступности
> отработанных эвристик - мне их приходилось эволюционно выращивать.
Ну про сложность и про количество вариантов это вы лучше команде DeepBlue расскажите, может они чего-то не понимают - заодно поднимете мировые копьютерные шахматы. А еще лучше сразу за Го возьмитесь, какая разница - и там и там куча простых эвристик и кол-во вариантов заведомо меньше, чем в ваших оптимизационных задачах. Те самые NP-обходы в глубину до сих пор совершенствуются. А в листьях (то есть на максимальной глубине) оценку позициии вы как предполагаете делать? Назвать это большим набором простых однотипных эвристик конечно проще всего.

> Про "микроуровень" - при программировании на серьёзном языке нет нужды лезть на микроуровень.
> Какой censored станет программировать, к примеру, красночёрное дерево, если оно уже есть? Или тот же qsort...
Примеры неудачные. Если, скажем, к VB добавить красно-черное дерево и qsort (кстати, рекомендую взглянуть, как сделана сортировка в Python, если еще не смотрели - это далеко не qsort), то получится, что и в VB не надо лезть на микроуровень - какая тогда разница между Хаскелл и VB? На микроуровень нужно лезть почти всегда, если хочеться сделать какой-то оригинальный алгоритм.

> Про синтаксис - вменяемые языки позволяют выбрать ЛЮБОЙ синтаксис, какой нравится,
> а не ограничиваться тем censored, что какой либо Гослинг или Страус выродил в муках.
Если вы создаете ваши творения исключительно один, а люди смотрят на этот код с вашим собственным синтаксисом и просто восхищаются (ничего при этом не понимая), тогда возможно, это достоинство языка.
А если вы хотите подключить других к разработке, то вас могут просто не понять, или наоборот, найдутся еще более головастые, и завернут это так, что вы сами нифига понять не сможете в когда-то вашей программе.
Это кстати одна из основных причин, почему некоторые до сих пор предпочитают C вместо C++, потому что в нем меньше языковых наворотов.
Тот же C, Python и многие другие языки отлично расширяются с помощью библиотек функций, классов и макросов - при этом оставаясь читаемыми. Ваши примеры с RB-деревьями и сортировкой хорошие этому примеры.
Базовый синтаксис и семантика просто являются неким фундаментом, качество проектирования которого влияет на успех языка. Но это не означает, что программисту следует давать тротил, чтобы он направленными взрывами этим фундаментом рулил.
Языки с изменяемым синтаксисом существовали и существуют уже давно (тот же Algol 68), только вот народ их не принял.

>>>тот же Algol 68 ....

Кстати, никто не в курсе, его не пытались реанимировать ?