OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 11:38

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 127 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7  След.
Автор Сообщение
СообщениеДобавлено: Воскресенье, 20 Февраль, 2011 09:39 

Зарегистрирован: Среда, 24 Декабрь, 2008 07:11
Сообщения: 13
Не совсем по теме, но вот наткнулся на мнение одного товарища (сразу оговорюсь что это больше к железу относится)

"What is essentially a discipline of pure mathematics has come to be called “the
theory of computer science,” and the notion of the algorithm has been decreed
to be a fundamental paradigm of computer science. The mathematical perspective,
however, is the wrong point of view. It is asking the wrong questions.
Mathematicians and computer scientists are pursuing fundamentally different
aims, and the mathematician’s tools are not as appropriate as was once supposed
to the questions of the computer scientist. The primary questions of
computer science are not of computational possibilities but of expressional
possibilities. Computer science does not need a theory of computation; it
needs a comprehensive theory of process expression."


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 20 Февраль, 2011 11:38 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Илья Ермаков писал(а):
Так же, как с реляционными базами. Регулярность, красивая алгебра, но в итоге - "ассемблер", на котором очень жёстко и долго моделировать реальные задачи. А уж модифицировать модель...


Вы просто не умеете их готовить... :D

90% потребностей при разработке прикладных программ покрывается реляционными базами данных. И не поддерживать их в языке - неправильно. А остальные 10% (указатели, объекты) нужны в лишь в очень специфических областях (работа с текстами, управление вычислительными ресурсами, разработка графического интерфейса). Развитие инструментария для 90% потребностей явно отстало. Конечно, диссертацию легче на какой-нибудь экзотике сделать. :wink:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 20 Февраль, 2011 12:08 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
90% потребностей при разработке прикладных программ покрывается реляционными базами данных. И не поддерживать их в языке - неправильно.
Это пока. А завтра изобретут чего получше и уже оно будет покрывать. И засовывать в язык такие фичи --- не правильно.

...Разве щас не начинают переходить на native XML-СУБД?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 20 Февраль, 2011 12:32 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
90% потребностей при разработке прикладных программ покрывается реляционными базами данных. И не поддерживать их в языке - неправильно. А остальные 10% (указатели, объекты) нужны в лишь в очень специфических областях (работа с текстами, управление вычислительными ресурсами, разработка графического интерфейса). Развитие инструментария для 90% потребностей явно отстало. Конечно, диссертацию легче на какой-нибудь экзотике сделать. :wink:


Я соглашусь с последней Вашей репликой про экзотику. Большинство так называемых ООП-баз действительно таково - это громоздкое масштабирование ОО-языка программирования на сторону СУБД и т.п.

Конкретно "настоящими" ОО-СУБД (т.е. "рабочими лошадками") я лично считаю только два направления: мампсы-кэши и решения на базе XML-СУБД и XQuery (что только начинает нарабатываться).

По поводу потребностей я не соглашусь с Вами: если нет представления о возможностях, то иногда нет и потребностей.
А я после компонентного программирования просто не могу смириться с рутиной и невозможностью нормально абстрагировать на базе таблиц. Мне остро нужен и полиморфизм, и виртуализация - потому что берясь за реляционное проектирование, я сразу представляю, насколько я мог бы увеличить повторное использование решений. Например, имея несколько почти похожих частей системы, унифицировать их интерфейс и структуру данных, уточняя только детали.
И я не могу смириться с необходимостью делать 10 раз почти одно и то же, когда я мог бы это привести при ООП к общему знаменателю.
Можно надстроить такие штуки над реляционными базами, да. Но это будет уже не совсем реляционная база, а некий слой объектной поддержки над ней. Так многие делают (в частности, alexus - у него статьи были на эту тему). Но тут уже проще подумать о выборе другой базовой СУБД, нереляционной.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 20 Февраль, 2011 13:43 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Илья Ермаков писал(а):
А я после компонентного программирования просто не могу смириться с рутиной и невозможностью нормально абстрагировать на базе таблиц.


Как-то Вас бросает в крайности - то Вы хотите массивы поэлементно складывать, чтобы представлять себе вычислительную нагрузку, то требуете объектно-ориентированную базу данных. Мне представляется, что с объектами проще "бороться" сериализацией.

