Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  21:25[Войти] | [Зарегистрироваться]
Обсуждение темы:
Русская ОС

Здравствуйте!

Хотелось бы знать, как народ отнесся бы к появлению проекта по созданию Руccкой ОС. Причём не только русской, но и всего русскоговорящего населения? Присоеденились бы вы к такому проекту?

Прошу не относить к флейму. Речь идёт о уже существующем проекте.

С уважением,

VICH

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 5452 сообщения



Отслеживать это обсуждение
<<<... | 1932—1923 | 1922—1913 | 1912—1903 | ...>>>
Всего сообщений в теме: 5452; страниц: 546; текущая страница: 354


№ 1922   18-07-2007 03:18 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 1920« (Гарин)
___________________________

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

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

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


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


№ 1921   18-07-2007 03:12 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 1919« (Geniepro)
___________________________

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

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

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

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

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

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

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

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

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


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


№ 1920   18-07-2007 03:04 Ответить на это сообщение Ответить на это сообщение с цитированием
>>>А что, есть большая разница между ГУИ 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 :))).



№ 1919   18-07-2007 02:52 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 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?


№ 1918   18-07-2007 02:37 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 1916« (Антон Григорьев)
___________________________

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

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


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

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


№ 1917   18-07-2007 01:33 Ответить на это сообщение Ответить на это сообщение с цитированием


№ 1916   18-07-2007 01:28 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 1915« (Руслан Богатырев)
___________________________

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

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

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


№ 1915   18-07-2007 01:00 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 1901« (Geniepro)
___________________________

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


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

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


№ 1914   18-07-2007 00:27 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 1909« (Jack Of Shadows)
___________________________

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

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

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


№ 1913   18-07-2007 00:21 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 1880« (Гарин)
___________________________

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


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

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


<<<... | 1932—1923 | 1922—1913 | 1912—1903 | ...>>>
Всего сообщений в теме: 5452; страниц: 546; текущая страница: 354




Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
Функция может не работать в некоторых версиях броузеров.

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования