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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.

Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.

Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.

 Jack Of Shadows

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

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

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


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

Добавить свое сообщение

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


Смотрите также обсуждения:
Средства разработки. Языки программирования.
  • Delphi 4 or Delphi 5
  • Что приобрести в качестве средства разработки?
  • Delphi6
  • Delphi vs PowerBuilder
  • Сравнение компиляторов
  • Вот и вышла Delphi 7... Вы рады?

  • <<<... | 2892—2883 | 2882—2873 | 2872—2863 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 263


    № 2882   16-04-2007 07:12 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2874« (Илья Ермаков)
    ___________________________

    Основные мои возражения в спорах были направлены против нескольких чрезмерно "сильных" тезисов - как то: безусловное превосходство ФП во всех сферах, и даже в системной и реального времени; подчеркивание якобы "труднодостижимости" параллельности на мультипроцессорных системах при разработке на ИЯ. Но эти тезисы мы вроде бы уже обсудили

    Обуждать-то обсуждали, да вот только к общему мнению так и не пришли, похоже... Ну да ладно...


    По моим впечатлениям, курс построен здорово. По впечатлениям нескольких человек, которые в начале 90-х по нему учились - тоже.

    Конечно, хорошо иметь такой курс, вот только много ли преподавателей, которые его осилят?
    С ФП ситуация, похоже, не лучше...


    (ИП) Таким образом, в этом случае мы имеем программирование как "базово-инженерный" предмет.
    ...
    (ФП) Но - при этом сформируются уже другие качества мышления: в первую очередь - способность к формальному описанию решаемых проблем в терминах функций, декларативной формулировки цели вычислительного процесса. Это не менее важно, чем качества перечисленные выше - но! - это уже другое...

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

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


    Если даже язык верстки текста и мат. формул - LaTeX, который преподается всем специальностям физмата, - нынешним первым курсом воспринимается как "китайская грамота", то о чем тут говорить...

    Вот сколько пытался найти толковый TeX-редактор под Виндовс - так и не получилось... Не ставить же Линукс только ради этого редактора...
    Потому и мало кому известны все эти TeX'и, что мало распространены...


    1) Программирование и вычислительная техника - на основе подобных вышеописанному курсов и инструмента вроде Блэкбокса;
    2) Компьютерное моделирование либо Вычислительная математика - о названии можно подумать - на основе подходящей функциональной среды (Scheme? Haskell? - вам виднее, господа эксперты ФП),

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

    Scheme в этом плане вообще стоит особняком - это ведь гибридный язык, а значит в нём есть не только ФП, но и ничуть не меньше ИП и ООП, а также настоящего (или, скажем так, традиционного) метапрограммирования...
    Вообще-то в Scheme, пожалуй, больше ИП, чем ФП, поэтому, например, у AVC возникают "проблемы с децентрализацией в ФП" - он всё время думает категориями ИП, не переходя толком на ФП... Но для школьников это, пожалуй, неактуально...
    В Scheme функции выглядят ненамного математичнее, чем в Обероне, единственно, что ими гораздо удобнее оперировать.

    Наверное, строить школьный курс лучше было бы всё-таки на основе Scheme как самом универсальном и при этом самом простом из этих трёх языков...
    Проблема в том, что если для Оберонов уже существуют хорошие школьные курсы, которые нужно только адаптировать под Оберон, то для ФЯ таких (именно школьных) курсов вроде как и нету... Их ещё делать нужно... И обучать им в первую очередь учителей...


    Так вот, в последнии дни у меня случилось много поводов поразмыслить о преподавании информатики в школе. Как уже говорил, "натаскиваю" недоученных первокурсников.

    А у Вас есть возможность поэкспериментировать над школьниками? Было бы очень интересно...


    № 2881   16-04-2007 03:00 Ответить на это сообщение Ответить на это сообщение с цитированием
    В дополнение к сказанному выше, есть еще отличие: динамическая типизация Scheme может вызывать у учащихся трудности... Хотя, может и не вызывать --- на этот счет есть очень разные мнения. Впрочем, прикрутить статический вывод типов к Scheme (или к ее подмножеству), видимо, не составит труда. Более того, в развитых Scheme-компиляторах (если я не ошибаюсь, таковыми считаются Bigloo, Stalin) он, скорее всего, уже реализован для оптимизации кода.


    № 2880   16-04-2007 02:54 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2877« (pepper)
    ___________________________

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

    С этим согласен. Более того, давно уже ратую за мир, дружбу и добрососедство. Просто одно дело изучать некий инструмент, крутить-вертеть его в руках, и другое дело -- применять на практике с большой эффективностью. Здесь не зря всплывал в обсуждении тот же Python Гвидо ван Россума ("фаната" Modula-3), где можно задействовать ФП. Сам по себе Haskell не столь легок на подъем. У ФП есть немало плюсов, но есть и большущие минусы. Поэтому для перехода на ФЯ требуется тщательно продуманный выбор (за отрешение от мира суетного придется все равно платить).

    Лично для меня направление МП с развитием идей программных кластеров -- более интересно. Здесь Оберон -- хороший выбор. Значит, можно в нем как усиливать средства контроля сложности и гарантий надежности, перенимая чужой опыт, так и заниматься изучением возможностей взаимодействия ортогональных языков: например, в связке Оберон/КП -- Haskell или Оберон/КП -- Erlang. В Обероне можно эффективно реализовывать идею "саркофагов" (гарантия полного невмешательства как снаружи, так и воздействия вовне). Можно выделять зоны, в которых разумно устанавливать контакты с ФЯ и использовать ФЯ-хозяйство в качестве вспомогательного "сервера". Можно и наоборот, но предпочитаю смотреть со стороны, более близкой железу и моему опыту работы.


    № 2879   16-04-2007 02:41 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2874« (Илья Ермаков)
    ___________________________


    Итого, суммируя... Если ставить обучение в школе как положено, то необходимо изучение трех независимых предметов:
    1) Программирование и вычислительная техника - на основе подобных вышеописанному курсов и инструмента вроде Блэкбокса;
    2) Компьютерное моделирование либо Вычислительная математика - о названии можно подумать - на основе подходящей функциональной среды (Scheme? Haskell? - вам виднее, господа эксперты ФП), в самой тесной связи с изучением разделов математики, как наглядная демонстрация практического применения последних, лучше даже с преподаванием (подготовленными) учителями математики.


    "Не нужно умножать сущности без необходимости". (c) У. Оккам.

    Императивный стиль программирования на Scheme достаточно удобен. Более того, в одном из обсуждений на c.l.l проскочил даже такой тезис, что Scheme --- это вполне алголоподобный язык, только с необычным синтаксисом. Кроме того, небезызвестный Kent M. Pitman также ставит между Algol, Pascal и Scheme знак равенства в пригодности для обучения: http://www.myelin.co.nz/notes/kent-pitman-languages.html. Добавим к этому наличие учебников, методических материалов и специальных сред программирования, ориентированных на обучение. Еще добавим простоту языка, позволяющую в ходе учебного процесса разобрать собственно его реализацию как один из учебных примеров. Еще добавим достаточно развитую систему макросов, позволяющую коснуться и DSL (впрочем, это уже не для школьного курса).

    Минусом же ИМХО является то, что средства ООП и модульности в Scheme не стандартизованы (по крайней мере, в R5RS), так что каждый разработчик Scheme-системы склонен решать этот вопрос по-своему (и часто несовместимо). Впрочем, для учебной системы это не так важно, как для промышленности.


    № 2878   16-04-2007 02:15 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2876« (Max Belugin)
    ___________________________
    С моей точки зрения, криптографичность (то есть оперирование спецзначками, а не словами) дает выигрыш в долгосрочном плане. (Разумеется, если значками обозначаются частоиспользуемые слова, а не вводятся по знаяку на каждое его использование)
    Узнаю брата-фортера... :о)
    Кстати, на последник евроконфах по форту всё чаще попадаются статьи, предложения и рассуждизмы о внесении лямб в форт...
    ... Опасность для мира форта не в его ограничениях, а в его безграничности... :о)


    № 2877   16-04-2007 01:14 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2857« (Руслан Богатырев)
    ___________________________


    Я пояснял, что переменная, импортированная на чтение (равно как и экспортированная на чтение) -- это не константа. Она может постоянно меняться (например, другим процессом). Просто ее запрещено изменять сущностями данного "государства".


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


    № 2876   16-04-2007 00:52 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2873« (AVC)
    ___________________________


    У меня пока проблемы с децентрализацией в ФП.


    Какие?


    Конечно, "криптографичность" свойственна не ФП (как системе идей), а отдельным нотациям, в т.ч., к сожалению, некоторым ФЯ


    С моей точки зрения, криптографичность (то есть оперирование спецзначками, а не словами) дает выигрыш в долгосрочном плане.

    (Разумеется, если значками обозначаются частоиспользуемые слова, а не вводятся по знаяку на каждое его использование)

    Говорят, что труды Ньютона написаны словами -- без формул типа: "ускорение обратно проворционально массе и прямо пропорционально силе" вместо a=F/m. При первом прочтении словами понятнее, но оперировать труднее...


    № 2875   15-04-2007 22:57 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2874« (Илья Ермаков)
    ___________________________

    1) Программирование и вычислительная техника
    2) Компьютерное моделирование либо Вычислительная математика
    3) Информационные технологии - продолжение "трудов" на компьютере.


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


    № 2874   15-04-2007 14:48 Ответить на это сообщение Ответить на это сообщение с цитированием
    Позволю себе поразмыслить вслух об обучении программированию в школе - и о преимуществах в этом смысле ФП/ИП. Это будут именно мысли, с формулировкой своих сомнений и своего видения проблемы, а не с целью критики ФП (говорю это из-за того, что в последнее время обсуждения у нас в ветках стали балансировать на грани holly-war. Еще раз подчеркну, что лично я не имею никакого предубеждения против ФП как такового, и против достойного места ФП в образовании. Основные мои возражения в спорах были направлены против нескольких чрезмерно "сильных" тезисов - как то: безусловное превосходство ФП во всех сферах, и даже в системной и реального времени; подчеркивание якобы "труднодостижимости" параллельности на мультипроцессорных системах при разработке на ИЯ. Но эти тезисы мы вроде бы уже обсудили).

    Сразу предупрежу, чтобы потом к этому не возвращаться - будем говорить о преподавании в старших классах (8-11) физико-математического, естественно-научного, технологического и подобных профилей. Для гуманитариев все эти рассуждения могут не совсем подходить...

    Так вот, в последнии дни у меня случилось много поводов поразмыслить о преподавании информатики в школе. Как уже говорил, "натаскиваю" недоученных первокурсников. В связи с этим поднял старый добрый школьный учебник: А.Г. Кушниренко, Лебедев, Сворень "Основы информатики и ВТ", 1990. Этот учебник сделан на мехмате МГУ, основан на среде КуМир, там же на мехмате и разработанной в свое время. Если говорить от традиционном ("императивном") обучении информатике, то по моему мнению, учебник превосходен. Алгоритмический язык на основе ершовского прост, чист и нагляден, и, между прочим, непосредственно, до мелочей, отображается на основные алгоритмические конструкции Оберона (даже ASSERT введен - оператор УТВ, он справедливо признан важным с самых первых шагов + есть стандартная форма записи предусловий и постусловий для "вспомогательных алгоритмов", т.е. процедур).

    В целом, авторам удалось в небольшой по объему книжке пошагово изложить все основные схемы алгоритмизации, даже с объяснением инварианта цикла. Курс учит не просто основам построения алгоритма, но и основам структурного программирования - декомпозиции на процедуры, формулировки пред/постусловий и т.п.
    Более того, во второй части книжки объясняются принципы построения процессора и его работы. И далее описывается простейшая система машинных команд гипотетического процессора - и строится его эмулятор на все том же школьном алгоритмическом языке!!
    По моим впечатлениям, курс построен здорово. По впечатлениям нескольких человек, которые в начале 90-х по нему учились - тоже.

    Так вот, к чему это я? Это я привел пример эталонного "императивного" курса. Который посвящен не "тыканию" формочек и не возне с заморочками конкретных сред, а постановке некоторых общих качеств мышления (каких - об этом ниже!), на базе предельно простого и чистого инструмента - школьной среды КуМир. (Однако КуМир в этом эталонном курсе прозрачно меняется на Блэкбокс. Вплоть до возможности полной имитации первого внутри второго).

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

    Таким образом, в этом случае мы имеем программирование как "базово-инженерный" предмет. Я бы провел тут параллели одновременно с физикой, и с черчением (которое - УВЫ! - всем известные мерзавцы из МинОбра сейчас убрали вообще).

    Теперь обратимся к варианту преподавания программирования на примере функционального языка. Я более чем уверен, что для того же Scheme или Haskell можно сделать прекрасный курс для школьников. Про достоинства подобного подхода, который позволит убрать "ненужную детализацию императивных языков", вы здесь уже говорили.
    Однако давайте теперь подумаем - а какие качества мышления будут развиваться у школьников?
    Специфика, "заточка" ФП предполагает преимущественно прикладной характер задачек. Т.е. если в эталонном "императивном" курсе алгоритмизация рассматривалась сначала сама по себе, как набор управляющих схем, которые визуализировались тем или иным исполнителем, то здесь с самых первых шагов подразумевается подход "задача из смежного предмета (математика, физика, логика) - ее моделирование на изучаемом языке". И мы видим, что ФЯ здесь действительно позволит порешать легче и быстрее гораздо более сложные задачки.
    Но - при этом сформируются уже другие качества мышления: в первую очередь - способность к формальному описанию решаемых проблем в терминах функций, декларативной формулировки цели вычислительного процесса. Это не менее важно, чем качества перечисленные выше - но! - это уже другое...

    Такое программирование становится математическим предметом. Более того, оно очень последовательно продолжает курс математики и может использоваться для закрепления этого курса, для того, чтобы буквально "пощупать" все то, что изучается в теории.

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

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

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

    Если даже язык верстки текста и мат. формул - LaTeX, который преподается всем специальностям физмата, - нынешним первым курсом воспринимается как "китайская грамота", то о чем тут говорить... Они из всей информатики видели в школе только офисные пакеты - И ПРОСТО НЕ МОГУТ ВЗЯТЬ В ТОЛК, как вместо нажатия кнопки и наблюдения воочию мгновенного эффекта можно писать какие-то странные английские слова, и как эти слова связаны с тем визуальным документом, который по ним строится...

    Итого, суммируя... Если ставить обучение в школе как положено, то необходимо изучение трех независимых предметов:
    1) Программирование и вычислительная техника - на основе подобных вышеописанному курсов и инструмента вроде Блэкбокса;
    2) Компьютерное моделирование либо Вычислительная математика - о названии можно подумать - на основе подходящей функциональной среды (Scheme? Haskell? - вам виднее, господа эксперты ФП), в самой тесной связи с изучением разделов математики, как наглядная демонстрация практического применения последних, лучше даже с преподаванием (подготовленными) учителями математики.
    3) Информационные технологии - продолжение "трудов" на компьютере. "Вот, дети, раньше мы вышивали, а теперь в Paintе порисуем" :-)


    № 2873   14-04-2007 16:52 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2858« (Geniepro)
    ___________________________


    Назову некоторые черты ООП: децентрализация, косвенность и обобщение.
    Это настолько общие черты, что их можно легко увидеть и в ФП.


    У меня пока проблемы с децентрализацией в ФП.

    Ну если заранее настраивать себя на то, что ФП - лишь криптография, что ж... Боюсь, тысяч слов будет недостаточно, что бы объяснить хоть какие-то принципы...

    Конечно, "криптографичность" свойственна не ФП (как системе идей), а отдельным нотациям, в т.ч., к сожалению, некоторым ФЯ (но не только; другой пример -- APL).
    Именно поэтому я и решил начать со Схемы.

    Вот как Вы бы организовали обработку событий? С помощью шины сообщений? С помощью активных объектов? Как-то ещё? А что мешает эти же принципы использовать в ФП?

    На практике обработку событий я обычно реализую с помощью очереди событий (как правило, приоритетной).
    Это отчасти связано со спецификой встроенных приложений: позволяет отделить обработку событий от получения данных о событиях в прерываниях.
    Но как мне кажется, использование очереди событий вообще удобный прием.
    Можно спросить у Сергея Перовского, он занимается дискретным моделированием.

    Что мешает использовать то же самое в Хаскеле?
    Это я и пытаюсь выяснить.
    Возможно -- ничего.
    В моих конкретных обстоятельствах требуется эффективно изменяемая структура данных -- очередь.

    А вообще, забавная ситуация: Вы хотите, что бы Вам в нескольких словах объяснили принципы Функционального Реактивного Программирования, но при этом у Вас, похоже, нет особого желания разбираться с просто Функциональным Программированием.

    Откуда такое умозаключение? :)
     AVC


    <<<... | 2892—2883 | 2882—2873 | 2872—2863 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 263


    Добавить свое сообщение

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

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

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

    Перейти на конкретную страницу по номеру
      
    Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

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