А что касается XML-СУБД, то эта вещь будет иметь крайне ограниченное применение, сочетая в себе недостатки XML и СУБД. См. Есть ли будущее у XML-СУБД?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 20 Февраль, 2011 14:27 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Да нормальная XML-СУБД типа Седны внутри совершенно не XML. А просто иерархическая. И, соответственно, никаких недостатков не наследует. И XQuery - язык запросов по иерархическим данным. Формат XML сам по себе не причём. Определено всё на иерархической модели XML InfoSet.

XML же оказывается просто форматом ввода-вывода данных из базы.
Так и на SQL-запрос часто текстом ответ идёт, а потом уже приложением парсится.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Февраль, 2011 00:34 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Илья Ермаков писал(а):
Да нормальная XML-СУБД типа Седны внутри совершенно не XML. А просто иерархическая. И, соответственно, никаких недостатков не наследует. И XQuery - язык запросов по иерархическим данным. Формат XML сам по себе не причём. Определено всё на иерархической модели XML InfoSet.

XML же оказывается просто форматом ввода-вывода данных из базы.
Так и на SQL-запрос часто текстом ответ идёт, а потом уже приложением парсится.

Тогда вопрос, зачем вообще там XML? Чтоб описания интерфейсов в БД засовывать и рисовать с помошью XSLT? Да передачу данных меж системами реализовывать? Мумпс - круче, все эти XQuery,по-моему,маразм типа SQL, если говорить об надстройках. Интерфейс засовывают и в мампсах, а реализовать парсер XML, на М думаю не сложнее, чем на других языках. В Cache все это есть. Но Cache бабок стоит. Хотя есть и бесплатные аналоги.


Последний раз редактировалось Рыжий Понедельник, 21 Февраль, 2011 01:31, всего редактировалось 3 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Февраль, 2011 01:17 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Поделюсь своими впечатлениями о ЯП. Первым внятным ЯП был Фортран-IV. Язык позволял, на тот момент, буквально все на свете. Чего он не позволял легко достигалось отличной интеграцией с ассемблером. Его наследником стал ПЛ/I, который включил в себя практически все фичи Фортрана и прибавил структуры и базированные переменные( указатели, которые в нем же впервые и появились), еще в язык была включена масса дополнительных фич, но, в целом ПЛ/I - наследник Фортрана. В период наиболее активного использования ПЛ/I , Фортран прочно занял нишу вычислительных задач, так как для бизнес-приложений ПЛ/I подходил больше( мы не говорим тут о Мампсе и Коболе, как более специализированных инструментах). В связи с миниатюризацией ЭВМ, на поверхность всплыла ветка рекурсивных языков , вроде Паскаля, развитого и пропагандируемого Дейкстрой с Виртом. ПЛ/I включал в себя все необходимое для структурного программирования, потребность в деятельности школы Дейкстры-Вирта , вообщем-то отсутствовала и эта деятельность не стала бы так заметна, если бы не миниатюризация и сложности реализации тарнсляторов ПЛ/I и Фортрана на таких микро-эвм. Вот тут то и подоспели работы Вирта и Дейкстры. В результате Фортран остался на мейнфреймах, ПЛ/I постепенно был вытеснен паскалем, фоксбейсом и электронными таблицами. Параллельно с этим происходило вытеснение иерархических БД реляционными. Концепция РБД аналогична концепции Виртовских "записей" - объединение связей с данными в одну коробку. Все эти идеи возможно рассмотреть с точки зрения понятия - отношения. На тот момент, многим из программирующего сообщества показалось, что это немерянно круто. Мечталось о снижении математической нагрузки на алгоритмизацию. Параллельно существовали мини языки вроде Бейсика( и его многочисленных клонов) - удачные варианты больших языков первой линейки, адаптированные для более удобного приминения в быту, играх и т.п.
В конечном счете рекурсивно-ориентированные языки : Паскаль и С вытеснили все остальные. Тоже произошло с Мампсами, Диамсами и т.п. в области СУБД. Далее выяснилось, что приматический элемент, послуживший причиной распространения С-Паскалей ( к чему бы там не стремились Вирт с Дейкстрой в своих заблуждениях) привел к необычайному усложнению языкового окружения, проявления этого мы видим буквально во всем. Кроме того, идеи Дейкстры-Вирта, возможно помимо их воли, развиваясь привели к возникновению огромного количества малоотличающихся по сути, но несовместимых технологически концепций, лавинообразному языкотворчеству, и громадному количеству несвместимых форматов данных. Также это сказалось на понимании концепций пользовательского интерфейса. В СССР это заболевание протекало особенно остро, из-за отсутствия хорошей литературы. Например по тому же QuickBasic , большинство программирующих лиц считало, что Бейсик замер на уровне СМ-1. Парадоксально, но ПЛ/I не умер. Он вернулся к истокам, а именно в - Фортран. Поздние стандарты Фортрана впитали в себя все наработанные в языках первой линейки идеи. И на сегодняшний день мы имеем процесс конвергенции этих концепций и лидером в этом процессе является все тот же Фортран. Сдесь мы, совершенно, не видим того хаоса, который порожден Виртовско-Дейкстровой деятельностью. Точно так же современные Бейсики (за исключением MS) впитали в себя все лучшее , что имеется на сегодня в ЯП, вто же время, сохранив верность старому идеалу. В сфере CУБД, Cache и прочие аналоги Мампса, занимают очивидную выгодную позицию по отношению к РСУБД, и лишь необходимость поддерживать настроченные в реляционном дурмане БД и приложения, тормозят переход к старым формам СУБД в их новом обрамлении.

