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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение. 

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

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

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


Всего в теме 6256 сообщений

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

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

Обсуждение из раздела
Школа ОБЕРОНА

<<<... | 3516—3507 | 3506—3497 | 3496—3487 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 276


№ 3506   25-03-2007 09:47 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3461« (AVC)
___________________________

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


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

у меня архиватор использует 5-10 потоков. данные между ними пережаются через каналы, за исключением двухз переменных. одну из них я обернул в синхронизатор, другая (статистика UI) осталась как есть :D

оборачивание переменной в синхронизатор MVar выглядело так (File - это исходный тип до оборачивания, file* - операции над ним):

-- |Архивный файл, заворачивается в MVar для реализации параллельного доступа из разных тредов ко входным архивам
type Archive        = MVar File
archiveCreate        = returnMVar . fileCreate
archiveOpen          = returnMVar . fileOpen
archiveGetPos        = liftMVar1 fileGetPos
archiveGetSize      = liftMVar1 fileGetSize
archiveSeek          = liftMVar2 fileSeek
archiveRead          = liftMVar2 fileRead
archiveReadBuf      = liftMVar3 fileReadBuf
archiveWrite        = liftMVar2 fileWrite
archiveWriteBuf      = liftMVar3 fileWriteBuf
archiveClose        = liftMVar1 fileClose

вообразите то же самое на яве :)))


запуск дополнительных процессов для выполнения вспомогательных задач выглядит вообще до неприличия простым. вот кусочек, запускающий треды, которые осуществляют отдельные шаги алгоритма упаковки и передат частично обработанные данные дальше (в точности по принципу юниксовских пайпов!):

case compressor of
  [a]    ->  storing_PROCESS |> compressP a
  [a,b]  ->  storing_PROCESS |> compressP a |> compressP b
  [a,b,c] ->  storing_PROCESS |> compressP a |> compressP b |> compressP c

здесь storing_PROCESS и compressP - процедуры, запускаемые в создаваемых тредах. причём обратите внимание - это всё чисто императивное программирование, просто с цункциоланльным пододам к композиции алгоритма, в данном случае - из отдельных тредов в точности так же, как это делается в эниксе :)))


№ 3505   25-03-2007 09:24 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3504« (Булат Зиганшин)
___________________________

мне представляется, что идеи шли по линии smalltalk->objc->objpascal->delphi->c#. ява же непосредтсвенно из objc (и разумеется, ява оказала первоочередное влияние на c#). во всяком случае, эти технологии были более популярны, чем оберон, и спцифически обероновских особенностей, типа отказа от ООП, в c#/яве не наблюдается.

Булат, еще небольшой штрих к вопросу о корректности и мифотворчестве.

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

Если брать C++, Objective C, Java и C#, то источником их идей были работы Xerox PARC (примерно с 1970 по 1990 гг.), а также, пожалуй, самой тогда мощной по своей инфраструктуре сети исследовательских лабораторий компании DEC (Digital Equipment Corp., потом просто Digital). Той самой, что известна миру по своими PDP-11 и VAX-11, ОС VAX/VMS, OpenVMS и процессором Alpha. Той самой, которую сначала скушала Compaq, а потом эту Compaq -- HP. Народ оттуда (как, кстати, и из Xerox PARC) порастащил все тот же самый Microsoft.

Так вот помимо Smalltalk в Xerox PARC делались также Mesa, Cedar. Ну а в DEC Systems Research Center -- Modula-3. Smalltalk не имел прямых европейских аналогов (разве что норвежская Симула-67), а вот Mesa и Cedar имели: Modula-2 и Oberon. Интересно, что в случае Modula-2 направление творческого заимствования идей (Modula-3) пошло в другом направлении: из Европы в Штаты. Хотя там команда Грега Нельсона и Билла Калсова в контексте той задачи, которая ставилась, поработала на славу: получился монстр масштаба Ады, но при этом сохранивший дух и элегантность Модулы-2.

Благодаря такому параллельному развитию исследований в лучших языках 1970-1990 гг. по обе стороны Атлантики у американцев есть великий соблазн говорить только о своих, американских работах. И они перед этим соблазном не могут, разумеется, устоять. Скажите, Вы где-нибудь читали о том, что Хоар имел какое-то отношение к зарождению идей ООП? Хотя бы в той же Европе? То-то и оно. На мир мы смотрим через очки американцев. А неплохо бы рассуждать самостоятельно.

Хочу еще раз вернуться к тому, что здесь в Королевстве уже обсуждалось. Раз речь зашла об истоках Java, хотел бы внести уточнение. Поскольку нередко можно встретить слова о том, что Java "содрана" с Oberon. Конечно, это не так. Java создавалась под влиянием Оберона. Известна история с лицензированием системы Oberon и выступлнием Франца в SunLabs. Это факты, подтверждающие источники прямого интереса создателей технологии Java (к которой руку приложил не один Гослинг). Но влияние -- вещь эфемерная. Чтобы не было упреков в передергивании, приведу цитату Бьерна Страуструпа (2000): Clearly, Java borrows from C and C++, but under the skin, the similarities to Modula-3 seem greater. http://www.gotw.ca/publications/c_family_interview.htm

Так что автор C++ признает большое влияние на создание Java со стороны языка Modula-3 ( http://en.wikipedia.org/wiki/Modula-3 ), который создавали в DEC Systems Research Center при участии Olivetti Research на основе языка Modula-2, т.е. прямого предшественника Оберона. Это достаточно убедительно говорит об истинных корнях языка Java. Что касается Java-браузера и аплетов (главной точки раскрутки Java в 1995 г.), то здесь факт прямого заимствования из системы Oberon налицо.


№ 3504   25-03-2007 08:51 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3502« (Илья Ермаков)
___________________________

Ответ на »сообщение 3499« (Булат Зиганшин)
___________________________

Ответ на »сообщение 3497« (Руслан Богатырев)
вот когда вы говорите, что какие-то вещи есть только в обероне, а в C++ их нету, вспминайте про эти языки тоже. gc, dynamic loading, компонентное программирование. вы ведь знаете возможности этих языков?
ObjC, про который я немного читал, видимо, интересная штука - у него старая история... Увы, не знаком с ним даже "шапочно", нет возможности и времени...

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

Над Шарпом-Нетом работали некоторые люди из Паскаля/Оберона. Клеменс Шиперски - один из первых разработчиков Блэкбокс. Про Андре Хейлсберга (автор Дельфы) все, наверное, знают.
Более того, даже технически Блэкбокс является предтечей .NET - я это увидел воочию, когда перерабатывал его ядро - и параллельно читал Рихтера про особенности реализации .NET.
Однако приличная часть перспективных идей из ББ в .NET не пошла. Например, графический Framework развит из идей VCL, а не из составных документов ББ.


мне представляется, что идеи шли по линии smalltalk->objc->objpascal->delphi->c#. ява же непосредтсвенно из objc (и разумеется, ява оказала первоочередное влияние на c#). во всяком случае, эти технологии были более популярны, чем оберон, и спцифически обероновских особенностей, типа отказа от ООП, в c#/яве не наблюдается.

ну и далее - если оно и заимствовано из оберона, то какое это отношение имеет к сравнению *современных* языков? так у вас получится, что алгол и фортран - до сих пор остальись лучшими языками, поскольку вы их будете сравнивать только с автокодом ;)

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


№ 3503   25-03-2007 07:51 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3499« (Булат Зиганшин)
___________________________

вот когда вы говорите, что какие-то вещи есть только в обероне, а в C++ их нету, вспминайте про эти языки тоже. gc, dynamic loading, компонентное программирование. вы ведь знаете возможности этих языков?

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

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


№ 3502   25-03-2007 07:48 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3499« (Булат Зиганшин)
___________________________

Ответ на »сообщение 3497« (Руслан Богатырев)
вот когда вы говорите, что какие-то вещи есть только в обероне, а в C++ их нету, вспминайте про эти языки тоже. gc, dynamic loading, компонентное программирование. вы ведь знаете возможности этих языков?

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

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

Над Шарпом-Нетом работали некоторые люди из Паскаля/Оберона. Клеменс Шиперски - один из первых разработчиков Блэкбокс. Про Андре Хейлсберга (автор Дельфы) все, наверное, знают.
Более того, даже технически Блэкбокс является предтечей .NET - я это увидел воочию, когда перерабатывал его ядро - и параллельно читал Рихтера про особенности реализации .NET.
Однако приличная часть перспективных идей из ББ в .NET не пошла. Например, графический Framework развит из идей VCL, а не из составных документов ББ.


№ 3501   25-03-2007 07:48 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3500« (Илья Ермаков)
___________________________

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

Ответ на »сообщение 3491« (Илья Ермаков)
___________________________
Кстати, в последнее время намечяется тенденция к переходу от компонентного программирования к метапрограммирования - к софтверным фабрикам всяким, что-то типа макросов в Лиспе да новомодном Немерле.
Что думают наши оберонщики об этом?
По поводу Немерле - я не в курсе, кроме того, что вроде бы синтетический язык в плане ФП/ИП.

