Ответ на »сообщение 1920« (Гарин)
___________________________

Не уверен, первым, вторым или третьим, но Haskell включать надо.

Понятно. По ФП лучше иметь несколько кандидатов (2-3), чтобы можно было отдельно провести анализ сложности реализации и тесной интеграции с Обероноподобным языком (в котором могут быть введены некоторые ограничения, повышающие надежность). Haskell как один из первоочередных кандидатов фиксируем.

Во-первых, они бывают 2 типов: клиентские и серверные. Во-вторых, здесь наблюдается явное "преобладание" С-образных :))).
Для клиентов уже есть как бы "стандарт": ECMAscript (~Javascript). Поэтому, чтобы не идти против международной практики, вроде надо включать.
Что касается остального, то пока мнения нет. Хотя одно мнение вроде есть :). Терпеть не могу VBscript и PHP :))).

Как Вы смотрите на добавление к JavaScript такого языка, как Python? Опять же с точки зрения модульности и проработки языка.

Ответ на »сообщение 1919« (Geniepro)
___________________________

Наверное, стоит устроить специальный опрос где-нить на RSDN.RU, например...

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

1. С точки зрения перспектив больше очков у Хаскелла, затем у Ерланга, далее ОКамл/F#.

Как я понял, Haskell -- это хорошая ортогональность, неплохой рынок, но трудности реализации. Сколь много мы можем потерять в возможностях ФП, сделав ставку на Erlang? Какой язык из них более стабилен по изменениям? Чьи описания и реализацию реже правят?

2. Питон и Руби очень популярны, но по крайней мере одно семейство - JavaScrypt/JScrypt/ECMAScrypt - точно придётся реализовать: это жизненно необходимо для современного веб-браузера.

Если в качестве сценарного будет, например, расширенный JavaScript (ECMAScript -- строгое подмножество нашего расширения)?

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

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

3. Транслятор С разработать ненамного сложнее, чем транслятор того же Оберона. С С++ похуже, но он и не так важен, в принципе...
Большого толку от этих языков, наверное, не будет, ведь современные программы на С/С++ очень сильно привязаны к ГУИ, WinAPI, GDE, GTK, GDK, Qt... Кто будет реализовывать эти API?

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

>>>А что, есть большая разница между ГУИ Windows, MacOS, Linux? Какая?
А я и не говорил, что разница большая. Она маленькая. Но все-таки есть. Например, если Вы работали с MacOS X, то должны понимать, о чем речь. Мелочи, конечно, но имеются. Например, нет традиционного для Win меню/кнопки "Пуск" (Start), эту роль выполняет панель задач в нижней строке рабочего стола (уже не помню как точно эта штука называтся). Для управления задачами используется оболочка Finder, которая в любой момент доступна через меню в верхней строке рабочего стола. И т.д. Разумеется, любой пользователь быстро к этим различиям привыкает. Но все-таки детали "дизайна" GUI MacOS и "привычного" GUI Win32 отличаются. Хотя, по сути, Вы правы - окно - оно и в Африке - окно :)

>>>В связи с языками применительно к новой ОС хотелось бы узнать общественное мнение в
>>>отношении:
>>>1. Выбора базового языка ФП
>>>2. Выбора базового сценарного языка
Раз надо узнать мнение, выскажу свое.
Не уверен, первым, вторым или третьим, но Haskell включать надо.
Основания:
1) За этим языком нет интересов какой-то одной коммерческой фирмы. Проект научный, международный, можно сказать "академический". Для исследовательской экспериментальной ОС самое то;
2) Язык, по крайней мере, в отдельных чертах, поддерживает концепцию модульности. Это хорошо согласуется с идеологией Oberon;
3) Язык представляет группу ФЯ с ленивой моделью вычислений (lazy). Хотя бы один ФЯ ленивого типа должен быть представлен;
4) Для языка существуют хорошие компиляторы, доступные в режиме открытого использования (GHC, Hugs 98, и т.д.);
5) Язык имеет четко определенный официально опубликованный стандарт и хорошую математическую базу (Haskell 98);
Со скриптовыми языками сложнее.
Во-первых, они бывают 2 типов: клиентские и серверные. Во-вторых, здесь наблюдается явное "преобладание" С-образных :))).
Для клиентов уже есть как бы "стандарт": ECMAscript (~Javascript). Поэтому, чтобы не идти против международной практики, вроде надо включать.
Что касается остального, то пока мнения нет. Хотя одно мнение вроде есть :). Терпеть не могу VBscript и PHP :))).

Ответ на »сообщение 1915« (Руслан Богатырев)
___________________________

В связи с языками применительно к новой ОС хотелось бы узнать общественное мнение в отношении:
1. Выбора базового языка ФП
2. Выбора базового сценарного языка
3. Приоритетности реализации компиляторов Си, C++ и уровня ограничений, накладываемых на работу этих языков (реализованного на них софта) в новой ОС.

