OWL2, XML и все-все-все

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

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

А воровство он не оправдывает. Даже напротив. Он не одобряет пиратство. Жить надо по законам. И менять нужно сами законы.

> Столлмана надо за одно это прибить, за то, что его абстрактными идеями оправдывают банальное воровство.

Urix, залогиньтесь...

> И вообще, в головах адептов Столлмана каша. Из правильного по сути постулата "патенты тормозят прогресс" они делают офигительный по простоте вывод: "надо всё взять и поделить".

Столлман считает, что программы с открытым исходным кодом надо именно *продавать*. А то, что сейчас они 99.9% бесплатно -- это кхм... тебе повезло.

Однако он до сих пор не опубликовал аналог GPL, в которой была бы четко обозначена royality. И это конечно упущение. И это надо исправить.

> MathML,SMIL,WSDL и не предназначены для того, чтобы их кто-то "видел".

Да что ты говоришь. Ознакомься сначала с MathML и SMIL, а потом уже будешь сувать их в одну кучу с WSDL.

> Вот так и с MathML, если _ты_ ни разу никогда им не пользовался это не значит, что его нет и оно никому не нужно

Ну дык покажи мне хоть один браузер, который поддерживает MathML нативно.

> на тему Web-онтологий

сначала прочитал как "на тему Web-онотолей"... долго думал

а вобще "антология", конечно

> > на тему Web-онтологий

> сначала прочитал как "на тему Web-онотолей"... долго думал

> а вобще "антология", конечно
> anonymous (*) (09.02.2009 9:58:39)

http://ru.wikipedia.org/wiki/Антология
http://ru.wikipedia.org/wiki/Онтология

За "всё-таки перечитал, потом написал" - +1.
Ждем "подумал - потом написал".

>Ну-ка положи мне алгоритм быстрой сортировки на объекты. Или замути редукцию графов.

Сортировка это алгоритм! Алгоритм это описание какого-то процесса - следовательно это метод.

Тогда про методы:

Методом какого объекта является функция вида: соединиться(сервер, приложение, объект-для-передачи-приложению)?

Или даже простая операция <.

А ещё: как адекватно представить в виде объекта, например, https://svn.musicpd.org/mpc/trunk/doc/mpc-bashrc

Это _данные_ для bash-completion, но не объект (и даже не метод чего-либо). В общем, конечно, можно и в объекты всё попытаться упаковать. Microsoft со своим Power Shell это успешно доказала :-) Но не всё адеватно на них ложится.

В простых терминах (не будем о функциональщине, поговорим о быдлокодинге):
дело в том, что обработка информации (или конкретная функция, программа) - всегда ограничена ресурсами, будь то обработка видео, графики, большого количества информации или юзеров - хотя-бы потому что в отличие от случая сферических коней в ваккуме - скорость процессора, скорость кеша, памяти, диска, сети отличаются на много порядков, а объём ресурсов/данных - точно также, только обратно пропорционально. Поэтому думать об объектах вначале - не только бесполезно, но и вредно (начальное разбиение - как-бы это сделали далёкие от программирования люди - скорее всего неэффективно изначально, не учитывается структура данных, их локальность и прочее - если начинать с обьектов и кончать функциями).
И наоборот - размышеление о потоках данных, объёмах, джойнах, и только по мере надобности - добавление структур/обьектов - единственно-эффективный путь.
Сколько я видел завалов проектов, когда обьектники настроят хибернейтов или других ОРМов, а потом оказывается что вместо 2 запросов+2 апрейтов на страницу с минимально-необходимым суммарным количеством байтов которые должны пройти через ИО (сеть), скажем, 1024 - максимум, - объектники либо прокачивают почти гигабайт данных через сеть, вызывают один селект на страницу раз 10 - на порядок больше и подобное, хотя немного более сложный джойн в базе сделает это на порядки эффективнее. Не говоря про локи и прочее. Проблема в непонимании архитектуры машин, в непонимании того что делает база, как, и итд. Итог - завальные проекты почти везде. То-же с EJB.
Программирование же - это написание функций (т.е. не что, а _как_), а не рисование картинок (кто-то должен всё равно писать _как_, и скорее всего методы о которых думаете - будут вызываться слишком часто, неэффективно, появится избыточность дорогих запросов и данных которые обязательно вас убьёт из-за несимметричности архитектуры и различия скорости памятей во много порядков).
Чуть сложнее проект - и нужна эвристика, магия, чутьё - что делать с данными, как укладывать алгоритмы, и объекты там - последнее дело. Просто бесполезное. Всё равно придётся имплементировать. Но потом неправильное разбиение - почти наверняка даст вам в печень.

Ну незнаю как можно такое не положить на объектную модель

>Методом какого объекта является функция вида: соединиться(сервер, приложение, объект-для-передачи-приложению)?

class Prilada {
  private URL server;
  private Object data;
  private ещё много чего для работы
  public void connect() {...}
  public void transfer() {...}
}