Да здравствует Фортран,Бейсик и Мампс!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Февраль, 2011 01:39 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Одно дело когда такие штуки включаются в язык естественно, и совсе другое когда становятся его доминантой. Это, как мы видим, ведет к лавинообразным последствиям.
Одно дело надстройка и совсем другое - базис. Базис оказался крайне привлекателен и страшно узок, отсюда лавинообразный рост версий, клонов, добавлений, форматов и т.п.
Как в ЯП так и в СУБД. Конечно это объясняется приматизмом. :D Но у истоков стояли именно Вирт с Дейкстрой, переоценившие силу концепции и недооценившие мощь приматизма.
Именно поэтому у Оберона нет и не может быть массового распространения. Но пусть не радуются поклонники SQL, С++, Net и Java. У них никакого будущего нет вообще. :lol:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Февраль, 2011 09:26 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Рыжий писал(а):
Поделюсь своими впечатлениями о ЯП. Первым внятным ЯП был Фортран-IV. Язык позволял, на тот момент, буквально все на свете. Чего он не позволял легко достигалось отличной интеграцией с ассемблером. Его наследником стал ПЛ/I, который включил в себя практически все фичи Фортрана и прибавил структуры и базированные переменные( указатели, которые в нем же впервые и появились), еще в язык была включена масса дополнительных фич, но, в целом ПЛ/I - наследник Фортрана.

Не соглашусь. В ПЛ-1 было ДОФИГА из Кобола (я писал и на том, и на том).
Кроме того, самой непрятной чертой ПЛ-1 были неявные преобразования типов - это УЖОС!
Вирт поступил совершенно правильно, все по умолчанию запретив. Надежность от этогог резко повысилась, поскольку программист теперь должен подумать и написать явно, чего он хочет.
В С++ - та же беда - по умолчанию все разрешено. Вот и лезут конструкторы, когда их никто не просит.
Вот на РСДН задали вопрос: а что, невозможно изменить размер вектора без обнуления по умолчанию?
Невозможно! А это - сотни тысяч команд - быстродействие сильно страдает.
Поэтому я Вирта поддерживаю: нефиг все позволять. Гораздо лучше - все запретить, и пусть думает, что ему реально нужно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Февраль, 2011 10:03 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
В ПЛ/I много от чего есть, в т.ч. и от Кобола, но основа по-моему мнению Фортран.
Цитата:
Поэтому я Вирта поддерживаю: нефиг все позволять. Гораздо лучше - все запретить

Приматизм рулит всегда, но, при наличии особенно жесткой концептуализации, приматизм рулит особенно сильно. Так как приходиться изворачиваться и комбинировать в специфических условиях диктуемых концепцией. Пример тому все что Вы видите вокруг в Путинской России. :D
Цитата:
и пусть думает, что ему реально нужно.

Представляю, что он себе надумает. :D
Цитата:
Кроме того, самой непрятной чертой ПЛ-1 были неявные преобразования типов

В ПЛ/I есть операторы контроля типов.
Цитата:
В С++ - та же беда - по умолчанию все разрешено.

А вот это , как раз, последствия "надумывания".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Февраль, 2011 03:27 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Вот отличный сайт посвященный fortran-у:
http://www.izhfortran.narod.ru/


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Февраль, 2011 16:39 

Зарегистрирован: Среда, 30 Сентябрь, 2009 14:45
Сообщения: 147
Рыжий писал(а):
Поделюсь своими впечатлениями о ЯП.
...
Да здравствует Фортран,Бейсик и Мампс!