Наверное, стоит устроить специальный опрос где-нить на RSDN.RU, например...

Как мне кажется, тут нужно учитывать перспективы роста популярности этих языков...

1. С точки зрения перспектив больше очков у Хаскелла, затем у Ерланга, далее ОКамл/F#.

Качественный транслятор Хаскелла реализовать сложнее, чем Окамла/F#, однако, как я думаю, Хаскелл будет более затребован - у него большая академическая база. С использованием Хаскелла идут все основные новые исследования и разработки в области ФП.

Представитель ФП семейства должен максимально полно отображать современные идеи ФП, верно? Значит это должен быть чистый ФЯ с нестрогой семантикой и сильной типизацией. Самый изветный и распространённый такой язык - Хаскелл.
Окамл в этом плане менее интересен, так как он даёт гораздо меньше нового по сравнению с ИП, чем Хаскелл...

Ерланг интересен и полезен в плане многопоточных программ.
Эх, было б кому всё это реализовывать... :о)

2. Питон и Руби очень популярны, но по крайней мере одно семейство - JavaScrypt/JScrypt/ECMAScrypt - точно придётся реализовать: это жизненно необходимо для современного веб-браузера.

Кстати, роль скриптовых языков вполне могут играть Хаскелл, ОКамл, Scheme.
ОКамл в этой роли выглядит более привычным - он больше похож на стандартные Питон и Руби, в нём есть полный и удобный набор для императивного и ОО программирования, синтаксис более привычный, чем у Лиспов...

Лисп/Scheme - это вообще отдельная тема, ведь это не столько язык программирования, сколько образ мышления... Common Lisp сложнее в реализации, чем Scheme, но и более популярен. Однако с учётом использования новой ОС в сфере образования Scheme подходит больше.
Интерпретатор Scheme достаточно прост для реализации, что бы не задумываться об этом; можно просто включить его как бонус...

3. Транслятор С разработать ненамного сложнее, чем транслятор того же Оберона. С С++ похуже, но он и не так важен, в принципе...
Большого толку от этих языков, наверное, не будет, ведь современные программы на С/С++ очень сильно привязаны к ГУИ, WinAPI, GDE, GTK, GDK, Qt... Кто будет реализовывать эти API?

Ответ на »сообщение 1916« (Антон Григорьев)
___________________________

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

В общем, моё мнение - гнать С++ из новой ОС поганой метлой, чтобы и духу его там не было.

А Си? Тоже гнать? Он ведь стандарт де-факто для переносимого промежуточного кода. Если взять, например, ANSI C и обеспечить его работу в рамках специальных "саркофагов"? Под чутким, так сказать, руководством?

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

Ответ на »сообщение 1909« (Jack Of Shadows)
___________________________
http://www.citforum.ru/database/articles/manifests/

http://en.wikipedia.org/wiki/The_Third_Manifesto

Ответ на »сообщение 1915« (Руслан Богатырев)
___________________________

3. Приоритетности реализации компиляторов Си, C++ и уровня ограничений, накладываемых на работу этих языков (реализованного на них софта) в новой ОС.

Я вот что-то не понял - ведь если базовым языком становится Оберон, то, наверное, и понятие модуля становится важной частью архитектуры системы. И как вообще можно для такой системы писать на языках, в принципе не поддерживающих модульности и раздельной компиляции? Можно, конечно, придумать какую-то обвязку, но тогда это будет не совсем С++, и стоит ли ради этого городить огород?

В общем, моё мнение - гнать С++ из новой ОС поганой метлой, чтобы и духу его там не было.

Ответ на »сообщение 1901« (Geniepro)
___________________________

Если запускать программы на Си в отдельных пользовательских процессах, то они будут изолированы от ошибок друг друга...
И вапще на Си можно создавать элегантные и вполне безопасные программы... (Но можно и не создавать, да...:о( )

В связи с языками применительно к новой ОС хотелось бы узнать общественное мнение в отношении:
1. Выбора базового языка ФП
2. Выбора базового сценарного языка
3. Приоритетности реализации компиляторов Си, C++ и уровня ограничений, накладываемых на работу этих языков (реализованного на них софта) в новой ОС.

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

Ответ на »сообщение 1909« (Jack Of Shadows)
___________________________

Попробуйте поискать базис реляционных БД в виде той самой "строгой математической теории" и вы убедитесь чо они построены на песке господина Кода, который просто взял некий набор придуманных им самим аксиом (не из математики).

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

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

Ответ на »сообщение 1880« (Гарин)
___________________________

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


Ответ на »сообщение 1881« (whitetown)
___________________________

У "русской" ОС эмблемой, наверное, может быть медведь. А чтоб он не казался неуклюжим, пусть он танцует вальс. Кто сказал что медведи не танцуют?
Есть такая книга - "Вальсируя с медведями" ;-)