>Или даже простая операция <.

А как в ЦПП переопределяются операторы?

>А ещё: как адекватно представить в виде объекта, например, https://svn.musicpd.org/mpc/trunk/doc/mpc-bashrc 

URL наверное, или если хочешь чего поинтереснее, то можно описать объект который самзнает как себя (и свои данные) высасать через сетку

>Сколько я видел завалов проектов, когда обьектники настроят хибернейтов или других ОРМов, а потом оказывается что вместо 2 запросов+2 апрейтов на страницу с минимально-необходимым суммарным количеством байтов которые должны пройти через ИО (сеть), скажем, 1024 - максимум, - объектники либо прокачивают почти гигабайт данных через сеть, вызывают один селект на страницу раз 10 - на порядок больше и подобное, хотя немного более сложный джойн в базе сделает это на порядки эффективнее. Не говоря про локи и прочее. Проблема в непонимании архитектуры машин, в непонимании того что делает база, как, и итд. Итог - завальные проекты почти везде. То-же с EJB.

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

Как пример, у меня на работе сейчас разрабатывают проект на пять лимонов и архитекторы такого наворотили , что просто хочется плакать от безысходности. Потому что те технологии, которые они заставляют всех использовать совсем не стыкуются с задачами, под которые эти технологии были рассчитанны. Так, что проблемма не в объектном подходе а в изначальном понимании задачи и выборе адекватных технологий под эту задачу.

ещё примеры того что объекты - не важно. Редактор. Документ. Как документ имплементировать будем? (надеюсь - что не каждая буква объект;) Но ведь надо подсветку! Курсор. Слово? А если откроем 1Г-геном человека в нём (одно слово из 4 букв)? Если памяти меньше чем документ? А если данные удалены и только кусочек надо показывать? Индексирование чего? Итд. Для любого подобного требования (который может появиться на любом этапе или просто прийти со временем) - нужна полная перекройка объектов, потому-что ни объекты, ни методы не только не дадут пользы, но и заставят неправильно думать. Потому-что думать придётся о смещениях, об эффективной индексации, вопросе где это делать, стримах, каком-нибудь инкрементальном парсинге (не придираться - не в этом суть здесь) - но не об объектах. Объекты - последнее.
Другой пример. Обработка данных. Чувак написал прогу на быдлоязыке модифицирующую большие данные. Работало сутки. Потому что обьекты, файлы, ..., и как ему казалось. На Ц стоило просто заместить маленькие стринги без копирований - уложилось в 5 минут.
Третий пример. хмлщики ваяют хмл-г... для которого нужен суперкомпьютер (даже саксом не пользуются, стервецы, - всё в свои дом-объекты ложут). Памяти им 4Г конечно не хватает и процессоров надо больше 8. Обычная персоналка молотит седом за милую душу с одним процессором гораздо быстрее. (юниксовые пайпы- отдельный разговор).
А сколько примеров когда элеметарный файл на несколько гигабайт поправить не могут. Зато объекты, блин. Да для нормального программиста нет разница - что структура, что объект, что массив, что кусок в памяти - главное задачу сделать (читай - реализовать алгоритм/функцию, а где данные хранить - по ходу придёт.

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

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

С чем конкретно не согласен?

я считаю - проблему создали Бучи, Гаммы, кормящие их ибмы (за счёт бабок выбитых за лицензии с дураков), саны и микрософты, вернее их менагеры и кормящиеся вокруг.
Возведя объекты в абсолют. Хотя они - ничто в сравнении с алгоритмами, функциональщиной.
(а ведь Буч конкретно наехал на алгоритмический подход, обьявив свой объектный подход более прогрессивным).

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

ладно, спать пойду.
Больное место.
А не то опять буду наезжать на жабо-очереди, на веб-сервисы итд. А это - надолго.

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

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

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

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

>ещё примеры того что объекты - не важно. Редактор. Документ. Как документ имплементировать будем? (надеюсь - что не каждая буква объект;) Но ведь надо подсветку! Курсор. Слово? А если откроем 1Г-геном человека в нём (одно слово из 4 букв)?

На примере редактора с подсветкой можно предложить следующую объекты:
Базовые классы: редактор, документ, парсер, хайлайтер
Расширения:
ХМЛ
редактор - wyswyg редактор,
документ - текстовый документ
парсер - хмл парсер
хайлайтер - хмл хайлайтер
Графический
....

А насчёт быдлоязычков, так я на небезизвесном обйектно ориентированном быдлоязычке написал небольшую такую гуёвину, которая показывает таблицу из более 10 миллионов строк и как ни странно от запроса показать данные до полностью отрендеренной картинки с данными проходит не более 50 милисекунд(!), и это включая простой запрос на базу данных. Там и динамическая подгрузка данных, и освобождение памяти, и представление данных с картинками и рюшечками, только блядей не хватает. Так что не надо обсирать концепцию а надо просто правильно её применять.