У Оберона есть приличный ресурс по развитию в плане метапрограммирования. Однако пока "потолок" ставится конкретными реализациями. Для поднятия этой планки нужен, в частности, уход на JIT и особые промежуточные представления (например, развивающие Франца). Тема интересная, но пока по ней работы, вроде бы, никем не ведутся...


макросы в обоих языках - это кодогенерация во время компиляции, никакого отношения к RTS средствам она не имеет. немерле похож на C# - ООП язык с ФП надстройками типа лямбда-выражений и выведения типов


№ 3500   25-03-2007 07:40 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3498« (Geniepro)
___________________________

Ответ на »сообщение 3491« (Илья Ермаков)
___________________________
Кстати, в последнее время намечяется тенденция к переходу от компонентного программирования к метапрограммирования - к софтверным фабрикам всяким, что-то типа макросов в Лиспе да новомодном Немерле.
Что думают наши оберонщики об этом?

По поводу Немерле - я не в курсе, кроме того, что вроде бы синтетический язык в плане ФП/ИП.

У Оберона есть приличный ресурс по развитию в плане метапрограммирования. Однако пока "потолок" ставится конкретными реализациями. Для поднятия этой планки нужен, в частности, уход на JIT и особые промежуточные представления (например, развивающие Франца). Тема интересная, но пока по ней работы, вроде бы, никем не ведутся...


№ 3499   25-03-2007 07:39 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3497« (Руслан Богатырев)
___________________________

Т.е. для сложных системных вещей C++ противопоказан. Для прикладных -- есть куда лучше и надежнее варианты. Остается что -- производительность? Мы будем здесь сравнивать производительность C и той же Modula-2 с C++ или не стоит?


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

>>можно тогда ожидать от вас сравнения Оберон не только с С++, но и с objc/c#/erlang?

Сравнения по каким критериям и по какой методике? Боюсь, мы все чаще сравниваем бананы с попугаями. :)


вот когда вы говорите, что какие-то вещи есть только в обероне, а в C++ их нету, вспминайте про эти языки тоже. gc, dynamic loading, компонентное программирование. вы ведь знаете возможности этих языков?


№ 3498   25-03-2007 07:33 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3491« (Илья Ермаков)
___________________________

В целом это обсуждение еще раз показывает разницу между мышлением специалистов, "заточенных" под разные задачи. У Вас, по-видимому, четко выраженное математическое мышление. А мы (я, Руслан, AVC...) - технари-системщики :-)

Да я тоже, вобщем-то, технарь, только я привык больше к Си и Паскалю, чем к Оберонам...
Несколько лет назад (ок. 8 где-то) мне попался Oberon-M - было интересно, но там даже плавающей арифметики не было, и операторв FOR тоже... :о)

А ФП вообще только последние полгода интересуюсь. Представляете, до того, как я узнал о Хаскелле, я больше интересовался Занноно и его активными объектами... :о))
____________

Кстати, в последнее время намечяется тенденция к переходу от компонентного программирования к метапрограммирования - к софтверным фабрикам всяким, что-то типа макросов в Лиспе да новомодном Немерле.

Что думают наши оберонщики об этом?


№ 3497   25-03-2007 07:33 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3495« (Булат Зиганшин)
___________________________

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

Ну если в этом смысле, то связка конечно есть (с чего бы ей не быть, если ее и строили). Паразитирование C++ и ставило целью создание такой связки. Потом, правда, произошла досадная рассинхронизация. Тот же Страуструп, увидев до какой степени обогащения доведено его же детище, признался: "Моим идеалом по-прежнему остается единый язык, и техническая возможность достаточно логично слить С++ с C99 пока сохраняется. На мой взгляд, такой язык мог бы соответствовать любым разумным техническим условиям. Однако я не уверен, что это приемлемо политически". Разработчики UNIX (про Томпсона и Ритчи помолчу, они уже молвили "доброе" слово в адрес C++ и того же Linux) стараются четко разграничивать C и С++ (вроде как не лезьте к нам со свиным рылом в калашный ряд). Возвеличенный до неприличия Линус Торвальдс и тот кроет C++ на чем свет стоит. Т.е. для сложных системных вещей C++ противопоказан. Для прикладных -- есть куда лучше и надежнее варианты. Остается что -- производительность? Мы будем здесь сравнивать производительность C и той же Modula-2 с C++ или не стоит?


<<<... | 3516—3507 | 3506—3497 | 3496—3487 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 276


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

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

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

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

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

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