Но не раскрыта тема Первой Мировой войны ЯП:
а именно - прежде чем лечь костьми под паскаль фортран наголову разбил все наезды алгола.
За алгол была вся Европа, СССР, Международная федерация с Хоарами, Виртами и прочими Вейнгартенами.
За фортран был американская наука.

Фортран был напичкан особенностями, несуразностями, эдхоками.
Алгол был прост, логичен, эстетичен.

Фортран победил по совсем простой причине - он был модульный (в алгоритмах и данных).

А насчет мини ему перебежал дорогу бейсик. Фортран (если причесать) был бы не хуже.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Февраль, 2011 21:30 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
"СССР, Международная федерация с Хоарами, Виртами и прочими Вейнгартенами." - это не "вся Европа". Это именно то что перечисленно. Международная федерация судя по всему состояла как раз из Вирта , Хоара и прочего Вейнгартена с некоторые сотоварищи. Естественно они получили по мозгам, ибо фортран всю дорогу успешно использовался. Фортран никак не мог быть "не хуже бейсика" т.к. они имеют несколько разную ориентацию и возможности, несмотря на принадлежность к одному семейству. Впоследствии эти лица под предводительством Дейкстры выдумали "кризис" и предложили якобы решение. Об этом в теме и говорится. Не надо наводить тень на плетень. :D Вот у меня книженция, глава "отношения в базах данных и структурах данных".То что я подчеркивал выше. Впрочем, Вы предложили не контраргумент, а приятное дополнение. :D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Март, 2011 11:11 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Вообщем, преимущества гипертекстового интерфейса ББ запросто переносятся куда угодно. Например в Delphi (собственно в Windows) такой интерфейс реализуется просто. Я например организовал на основе Rtf. Полагаю, что перенести это в фортран не составит труда. Вопрос тогда, где преимущества ББ, перед фортраном?
Изображение
То же самое легко и со сносками, причем в двух видах : как хинты или как вставка текста(как в ББ).
А уж с канвой, кнопками и встроенными компонентами писано переписано. Можно легко например любой RichEdit на любую канву скопировать например, ну и т.п. Вообщем , обычный RichEdit и немного сообразительности - и будет интерфейс ББ. :D
Для Ртф - документа сделать общий метод ScanRtfDoc,вызывающий ApplyLinks, ApplyHints и т.п. (в зависимости от установки булевых свойств) Ну а интерактивность в соответствующих событиях RichEdita, при ,например, GetMove(Link\Hints...)<>nil и стало хорошо. :D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Март, 2011 13:20 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Вообще непонятно зачем всю эту хрень изобрели типа XML. В ртф можно вставить любые неотображаемые теги с любой вложенностью, и обрабатывать их внешним образом как угодно, по любым правилам. В HTML хочешь преобразовать - вызвал метод сохранения SaveAS HTML и все дела. И никакого XML\XSLT. SGML - рулит. Поражает тупизм. :mrgreen:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Март, 2011 16:48 

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
И вообще , все такие среды любой школьник может за пару месяцев настрочить. Сунули туда компилятор ресурсов, windows.h перестрочили, зашифровали формат обогощенного текста, процедур Doc-View понастрочили, настроек понапихали - и дело в шляпе. :D Главное в нашем деле все зашифровать и подать в красивой оболочке, чтоб никто не догадался. Расширения там поменять у файлов и т.п. :mrgreen:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Март, 2011 17:14 

Зарегистрирован: Среда, 30 Сентябрь, 2009 14:45
Сообщения: 147
Рыжий писал(а):
Поражает тупизм. :mrgreen:

В Ваших предложениях отсутствует главное - бзик.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Март, 2011 18:47 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Рыжий писал(а):
Вообще непонятно зачем всю эту хрень изобрели типа XML. В ртф можно вставить любые неотображаемые теги с любой вложенностью, и обрабатывать их внешним образом как угодно, по любым правилам. В HTML хочешь преобразовать - вызвал метод сохранения SaveAS HTML и все дела. И никакого XML\XSLT. SGML - рулит. Поражает тупизм. :mrgreen:

Я тоже никогда не мог понять, нафига коту баян? Очередной сруб бабла?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Март, 2011 19:15 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Валерий Лаптев писал(а):
Я тоже никогда не мог понять, нафига коту баян? Очередной сруб бабла?
Это всегда должно быть первой гипотезой. Конечно, зацикливаться на этом (как Стариков и Ко. на англосаксах) не нужно. Просто как первое предположение.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 127 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 7


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB