Цитата:
В вашем комментарии словосочетание «объектно-ориентированное программирование» можно заменить на любую другую изучаемую технику
В том то и дело что не любую другую. Многие другие технологии имеют рациональный инженерный и научный подход. И решают какие-либо проблемы. ООП не решает никакие проблемы, только создаёт. Это сугубо гуманитарная штука, как отмечено в комментарии ниже.
цитата:
Если реализацию можно использовать, использую обычную агрегацию, то подстановку объектов разных классов по одному интерфейсу в большинстве языков со строгой типизацией без наследования не сделаешь.
Согласен, если никак по-другому не сделаешь, приходится наследовать. Но тут от наследование скорее не польза, а неизбежный костыль. В некоторых языках со статической типизацией эта проблема решена без наследования.
Основная сложность при изучении объектно-ориентированного программирования (или любой другой парадигмы программирования) заключается в том, что весьма сложно подобрать формальные критерии, которые бы сказали: «ок, теперь я знаю ООП и стану писать более клевые (читай модульные, реюзабельные и легкие в сопровождении) программы».
Та же проблема в астрологии. Такая же астральная штука, в которой никто не понимает зачем она нужна и как именно помогает писать клёвые программы, но считает что просто ещё не достиг просветления
Единственная польза — структуризация программы. Но того же эффекта можно достичь просто грамотно разделяя продцедуры на модули в процедурном программировании. Да хотя бы просто логически сгрупировать процедуры в исходнике — абсолютно тот же эффект без оверхэда на булшит.
Ну и наследование. Хотя никто не может объяснить какая от него польза в реальном продакшене. Ну да, можно определить базовый класс и от него наследовать. Единственная польза от этого это то, что можно определить базовый класс и от него наследовать. Это не какой-то универсальный метод и ничем обычно реально не помогает. Просто какой-то абсурдный частный случай.
p.s. Да, я в курсе что я ещё не просветлел, у меня мало опыта и вообще низкий уровень интеллекта. И, разумеется, зря противоречу постулатам, которые намертво выжжены в подкорке опытных С++ и джава программистов.
а непосвященные замирают с открытыми ртами при виде такого таинства программирования.
Ага, щас. Точно так же будет подходить начальство и спрашивать «когда». А при знакомстве, узнав что ты программист все будут точно так же с покерфейсом говорить «понятно».
Там тоже не учат, например, математику. А учатся отвечать на вопросы егэ по математике.
(для школофобов напомню что егэ начали экспериментально вводить с начала нулевых)
Хотя конечно полезно когда все в команде гарантировано знают какой-то общий стандартизированный набор понятий из области программирования.
Наверное отбирать огромное кол-во эффективных специалистов это очень трудная работа. Интересно, каков процент непрохождения испытательного срока.
> При последнем трудоустройстве я прошел собеседование (4 человека собеседовали), затем тестовый день (в который я выполнил задание, которое должен был выполнить за неделю), затем мне предложили пройти у них еще тестовую неделю-две т.к. 1 тестовый день все же мало (бесплатно), а потом, если пойдет работа — начнется испытательный срок длительностью от месяца до трех.
> При последнем трудоустройстве я прошел собеседование (4 человека собеседовали), затем тестовый день (в который я выполнил задание, которое должен был выполнить за неделю), затем мне предложили пройти у них еще тестовую неделю-две т.к. 1 тестовый день все же мало (бесплатно), а потом, если пойдет работа — начнется испытательный срок длительностью от месяца до трех.
Sql это частный случай той логики запросов, которую реализует пролог. Поэтому не каждая конструкция пролога может быть преобразована в запрос sql.
Если есть такой «bridge», то он на задание рекурсивных предикатов должен создавать в rdbms рекурсивную хранимую процедуру.
Для своих задач я бы не отказался от такой штуки.
Да и вообще, использование datalog вместо sql может сильно упростить жизнь. Например, писать foo(A,X1),bar(X1,X2),baz(X2,B). намного проще чем делать двойной join.
Простейшая имплементация конечно простейшая, но нужны ещё стандартные предикаты, типы данных, многопоточность и ещё куча сложностей.
Да, именно для java есть очень много встраиваемых реализаций. Но тащить ради этого jvm как-то не хочется.
Есть мысль написать свою реализацию пролога, ориентированную на хранение данных. Точнее, дедуктивную СУБД с интерфейсом на datalog. Примерно так, как описано здесь: www.vldb.org/journal/VLDBJ3/P245.pdf. Хранить предикаты не в памяти, а на диске, сделать API для доступа к данным.
Поизучал WamBook, но разобраться и вплотную заняться этим проектом пока нет времени.
> If you are using SWI-Prolog as an embedded engine in a multi-threaded application you can access the Prolog engine from multiple threads by creating an engine in each thread from which you call Prolog.
Я хочу сделать базу фактов и обращаться к ней из нескольких потоков. Это сделать не получится, потому что на каждый поток нужно создавать свой «движок», наборы определённых предикатов для которых изолированы.
На мой взгляд, пролог очень крут, но не как универсальный язык, а как язык запросов.
Пытался использовать пролог в разработке, просмотрел возможные варианты. Разобрался с сишным интерфейсом к swi-prolog, написал простую обертку для хаскеля.
Но фейл все-таки нашелся — этот интерпретатор не потокобезопасный. И использовать его, скажем, в веб приложении, не получится.
Мораль такова: стабильных работающих встраиваемых свободных реализаций нет.
В вашем комментарии словосочетание «объектно-ориентированное программирование» можно заменить на любую другую изучаемую технику
В том то и дело что не любую другую. Многие другие технологии имеют рациональный инженерный и научный подход. И решают какие-либо проблемы. ООП не решает никакие проблемы, только создаёт. Это сугубо гуманитарная штука, как отмечено в комментарии ниже.
Если реализацию можно использовать, использую обычную агрегацию, то подстановку объектов разных классов по одному интерфейсу в большинстве языков со строгой типизацией без наследования не сделаешь.
Согласен, если никак по-другому не сделаешь, приходится наследовать. Но тут от наследование скорее не польза, а неизбежный костыль. В некоторых языках со статической типизацией эта проблема решена без наследования.
s/намертво/необратимо/
Та же проблема в астрологии. Такая же астральная штука, в которой никто не понимает зачем она нужна и как именно помогает писать клёвые программы, но считает что просто ещё не достиг просветления
Единственная польза — структуризация программы. Но того же эффекта можно достичь просто грамотно разделяя продцедуры на модули в процедурном программировании. Да хотя бы просто логически сгрупировать процедуры в исходнике — абсолютно тот же эффект без оверхэда на булшит.
Ну и наследование. Хотя никто не может объяснить какая от него польза в реальном продакшене. Ну да, можно определить базовый класс и от него наследовать. Единственная польза от этого это то, что можно определить базовый класс и от него наследовать. Это не какой-то универсальный метод и ничем обычно реально не помогает. Просто какой-то абсурдный частный случай.
p.s. Да, я в курсе что я ещё не просветлел, у меня мало опыта и вообще низкий уровень интеллекта. И, разумеется, зря противоречу постулатам, которые намертво выжжены в подкорке опытных С++ и джава программистов.
Конечно нету! Человек не бездельем занят.
Ага, щас. Точно так же будет подходить начальство и спрашивать «когда». А при знакомстве, узнав что ты программист все будут точно так же с покерфейсом говорить «понятно».
Даёшь свободные облака и прочую инфраструктуру в массы!
Там тоже не учат, например, математику. А учатся отвечать на вопросы егэ по математике.
(для школофобов напомню что егэ начали экспериментально вводить с начала нулевых)
Хотя конечно полезно когда все в команде гарантировано знают какой-то общий стандартизированный набор понятий из области программирования.
Наверное отбирать огромное кол-во эффективных специалистов это очень трудная работа. Интересно, каков процент непрохождения испытательного срока.
Мощно.
Мощно.
Если есть такой «bridge», то он на задание рекурсивных предикатов должен создавать в rdbms рекурсивную хранимую процедуру.
Для своих задач я бы не отказался от такой штуки.
Да и вообще, использование datalog вместо sql может сильно упростить жизнь. Например, писать foo(A,X1),bar(X1,X2),baz(X2,B). намного проще чем делать двойной join.
Да, именно для java есть очень много встраиваемых реализаций. Но тащить ради этого jvm как-то не хочется.
Есть мысль написать свою реализацию пролога, ориентированную на хранение данных. Точнее, дедуктивную СУБД с интерфейсом на datalog. Примерно так, как описано здесь: www.vldb.org/journal/VLDBJ3/P245.pdf. Хранить предикаты не в памяти, а на диске, сделать API для доступа к данным.
Поизучал WamBook, но разобраться и вплотную заняться этим проектом пока нет времени.
Я хочу сделать базу фактов и обращаться к ней из нескольких потоков. Это сделать не получится, потому что на каждый поток нужно создавать свой «движок», наборы определённых предикатов для которых изолированы.
Пытался использовать пролог в разработке, просмотрел возможные варианты. Разобрался с сишным интерфейсом к swi-prolog, написал простую обертку для хаскеля.
Но фейл все-таки нашелся — этот интерпретатор не потокобезопасный. И использовать его, скажем, в веб приложении, не получится.
Мораль такова: стабильных работающих встраиваемых свободных реализаций нет.
Обычно говорю: «спасибо, назовите пожалуйста пункт договора, либо другой официальный документ, где это написпано».