Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Абстракция для программистов, или как я забыл MySQL и потерял 1500у.е

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Я совершенно не владею ООП и у меня для этого есть причины.

Первое — я прочитал какую-то юбилейную статью автора ООП, в которой он назвал ООП шуткой. Второе, когда я честно начал разбирать что там к чему, то мне сказали, что сейчас будет абстрактный класс, и смело показали ПУСТОЙ класс... Просто пустой класс, ктороый ни чего не делал и какие-то умники решили, что так и должно быть с абстракцией!

В программирование я пришел прямиком из философии, и убедить меня в том, что абстракция — суть пустое и не наполненное понятие не возможно в принципе. Я плюнул на ООП, поверил автору идеи ООП что это шутка, злая и глупая шутка и забил дверь в мир ООП корявыми досками и самыми крепкими гвоздями.

В СССР были два выдающихся физика: Гинзбург и Ландау. Я могу ошибаться, по этому заранее приношу извинения, если это так.
Ландау был большим поклонником математики. Гинзбург (еще раз оговорюсь, что могу ошибаться в персоналиях), был не таким большим поклонником. Результатом оказалось то, что школа Ландау легко громила школу Гинзбурга.
Математический аппарат — основа естествознания. Звучит банально, но это так. Если вы выбираете не владеть математическим аппаратом — вы лаборант. Вас легко поймают на не знании методов и... отправят учить, что нельзя делить на ноль сферического коня в вакууме.

Наличие математического аппарата позволяет подойти к объекту познания со стороны абстракции, то есть правильно! Отсутствие здравой абстракции в программировании натолкнуло меня на мысль, что как наука программирование не существует до сих пор и представляется чистым ремеслом.
Математика — царица наук именно потому, что она абсстрактна на 100%!

Истиность положений науки проверяется практикой. В том числе и математика.

Существование большинства наук, в основе которых лежит математический аппарат, их способность предсказывать состояние систем («А вот доедет это колесо до Москвы, если случись...») доказывает правильность и важность абстракции как в процессе познания мира, так и в процессе его изменения для пользы человека.

Програмирование не исключение.

Я не поверил в ООП потому, что с первых же шагов в нём грубо нарушалось элементарное представление об абстракции. Может это и может как-то работать, но зачем нам «как-то»?
Может я и не прав, но судя по тому, как именно ООП, вместо того, чтобы улучшить ситуацию повторного использования кода привело к раздуванию этого кода в разы вы можете видеть сами, что есть к этому подходу большие вопросы.

Но, ближе к делу.

Немного о природе абстракции.

В принципе, абстракция — это обобщение. Правильное обобщение приводит вас к тому, что ваше суждение, без оговорок, справедливо по отношению к любому случаю, к которому оно применимо.
Сейчас объясню!

Представим себе воду. Начнем с нуля градусов по Кельвину. Такая температура в реальности считается не достижимой. Вообразимой картины того, как будет выглядеть вода при —273,15 °C у меня лично нет. Дальше — лед (шампанское, коньки, Антарктида). Нагрев воду выше 0°C мы получаем жидкую фазу. Все понятно: пляжи, Моршинская, лишний текст. Дальше — пар: баня, облака, паровоз. Что дальше? — Плазма. Но до плазмы вода распадается на кислород и водород. Возможно, при абсолютном нуле воды тоже не станет — наверно разрушатся химические связи.
Что объединяет все эти приключения?
Первое, очевидно — присутствие воды. Второе — тепло. Но тепло — это производное от энергии. Значит объединив в правильных пропорциях воду и энергию, как абстрактные понятия, можно проехать от абсолютного нуля аж до плазмы!
Энергия — абстрактное понятие. Ничто — не абстрактное понятие.
Вещество — абстрактное понятие. Вода — производное от вещества, или, если хотите, от водорода и кислорода + реакция окисления с выделением энергии.
Современная физика считает, что само вещество — производное от «информация» + «энергия».
Помните: «в начале было Слово»?

Чем написание программ хуже сотворения Мира? Зачем косячить на этапе закладки фундамента? Ведь если в основу мироздания были заложены именно такие абстарктные идеи, что наука подтверждает, так давайте это использовать! Ну, ума и сил на такой же проект нам не хватит, но давайте посмотрим, на что может хватить.

Теперь еще немного о том, что такое «предмет науки». Это имеет отношение к абстракции. Взять, к примеру, число «1». В природе еденичных предметов не существует. Любой «единичный» предмет — совокупность других «еденичных» предметов. И так до энергии и информации. Взять, к примеру, звезды. Для чистого астронома звезда или точнее — любое небесное тело — единичный объект, который можно открыть, измерить и присвоить ему имя своей 14й любовницы или первой школьной любви. Для астро-физика звезда уже не еденичный объект. Для зоолога бык — единичный объект. Для анатома — нет. Для кулинара — и подавно нет! ))))
Любая наука возникает тогда, когда возникает ее условно-единичный объект — предмет изучения. А единица — это абстракция в чистом виде.

Еще одним, весьма существенным условием возникновения науки является наличие свободного времени. Галерный раб не может вносить вклад в науку. Между двумя гребками он не успевает подумать об абстрактном, он только успевает получить плетью по ребрам. Он не слышит «звуков небесных сфер». Все что он слышит это «раз-два», «раз-два», «раз-два», «раз-два», «раз-два», «дэд-лайн», «дэд-лайн», «дэд-лайн», «дэд-лайн», «дэд-лайн»...

Теперь вернемся к ООП. Вместо некой единицы познания нам предлагают «ноль». Сразу из нуля, происходит гипер-прыжок к конкретному объекту, но не к объекту, который представлял бы собой тот самый единичный объект науки о программировании, а... к быкам, счетам, комплектациям моделей AUDI... программисты принялись описывать абстракции из других областей знания, не имея ни собственного пресловутого единичного предмета, ни понятия об абстракции как таковом. Н-да... Это же на уровне алхимии!

Моя личная версия абстрактного единичного объекта науки о программировании стоила мне 1500 у.е. которые пришлось вернуть заказчику, по скольку все мыслимые дедлайны были пройдены. Начали, как всегда, с несчастных 20ти параметров в паре таблиц. Изменения в модель данных заказчик вносил лавинообразно, и последний вариант включал в себя более ста параметров, разбросаных по десятку таблиц со всякими хитроумными реляциями. Я хотел справиться. Мне было интересно найти такое решение, которое позволит вовсе не обращать внимания на выкрутасы заказчика и позволять ему резвиться, как он хочет. В конце концов, то, что для программиста — выкрутасы, для заказчика — сложный процесс познания, результатами которого он хочет поделиться с разработчиком. Маркетинг ведь от этого угла плясать должен? Ведь так?

Да, мне удалось создать свою версию абстракции для процесса разработки. Правда отношения с заказчиком восстановить не удалось, но не в этом дело.

Идеальным, или правильным я считал такое представление об абстракции, такой еденичный объект программирования, который позволит коду существовать отдельно, модели данных, бизнес-логике и интерфейсу — отдельно. Абстрактный код — цель. Код не должен содержать в себе ни каких элементов конкретной модели данных, конкретной бизнес-логики и конкретного интерфейса. Тогда он будет абстрактным. Тогда, создавая очередное приложение мне не нужно будет ни как изменять код. Если у меня есть 1000 заказчиков, то мне достаточно одного экземпляра кода, который можно и нужно улучшать, но не нужно менять под требования конкретного приложения создаваемого для конкретного заказчика.

Ведь ДНК строится именно так! Для любого живого существа есть лишь один набор лексем, один язык, на котором можно «написать» «Человек», «медведь», «акула», «скумбрия», «дуб», «подорожник»... И не надо выдумывать генетику каждый раз заново, когда нужен еще один «подорожник», например, со всеми его индивидуальными и видовыми признаками. ДНК + РНК — все работает! (РНК — типа такая штука, которая репродуцирует ДНК, если очень упростить).

Что вам сказать. У меня получилось. Один из результатов — я забыл SQL! Единожды написаный код обслуживает все четыре действия с базами данных: создать, изменить, извлечь, удалить запись. Работает, учитывая все реляции любых видов между данными в данной конкретной модели данных.
Остальное — так же.

Мой код абсолютно абстрактный. Из него можно строить любое приложение с любой моделью данных, с любым набором данных, менять это все хоть сто раз в час и при этом не трогать код вообще.

Абстракция — это то, что применимо к любому частному случаю. Абстрактная функция может больше, чем не абстрактная.
Решите задачу: какая функция более абстрактная?
1.
function plus ($a)
{
return $result = $a+ «3,14»;
}

2.
function plus ($a, $b)
{
return $result = $a+ $b;
}

Пустота — не абстракция!
Идеальная абстрактная функция будет делать ВСЕ! Ее одной будет достаточно! Но идеалов не существует! )))

Ищите свою модель абстракции, чтобы перестать слышать «раз-два», «раз-два», «дэд-лайн», «дэд-лайн»...
Удачи!

З.Ы.
В статье много упрощений, которые прошу оставить вне поля вашей критики, особенно, если вы спец в затронутой области знаний. В данной статье это всего-лишь иллюстрация.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

В программирование я пришел прямиком из философии,
это всё объясняет. В том числе, почему читать вас просто не возможно.

Хорошая статья. Только я не заметил телефона барыги в конце

Очень абстрактно написано про абстракции, очень абстрактно... Сколько раз ходил на ДОУ — намного лучше были вбросы, а тут хоть абстрагируйся в абстрал...

Могу порекомендовать почитать две вещи: определение шизофазии и “Топосы” Голдблатта.

In contrast to its name, object-oriented programming is essentially a categorical access to programming. Characteristics, such as encapsulation, inheritance, methods, and class or instance variables do realize what the Yoneda lemma suggests: to replace program entities by the behavior they can show under determined conditions, i.e., identification by behavior
— Guerino Mazzola, “The Topos of Music — Geometric Logic of Concepts, Theory, and Performance”
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Спасибо за ссыль. Комменты жгут! Посмеялся :) Особенно вот этот понравился:

Статья напоминает дамп мозговой деятельности PHP програмиста в момент погружения в сон

Хорошая статья, читать её, я конечно не буду.

Читал, читал. А я то все думаю, с каких таких подходов и методик е-декларирование слепили. А оно он как все просто — абстракция, абстрагирование, идеализирование, типа все само по себе рассасывается и лепится.

«Вам так не буде.» © ))))))

Автор, давай теперь о полиморфизме напиши.

Я так розумію, замість написання коду у вашій системі треба клацати по кнопках на сторінці і перетягувати елементи? Чим це краще за код? Юніт-тестами не покриєш, під контроль версій не покладеш, в улюбленому редакторі не відкриєш. До того ж конфігурація все одно зберігається у вигляді якогось коду, тобто єдина різниця у тому, що ви обмежуєте для користувача написання коду незручним інструментом.

Це ви Drupal перевинайшли? Чи 1С-пр’єдпріятіє?

Не пользовательское это дело, низкоуровневые конфиги крутить! )))
В друпале есть структура. B GPDP — нет ни каких предустановок.

Пользователь должен пользоваться, а не в код лазить! )))

Поки що нічого кращого за код по гнучкості та універсальності не придумали. Якщо ви заявляєте про універсальність і у вас буде багато користувачів, то це лише питання часу, коли вам доведеться в систему додавати code snippets як у друпал, або неповноцінне IDE по типу 1С конфіґуратор.

Наприклад в системі нема (окрім пари системних) жодної наперед вбудованої таблиці і навідь натяку на структуру даних. Нема чому очікувати той самий час! )))

Давайте начистоту — власне й продукту теж немає. А коли з’явиться, то в мене таке відчуття, що користувачі йому тільки заважатимуть, не вписуючись у ваші ідеальні абстракції.

)))))))))))))))) Що ж ви злі такі всі! )))))))))))

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

100%. По этой причине для таких вещей должен быть уровень разработчиков, которые могут плевать с олимпа на всех. Клиентский отдел, который типа как оракулы священных пхпистов, и юзвери, которые могут поиграть с некоторыми настройками!))))

Хотя, бывают и такие упоротые, что могут годами самостоятельно что-то настраивать, так до конца и не доводя начатое, но это уже обычное мудачество.
Це Ви про лінукс користувачів?

Нет, это я всё про заказчиков. Некоторым нравится самостоятельно ковыряться в конфигах и настройках.

Ну норм.
Поставте комфортну для себе погодинну ставку та правте скільки скільки завгодно.

У меня не стоит проблема в недостатке работы, а ковырять настройки — это скучно и муторно. Мне, как программисту, проще описывать всё на языке программирования: там и в подпрограмму можно вынести повторяющиеся куски, и копи-пастнуть в конце концов...

Можна брати з клієнта гроші та найняти когось щоб робив це за вас.
Якщо клієнту так зручніше то нехай платить.

В друпалі теж можна клацаючи мишкою в адмінці по entities, fields та views сконструювати будь-які таблиці зі зв’язками та гнучким CRUD, але для того щоб відтворити конфігурацію на іншому сайті, треба проклацати той же шлях, бо конфігурація жорстко зростається з даними системи. І, цікавий збіг, друпал теж писали люди які не могли в ООП і використовували якусь свою процедурну парадигму, щоправда на останніх версіях почали використовувати й ООП. Можливо у вас все-таки друпал?

Самое интересное, что ООП отлично сочетается с такими концепциями.

Хреновый ты философ. А математик вообще никакой. Рассуждения про единицу просто безграмотны. Кури аксиомы определения арифметики (например, Введение в математику. С. Клини 1957 или Введение в математическую логику. А. Чёрч. 1960 или что-то любое в началах логики). По поводу абстрактных функций. Ты обсуждаешь не абстрактные функции (что, собственно, должен был делать), а слово абстракция в том смысле как сам его понимаешь. А понимаешь ты хреново. Насчет ООП. В этой парадигме основная фишка не абстрактные функции и связка класс-объект. Ну, и наконец к проектированию баз данных это не имеет никакого отношения.

А ты аксиоматику арифметики уже усвоил? Ну, что б за 1
единицу херню не писать. Кстати, слова

«Человек», «медведь», «акула», «скумбрия», «дуб», «подорожник»...
Это не единицы, это как раз названия классов. Объектом они становятся только с указанием.. «Этот медведь», «Укусившая меня акула», «Нарезанная скумбрия» и т.д.
Это не единицы, это как раз названия классов. Объектом они становятся только с указанием.. «Этот медведь», «Укусившая меня акула», «Нарезанная скумбрия» и
т.д.

Не в наших языках. Здесь — по контексту все. Не путай с правилами артиклей... И что ты будешь делать с миллионом нарезанных скумбрий? Как выделишь одну из миллиона нарезанных скумбрий, и уж не знаю скольких укусивших тебя медведей? )))

Сделает обфускацию кода, даст готовый сайт. Потом, если не поладит с заказчиком, последний придет ко мне и расскажет старую как мир историю: «прошлый программист — редиска, деньги взял, код не предоставил, теперь у меня есть сайт, а сделать ничего с ним не могу».

Или SaaS :) Что тоже доставляет.

ага... расскажи, как вместо того, чтобы сделать простейшие изменения вы предлагаете написать все заново... плачущему заказчику! Из-за этого и происходит большая часть потери денег и клиентов, если не монополист. Откройте авто.риа.уа и посмотрите на водный транспорт, на авиа... нафига самолету коробка передач? У Риа нет доступа к коду, что они все так оставили?

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

Сделать простейшие изменения в чем? В коде, который остался на сервере разработчика? Да, мы предлагаем все сделать заново, потому что предыдущий исполнитель не отвечает на звонки заказчика.

Ты про свои луга цветущие уже утомил. Где они?

И при чем здесь риа? У кого-то руки кривые — я что, виноват? Он если криворукий, то хоть с кодингом, хоть без — сделает криво.

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

У меня весь код на ООП, а таких проблем почему-то нет. Что я делаю не так?

А, я знаю что! Я понял, что такое «абстракция» в ООП и как ее правильно использовать :) Именно поэтому у моих яхт и катеров не вырастают колёса :)

)))))))))))))))))) Ну вот! Искренне поздравляю!)))

Не надо поздравлений. Примите факты. Это просто означает, что Ваше предположение о проблеме «реальных объектов» не подтверждается. Я Вам больше скажу, по своему опыту знаю, что люди, которые пишут такие кривые решения, в ООП обычно не разбираются и используют его на уровне синглетонов.

Только могу порадоваться за вас! Наверно таки все так.
А почему у риа проблемы, как по вашему?

Вы знаете, я не хочу никого обидеть, но не всем дано быть гениями, и у разных людей разный уровень способностей. Это вопрос к матушке природе или к Богу (как предпочитаете), к родителям и школе, к обществу, в конце концов. Большинство специалистов — весьма посредственные специалисты. Задач много, и хороших специалистов на всех не хватает, к тому же они дорого стоят. К тому же никто не отменял человеческий фактор. Такая проблема не только в программировании, а во всех сферах жизни. Чем меньше человек будет делать вручную (непосредственно своими руками и под свою ответственность, неважно каким способом), тем меньше у него будет шансов напортачить. И конструкторы, и фреймвёрки существенно снижают количество ошибок. Но накладывают ограничения. Чем больше автоматизировано — тем больше ограничений.

А вот поздравлений не надо, просто примите как данность то, что ООП ни в чем не виновато :)

1. С любыми. Без ограничений. можно несколько в рамках одного проекта.
2. Код не продаю. Продаю продукт.
3. Зачем заказчику код? Заказчику нужен продукт! ))))

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

А если вы помрёте? Что тогда делать?

Как мы сможем помереть, пока вы деньги платить будете? ))))))

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

Фиг с ним с кодом. Если Вы собираетесь продавать платформу, на базе которой другие смогут сконфигурировать нужное нам приложение — значит эту часть Вы не утаите в мешке никак. «Продайте» ее нам. Покажите, как это будет работать для конечного клиента, и тогда разговор будет гораздо более предметным.

Судя по манере общения и идеи БД будет Днипро

Вы как-то слишком самоуверенно и высокомерно преподносите свое изобретение, при этом ломаетесь как девчонка. Почему слишком — потому что с таким отношением Вы никогда не увидите своих ошибок. А начали вообще с глупостей: составили всё своё представление об ООП на основе какого-то странного учебника.

То, что Вы представили пример кода на PHP, лично мне намекает на очень низкую квалификацию (да простят меня PHP-программисты). Кроме того, в сообществе PHP вообще очень немного хороших инструментов, поэтому каждый уважающий себя новичок в PHP обязательно пишет свой фреймвёрк, CMS, или хотя бы библиотеку для работы с базой данных — то есть «велосипед» (я лично тоже пытался делать ORM на PHP, но бросил из-за негибкости и невыразительности самого языка). Вы попались на ту же удочку: выбрали не самый лучший инструмент, и стали изобретать новый велосипед, потому что поняли, что держите негодный инструмент. Но высокомерие не позволяет Вам услышать доводы опытных разработчиков и обратить внимание на другие инструменты — Вы все еще думаете, что додумались до чего-то первым, даже не подвергая это сомнению.

Уверен, если Вы покажете Ваш код специалисту с многолетним опытом работы с разными языками, фреймвёрками, парадигмами в конце концов — он Вам объяснит, что именно Вы изобрели, что в этом хорошего и плохого, какие есть подобные изобретения, и как вообще решаются обнаруженные Вами проблемы в современном мире программ и приложений.

Хумани эратум эст! Если не ошибаюсь... А что у вас с ORM вышло? Какие результаты?

Ну так учитывайте же это, или Вы себя лично за человека не считаете? Тем более, если Вам дают советы опытные разработчики, опытные именно в программировании, а не в философии.

С ORM у меня вышло то, что на тот момент в PHP не было поддержки именованных аргументов функции (сейчас, на сколько я понимаю, тоже нет), а гонять параметры через ассоциативный массив — это выглядит просто ужасно. На этом я сразу и остановился. Метапрограммирование на тот момент тоже практически не поддерживалось, но я до него даже не дошел — хватило функций.

На счет массива что не устраивало? Прекрасно решает вопрос! Я лично пользую и менно это решение.

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

Сравните:

php_function(value1, array(’param2′ => $value2, ’param3′ => $value3))

python_function(value1, param2=value2, param3=value3)

как по-моему от перестановки мест слагаемых... документировать надо в любом случае. И чем лучше документация — тем лучше! )))

1. Это не перестановка, это избавление от всякой ненужной шелухи в коде, который сам по себе является важным источником информации, поскольку он — это проекция мыслей.

2. Без описания формальных параметров никакая IDE не сделает подсказку в случае опечатки, поэтому ассоциативный массив — это костыль, неудобный в использовании.

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

1. Если код хорошо задокументирован — почему бы не использовать ассоциативный массив? Код пишется в первую очередь для работы, а не для удобства чтения. Неудобочитаемые элементы кода хорошо документируем — в чем проблема?
2. Сам факт, что вам приходится делать выбор между удобством чтения кода программистом и хорошим архитектурным решением, ИМХО, говорит о том, что существует системная проблема присутствия в коде избыточной информации о «реальном объекте». Если реальный объект вынести из кода, то вы не будете иметь столько возможностей для опечаток и прочих ошибок, которые случаются даже с лучшими из нас.

Проблема неудобочитаемого кода в том, что в него сложно вносить изменения, и в нем легче допустить ошибки. Об этом недавно была статья на Хабре — про тойоты, а в ней — ссылки на другие статьи по той же теме.

Мне не приходится делать выбор между удобством чтения и хорошим архитектурным решением. Одно другому не мешает.

Написание кода — всегда риск внести ошибку. Но что Вы предлагаете взамен? Давайте посмотрим и выясним, какие ошибки можно сделать там, и какие ограничения накладывает Ваш способ. Продемонстрируйте пожалуйста, как вы создаете приложение без кода.

Хороший вопрос.
Совершенно правильно о том, что написание кода и ошибки — это сладкая парочка.

По скольку код абстрактен по отношению конкретной модели данных, возникают два момента:
1. Вы не кодите, когда создаете конкретное приложение. А следовательно не добавляете ошибки.
2. вы всегда можете использовать код повторно. В коде нет ни каких наименований взятых из модели данных, даже самых общих. Грубо говоря, если я делаю сайт торгующий шинами, у меня нет переменных с именами типа $tire_type, $tire_radius например. Ни где, и ни каким образом. Ни в названиях функций, ни в названиях классов (если бы писал на ООП) и так далее.

В добавок, архитектура не позволяет ни каких «срезаний углов», «приблуд», «временных решений».

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

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

Как-то так.

Теперь, хочу Вам сказать, уже хоть как-то более или менее ясно, что Вы придумали. Но для полной ясности, все же, почему бы не показать процесс «создания приложения»? Мне лично совершенно не интересно смотреть на реализацию, я хочу понять, что именно позволяет сконфигурировать Ваша система, и как.

Пока что мне ясно (я так думаю) следующее:
— Ваша система сама генерирует таблички в БД.
— Весь движок универсален и абстрактен.

Остаются открытые вопросы:
— Каким способом проводится конфигурация приложения? (хотя, по сути, это не столь важно)
— Какой класс задач решается Вашим движком?
— Сколько проектов для сторонних заказчиков Вы уже выполнили используя этот движок, и какие именно?

Это слишком конкретные вопросы) Ясно же, что система реализует абстракцию сферического коня в вакууме продуктов, работающих с базой данных и при этом создана для скачек по полю воображения, отражая солнечными бликами восхищенные взгляды разработчиков вполне неиллюзорных приложений)

1. почти. Есть простые правила, по которым создаются таблички. Генератора пока нет.
2. Да.
3. Нескролько разных способов: файл конфигурации, некоторые элементы, создающие конфигурацию хранятся в БД. Сама БД во многом определяет конфигурацию, по скольку система буквально считывает ее структуру. БД — 60% конфигурации и больше.
4. Изначально проект создавался для учета и статистики. Но легко расширяется под практическии любые задачи, доступные для вэба.
5. Несколько проектов. пока не больших. 100% — учет и технологическая статистика.

Под практически любые задачи?
— Можно ли без программирования вставить любой виджет, который потребует заказчик? Например, wysiwyg-редактор или какой-то определенный комбо-бокс или календарик, у которого свой уникальный способ инициализации?
— Можно ли на вашем движке сделать веб-приложение для учета времени, наподобие toggl.com? Нажал кнопку — время пошло, еще раз нажал кнопку — остановилось. И так, чтобы без программирования.
— Можно ли сделать веб-чат? Надо, чтобы сообщения добавлялись на странице через DHTML и Ajax. И так, чтобы он выдерживал большие нагрузки (скажем, сто тыщ запросов в секунду). Без программирования, естественно.
— Если потребуется экспорт данных в какой-либо формат, возможно даже бинарный, Ваш движок позволит реализовать это без программирования?
— Поддерживается ли горизонтальное масштабирование? Если запросов будет слишком много, и один сервер на справится.
— Есть ли поддержка нереляционных баз данных? Например, Redis?
— Можно ли прикрутить любые API, в том числе экзотические и узко-специализированные, не прибегая к программированию? Например, чтобы данные отправлялись на печать с сервера на сетевой принтер, или чтобы авторизация проходила через какую-то социальную сеть?

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

ну вот... угробил такой хороший топик...

Есть простые правила, по которым создаются таблички. Генератора пока нет.
Кстати, в своих проектах на Django я не создаю таблички руками, и не вношу в них изменения руками, и написание SQL-кода — для меня задача очень редкая, связанная исключительно с оптимизациями.
а гонять параметры через ассоциативный массив — это выглядит просто ужасно
уже дошло до того, что можно юзать [] вместо array()

на мой вкус — уже очень даже воркэраунд: при подходящем выравнивании воспринимается именно как именованные параметры

Так это давно уже так. Когда было иначе?

Вероятно, когда Вы занимались философией :)

Да, прогресс... Но, уже не нужно. Я нашел себе другой, гораздо более удобный и гибкий язык )

Хотя стоп.. Вас так смущает, что у кого-то вышло то, до чего вы не додумались? Завидки? )))

Что за детский сад? Сколько Вам лет, простите?

Мне нечему завидовать, Вы даже ничего не показали, а только написали много абстрактных слов и делаете вид, что Вам известен какой-то секрет. Смысл в ваших философских рассуждениях видите только Вы. Вам уже тут намекали даже на душевные расстройства. Все это похоже на жирный вброс. Вы — либо жирный тролль, либо очень молодой и не в меру амбициозный человек.

Тогда почему вы так эмоционально пишете?

Потому что я всегда расстраиваюсь, когда вижу такую «непробиваемость». Донести до Вас какую-либо мысль так же тяжело, как до любого верующего. Вы свято верите в свою правоту и не допускаете даже мысли, что Ваше решение может иметь свои минусы. По крайней мере я еще не увидел, чтобы Вы согласились хотя бы с одним замечанием к Вашим выкладкам. Все люди ошибаются, и я, и Вы — примите это! Хотите конструктивной беседы — показывайте ваше изобретение, хотя бы ту часть, которую планируете продавать.

У меня работающий прототип.
Я смог, как уже говорил, сделать так, что мне не требуется писать запросы к БД. Ни инструкции для какого-то скрипта... Пе требуется руками, ни на каком этапе, что-то подсказывать программе по работе с БД и так со всем. Что-то требует конфигурации, что-то нет.
Все это основывается на том, что я иначе провел линию абстракции.
Как именно — могу сказать. Код должен быть абстрактным по отношению к модели данных.
Как это реализуется — не покажу. Можно ли вести конструктивную беседу на основании этого лично с вами — такое дело.

Написать абстрактный код — это несложно. Я нечто такое делал 10 лет назад, когда делал универсальный каталог, где в каждой категории были свои параметры. Код был совершенно абстрактным, он не знал ни о машинах, ни о яхтах. Но там есть свои минусы.

Реализацию показывать не надо. Покажите, что конкретно и каким образом у Вас требует конфигурации. Давайте общаться предметно.

Ну, есть правила, которые нужно учитывать при создании БД.
Конфигурируются функциональные элементы: выборки, запросы.

Методы конфигурации пока есть разные. Свои плюсы-минусы...
Стараюсь на основе БД делать больше.

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

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

Минусы есть, но многое зависит от реализуемой идеи и от того, на сколько система получается гибкая и может сочетать в себе разные элементы. Разумеется, пока они подчиняются определенным правилам.

Удивительно, как эрудиция и невежество идут рука об руку!

Бросил весло и написал статью =)

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

Прочитал не больше 20% с перескакиваниями по абзацам и...

Sometimes, the elegant implementation is just a function.
Not a method.
Not a class.
Not a framework.
Just a function.
— John Carmack

престаньте страдать хней и прочитайте наконец что нибуть по теории категорий

о!
а чи можеш щось порадити просте для розуміння, невелике по обсягу і з практичними прикладами?
я завжди думав, що я щось пропускаю, не знаючи теорії категорій, тому порада більш досвідченого товариша була б дуже доречною :)

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

> Принципы ООП и паттерны проектирования являются лучшими практиками

Кто сказал? Чем меряли? :)

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

Это необъективно. Так PHP можно назвать лучшим языком для веба :)

а какой язык лучше для веба?

А никакой! Говорить, что какой-то язык лучше для веба — это тоже не объективно :) Веб бывает разный. Все зависит от задач. В общем-то, это уже тыщу раз обсуждалось.

Если вам простой сайт сделать, или требуется очень дешевый хостинг, то тут PHP нет равных. Есть много всяких CMS, и на некоторых из них можно даже что-то пристойное лепить. Wordpress довольно неплох. Тот же phpbb популярен, был, по крайней мере.

Если что-то серьезное и кастомное, и требуется гибкость в разработке — то либо Python, либо Ruby (и чаще всего — в связке с Django и Rails соответсвенно). Какой из них выбрать — это скорее дело вкуса. Мне нравится Python своей ясностью, динамичностью и стабильностью. Другим нравится Ruby со всеми его синтаксическими сладостями.

Если Энтэрпайз — то всякие там Java и .NET.

Это из самого популярного, и, следовательно, наиболее легкого для использования. Но на этом список не заканчивается. Есть и другие интересные языки и платформы. Меня сейчас заинтересовал Elixir и Phoenix — это из функционального мира, очень любопытные и быстро набирающее популярность штуковины.

А так же NodeJs для гейм-дева и хай-лоада :)

Мільйони мух не можуть помилятися? Далеко ми підемо із таким підходом доказу своїх висловлювань...

Универсальный код работает универсально плохою. © один умный человек

В программирование я пришел прямиком из философии
но потом явно вернулись обратно
В принципе, абстракция — это обобщение.
Я не поверил в ООП потому, что с первых же шагов в нём грубо нарушалось элементарное представление об абстракции.
en.wikipedia.org/wiki/Abstract_data_type
en.wikipedia.org/wiki/Algebraic_structure
Барбара Лисков неодобряе

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

ну куда уж нам до программистов, нам сыры кушать надо

Мои подозрения окрепли, когда я увидел первый $..

то что вы описали очень на 1с похоже

Коментар порушує правила спільноти і видалений модераторами.

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

А вообще бред. Я даже до половины не дочитал.

Вся статья о том, что у вас был шаблон которого хватало на все задачи, а потом пришел заказчик, и шаблона не хватило, вы не смогли заработать денег, так как забыли как писать SQL, и не смогли вовремя переделать свой шаблон?

ЗЫ: всегда думал что вот тот уровень абстракции, о котором вы пишете, это и есть сам язык программирования, это и есть ДНК с помощью которого строят собачек, птичек и червячков..

Забыл потом уже.
В том то и дело, что не совсем. Приходится создавать абстракции на языке программирования.

Не нравится ООП, попробуйте функциональное программирование. Оно как раз задумывалось максимально близким к математике. Напишите ORM в функциональном стиле, покажите его миру.

А так, вы пока что врете, что

В программирование я пришел прямиком из философии
Если вы куда-то пришли откуда-то, значит оттуда вы ушли, а из философии вы не уходили, так что разберитесь куда и зачем вы ходили.
ORM в функциональном стиле
о_о это как?

Это пусть автор топ-поста решает. Может по ходу придумает новую парадигму программирования.

Напишите ORM в функциональном стиле
А чем Slickа не достаточно?

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

Чувак, абстрагирование из философии и абстракции из программирования — они только называются одинаково. Ну, и, конечно, слегка так похожи на абстрактном уровне.
А так-то ничего общего. Одна — философская категория, второе — инженерная модель. Яблочко красненькое, а дверца у трактора во-о-от как открывается. Пусть схожее название не собьет тебя с пути ООП.

И да, и нет.
Смотря с какой стороны посмотреть. Следует учитывать опыт веков создавая новое! )))

Вот я и говорю — брось. Только мешает.

Топ-1 на ДОУ для меня

ну вы блин даете! )))

Забористо!

то мне сказали, что сейчас будет абстрактный класс, и смело показали ПУСТОЙ класс...
Единожды написаный код обслуживает все четыре действия с базами данных: создать, изменить, извлечь, удалить запись.

Spring-Data

public interface EntityRepository extends CrudRepository<Entity, Long> {}

Оно?

На первый — нет. Если я правильно понял за 2 минуты изучения вопроса, разница в том, что все что надо мой вариант CRUD делает сам. Сам интерфейсы рисует себе и все такое.

Я НЕ ПИШУ ЗАПРОСЫ К БД РУКАМИ ВООБЩЕ. Все автоматом.

CrudRepository
требует еще «обслуживания».

А вы какой-то код пишете? Можно привести пример клиентского кода к вашему CRUD?

Система для того и задумывалась, чтобы кода ни какого уже не писать по конкретным приложениям. Код смотрит в БД, находит все связи, составляет запрос, выполняет его и выдает результат в указанном виде. Что мне писать надо? Мы его улучшаем, расширяем по необходимости, но не пишем ради конкретного приложения ни строчки.

но не пишем ради конкретного приложения ни строчки

Это прорыв! Скажите, над автогенерацией БД и проверкой орфографии работа не ведётся?

Над проверкой орфографии — не ведется.
))))

Это подрыв устоев и обвал забоев. Код сам смотрит в БД, находит все связи и составляет запрос!

Код смотрит в БД, находит все связи, составляет запрос
Я бы допустил что такое возможно, но как генерирует запросы Ваш код если «связей» (специально оставил Ваш термин ;) ) в базе нет ?
— Код останавливается ?
— Код создает их сам
— Код все равно генерирует запрос, лишь бы хозяин успокоился ?

Одно совершенное решение не может жить изолированно в мире других решений. Я веду к тому что идеально спроектированных БД нет. Да в учебниках учат нормализации, а по факту посмотрите на продакшн реализации ? Тому есть подозрение что этот «Код» работает на одной только базе. Узкоспециализированный. Вы готовы натянуть Ваш код на любую продакшн базу с тысячами таблиц и несовершенной схемой (less than 3NF) ?

Вы все правильно поняли.
В нормализованной базе связи должны быть видны. Видны для кода.
По той причине, что «срезать угол» при разработке не возможно — нет технического долга. Все как на плацу: по стандарту, носочек тянуть, связи прописывать указанным образом.

Код потому и работает на любой БД, что маршируют они вместе, в ногу, так сказать. )))) Любую базу, которую научим маршировать — натянем, как вы говорите.

Код абстрактный по отношению к модели данных на 100%. из него можно делать любое приложение.

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

Я правильно понял что автор абстрагировался от дедлайна и ему не заплатили 1500 уй за срыв оного?

что токо не придумаешь,дабы оправдать забитый хрен на работу)

кгхм

В программирование я пришел прямиком из философии
...
Истинность положений науки проверяется практикой. В том числе и математика.

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

недавно очередную статью на эту тему прочел от физиков:
почему теория струн НЕ является физической теорией :)

Правильное обобщение приводит вас к тому, что ваше суждение, без оговорок, справедливо по отношению к любому случаю, к которому оно применимо.
мммм....

вы точно «не были в философии» :)

потому что «правильность обобщения» в общем случае никак не связана с его применимостью.
мало того, из-за того что обобщение, то бишь абстракция, лишено деталей — применить правильное обобщение НЕправильно — обычное дело.

Ну и про философию — ООП потому и критикуется в мире программирования, потому что оно — нематематично. Причем — немало напутано. видать не очень глубокие философы попытались приладить Аристотеля :)
для начала вашего возвращения в философию, а то вы как-то много там пропустили:
цитата из Класс объектов или объекты класса?:
Устраиваясь на новую работу, я придумал новый вопрос для собеседования. Хочу задать его и вам.
Пусть у нас есть конкретная машина. КОНКРЕТНАЯ! Не тип и не класс машин, ...

Абстрактный код — цель.
код, любой, это описание чего-то.
Если у меня есть 1000 заказчиков, то мне достаточно одного экземпляра кода, который можно и нужно улучшать, но не нужно менять под требования конкретного приложения создаваемого для конкретного заказчика.
поэтому «экземпляр кода» — следует читать — тоже самое описание.

И получается вы переоткрыли
Википедия:
Повторное использование кода (англ. code reuse) — методология проектирования компьютерных и других систем, заключающаяся в том, что система (компьютерная программа, программный модуль) частично либо полностью должна составляться из частей, написанных ранее компонентов и/или частей другой системы, и эти компоненты должны применяться более одного раза (если не в рамках одного проекта, то хотя бы разных). Повторное использование — основная методология, которая применяется для сокращения трудозатрат при разработке сложных систем.

Решите задачу: какая функция более абстрактная?
никакая, потому что это две — разные функции, почему-то названные одинаково.

напомню, программный код — это описание чего-то. он не может быть «абстрактным». Он может описывать абстракцию. или конкретику.

а теперь, решите задачу с вашими function:
опишите русским языком что делает каждая.
и объясните — почему вы им дали — одинаковое название?

и погуглите затем — выбор имени для переменной

Единожды написаный код обслуживает все четыре действия с базами данных: создать, изменить, извлечь, удалить запись. Работает, учитывая все реляции любых видов между данными в данной конкретной модели данных.
интересно посмотреть что у вас получилось :)

то есть — описание ЧЕГО содержит ваш код :)

Ищите свою модель абстракции
вообще-то абстракция и есть модель (утрировано для данного разговора, потому что не всякая абстракция может представлять собой модель. например абстракции класса категории — НЕ являются моделями).

а «модель абстракции(модели)» принято называть — метамоделью.

ждал вашего комента, пошел за попкорном :)

и мне захватите! ))

2+2=4 — это нельзя проверить эмпирически?

Если «любой код — это описание чего-то» как это совместить с его повторным использованием в принципе? Это не проблема? Это уже имеет приемлемое решение?

Мысля об абстракции, давайте примем, что существует некий водораздел между всеми частными случаями, и попыткой их осмыслить — то есть абстракцией. Математика предлагает свой метод. ООП предлагает не абстрагироваться и клеить все «в натуральную величину».

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

Как известно словари бывают толковые, и... орфографические (без-толковые)

Вот вам задача:
Нужен такой «код», такой подход к вопросу, чтобы было вот так: все связи «понимаются» и подхватываются программой автоматически. Чтобы не вышел новый «ПХПМайадмин». чтобы толк был! ))))
Дам подсказку: нужно правильно выбрать модель абстракции, или как вы хорошо сказали метамодель. Что скажете?

2+2=4 — это нельзя проверить эмпирически?
нет, нельзя.
вернее эта проверка перед этим потребует
1. определения значения символов
2, +, =, 4
2. указание применимости этих символов к частному случаю.

но самое забавное, что эмпирически нам придется проверять все комбинации операции + над числами
то есть
13213412+547562353245324=32453243243236

тоже придется проверить — эмпирически.

потому что из эмпирической истинности 2+2=4
не следует истинность:
13213412+547562353245324=32453243243236

Если «любой код — это описание чего-то» как это совместить с его повторным использованием в принципе?
так же как мы используем слова, и устойчивые выражения на обычном языке.
ООП предлагает не абстрагироваться и клеить все «в натуральную величину».
ООП такого — НЕ предлагает.

оно как раз предлагает абстрагировать свойства чего-то в — классы.

Может быть мне еще интереснее было бы посмотреть на ваш.
в моем коде ничего необычно.

я стараюсь придерживаться принятых стандартов. без фанатизма конечно :)

все связи «понимаются» и подхватываются программой автоматически.
чтобы «некто» «понял» нечто — это второе нечто должно существовать.

обычно, в программировании, это второе — в каком либо виде — описано.

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

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

так ЧТО описывает ваш код? ИИ который выявляет реляционные связи в БД?

P.S.
да, Википедия
Матема́тика (др.-греч. μᾰθημᾰτικά[1] < др.-греч. μάθημα — изучение, наука) — наука о структурах, порядке и отношениях, исторически сложившаяся на основе операций подсчёта, измерения и описания формы объектов[2]. Математические объекты создаются путём идеализации свойств реальных или других математических объектов и записи этих свойств на формальном языке. Математика не относится к естественным наукам,

Если хотите — пусть будет ИИ. Хотя это не так. Решения гораздо проще, но эффект дает не слабый.
А теперь на минутку примем, что я говорю на 100% правду. Чего стоит, по-вашему, система, которая дает такие возможности (в У.Е.)? Какая разница сказать, что описывается, или показать код?

Вы же почти сказали это! )))
совершенно правильно мыслите на счет метамодели.
Мне это только по потерянной прибыли стоило 1500 уе. ))))

Решение существует!

Ну, если действительно интересно — придется стать частью команды. Сами понимаете! ))) У вас же нет столько денег, чтобы говоря карточным языком «вскрыть» меня.

Отсюда и недосказанность в заметке моей. )))

А теперь на минутку примем, что я говорю на 100% правду.
а не имеет значения — говорите вы правду или нет :)

вы можете искренне заблуждаться, да и все.

покажите код.

не обязательно программный.

можете на русском написать. но, в топике вы написали явно бажный код. вряд ли у вас остальной код — правильный.

Чего стоит, по-вашему, система, которая дает такие возможности (в У.Е.)?
я не знаю пока свойств вашей системы, чтобы оценить ее возможности.
если действительно интересно — придется стать частью команды.
интересно конечно. но стать частью команды — это уже зависит от уровня предлагаемой оплаты :)
У вас же нет столько денег, чтобы говоря карточным языком «вскрыть» меня.
вы пока вскрываетесь очень неопрятными рассуждениями в топике :)

Ваші думки з приводу абсолютного нуля та матерії в цьому стані не мають жодного фізичного підґрунтя, але Ви при цьому дозволяєте собі такі грубі припущення, усвідомлюючи, що Ви не є компетентним в цій галузі. Це і ще інші Ваші висловлювання змушують задуматися над Вашою загальною компетентність.
P.S. Можливо для Вас буде відкриттям, але математика є абстракцією, що дозволяє описувати фізичні явища та будувати інші абстракції.

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

должны бы.

но мне непритна х-философия :)

то есть ремесленическое поделие.

так как же нормальному программисту неприятен ремесленнический код на пыхе — когда в одной функции и запрос к БД, и echoом html отдается :)

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

с неэмперичностью же математики столкнулся уже Пифагор.
Ему пришлось придумывать — иррациональные числа.

их тоже потом стало не хватать. пришлось придумывать — трансцендентные числа.

Задачка
проверьте эмпирически формулу расчета длины окружности
l = 2pr

Скажу так, при благоприятном стечении обстоятельств, вы бы создали что-то похожее. Все шаги вы уже сделали!

может действительно пригласить вас в команду?

может действительно пригласить вас в команду?
может.

хотя бы потому что парочка последних моих заработков — это оптимизация работы SQL подсистемы известных CMS систем.

то есть — связи то в них описаны правильно.
а я их описываю по другому. и тоже правильно.

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

Скажите честно, разве вам не хотелось бы, чтобы в 21 веке компьютеры уже делали бы таке вещи сами?

Скажите честно, разве вам не хотелось бы, чтобы в 21 веке компьютеры уже делали бы таке вещи сами?
хотелось бы, отчего ж нет.

на своем программерском веку я уже видел немало оптимизаций работы программиста.

Ваш практический опыт тут не имеет большого значения. Вы мыслите в правильном направлении — следовательно с вами не надо будет спорить о главном. А таких людей, которые бы мыслили в одном ключе трудно найти.

ну, я ж философ, да.

кроме практической реализации меня всегда интересовало и — а почему сделано так, а не иначе.

с тем же набором CRUD — тоже есть соображения — почему они массово пишутся так, что в некоторых случаях имеется денежный интерес переписать их по другому.

остальное, то что по делу, пишите в приват конечно.

как наука программирование не существует до сих пор и представляется чистым ремеслом.

да неужели?

программирование — суть создание модели реальных объектов и процессов, которая будет в неких рамках вести себя так же, как и первоисточник.
вы с таким пафосом заявляете, что «программирование — не наука», как будто это должно кого-то задеть. So what?! Программирование — не наука, да. Это подход к моделированию, когда модель может быть представлена в виде конечного автомата.
Точно так же не наука — составление дифференциального уравнения состояния какой-то определенной системы. Используется математический аппарат, да. Но само моделирование конкретной системы — нифига не наука. И чё?

Про абстрактный класс — как будто почитал признание о какой-то странности из детства, повлиявшей на жизнь. При этом, взрослый человек еще и в качестве аргумента использует, а не стыдится/пытается разобраться в себе и окружающем мире.

Начали, как всегда, с несчастных 20ти параметров в паре таблиц. Изменения в модель данных заказчик вносил лавинообразно, и последний вариант включал в себя более ста параметров, разбросаных по десятку таблиц со всякими хитроумными реляциями.
итеративная разработка — это про попытку впихнуть новые требования в имеющуюся модель.
если после того-самого моделирования системы в виде диффуравнения, внезапно, скажут, что надо учитывать еще солнечные циклы, гравитацию Альфа Центавры и магию единорога — претензия тоже будет к математике?

Галоперидол в аптеке закончился, что ли?

пост — полная абстракция.
#несмог #неасилил

В программирование я пришел прямиком из философии,
это всё объясняет. В том числе, почему читать вас просто не возможно.

Вот что бывает когда гуманитарии понаехали в наше прекрасное IT

Ниасилил. Мне смутно кажется, что автор пытается построить велосипед, но пока точно не уверен, как велосипед будет ездить. Бубенком автору в помощь, там хотя бы уже более-менее ездящий велосипед есть)

mikehadlow.blogspot.nl/...ion-complexity-clock.html — по-моему, вы добрались до 9 часов.

Скорей всего, Вам стоит использовать другую методологию разработки что-бы уйти от «лавинообразных» изменений заказчика.
З.Ы.
Порой, на 1000 стульев одним мягким местом и костылями не присядешь. Попробуйте MVC архитектуру.

Второе, когда я честно начал разбирать что там к чему, то мне сказали, что сейчас будет абстрактный класс, и смело показали ПУСТОЙ класс
Друзья по цеху показывали? Не хочу обидеть, но скорей всего Ваша детсткая травма заключалась в первоисточнике.

Вы издеваетесь? Вопрос на счет того, что использовать — закрыт. DPGP — форэвер.

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

На даный момент всё как-то слишком абстрактно :)

> Просто пустой класс, ктороый ни чего не делал и какие-то умники решили, что так и должно быть с абстракцией!

Просто плохой, нет, отвратительный источник для первичного обучения. Если это называлось «учебник» — автора бить ногами. Если статья по поводу — просто плохой выбор для первичного источника.

Хорошие примеры на ООП рождаются из показывания конкретных граблей. Это относится и к основным принципам. Для инкапсуляции, например, надо показать последствия вмешательства с перекосом данных. Для полиморфизма лучший пример, который я видел, это сишный интерфейс BerkeleyDB.

> и забил дверь в мир ООП корявыми досками и самыми крепкими гвоздями.

Детская травма. Не уважаю, но соболезную. Психолог в помощь.

> Математика — царица наук именно потому, что она абсстрактна на 100%!

В английском есть интересная прама омофонов — queen и quean. Так вот, математика — оба из них. Именно потому, что она абстрактна на 100%, её можно натянуть на что угодно, если некорректно натягивать.

> Я не поверил в ООП потому, что с первых же шагов в нём грубо нарушалось элементарное представление об абстракции.

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

> Да, мне удалось создать свою версию абстракции для процесса разработки.

Это процесс разработки Вы оценивали через «более ста параметров, разбросаных по десятку таблиц со всякими хитроумными реляциями», или что?

> Ищите свою модель абстракции

Спасибо, она и так на каждый проект своя. И, в основном, адекватная. Бывают неудачи, как же без них, но они тоже что-то приносят.

Удачи, и не обостряйтесь.

В английском есть интересная прама омофонов — queen и quean.

Мой мир никогда не будет прежним. Придётся многое переосмыслить, начиная с «Боже, храни Королеву».

Мой код абсолютно абстрактный. Из него можно строить любое приложение с любой моделью данных, с любым набором данных, менять это все хоть сто раз в час и при этом не трогать код вообще.

ZOG вам этого так не оставит. Вас попросят все забыть, а результаты ваших изысканий засекретят. Как и не было никогда.

Мне нужен Парабеллум! )))

Скорее хороший врач.

просто нахамить пытаетесь, или есть аргументы?

просто нахамить

Из вас хам — не очень хороший. Не ваше это дело. Пишите код! )))

Я и прогаю так себе :) Тут чисто само утверждась. Видимо не получилось :)

Вот увидите! Все будет хорошо! Не сдавайтесь в хорошем! ))

Просто будут платить абстрактными деньгами. На них можно купить абстрактное все, и при этом не трогать сами деньги вообще.

Я так понял вы сделали новый конструктор который в 100500 раз лучше остальных?

Кстати во многих языках есть универсальная абстракция Object называется

Не знаю, конструктор ли, и не знаю, во сколько раз лучше.
Просто удалось развести по разным углам создание приложений и кодинг. Когда создаешь продукт — не кодишь. Когда кодишь — не создаешь продукт.

Речь не о рынке здесь, а об отношении к вопросу абстракции как таковой.

А я думал, что кодинг — это и есть процесс создания приложения. Точнее — его часть под названием «реализация». Если Вы создаете приложение ничего не кодируя, то, очевидно, Вы его просто настраиваете. А если Вы кодите, не создавая законченный продукт, то, вероятно, вы кодите «конструктор». Это и есть то, что называется универсальным решением. Такой подход имеет место быть, с известными проблемами и ограничениями. Но под ограниченный круг задач для организации бизнес-конвейера — очень хорошее решение.

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

Вопрос в том, чем Вы пожертвовали ради этого. Здесь многие скептически отнеслись к вашим заявлениям, потому что знают на собственном опыте, что всегда приходится искать какой-то компромисс между универсальностью кода и его эффективностью (производительностью, простотой обслуживания). Я, например, тоже, можно сказать, забыл SQL. Потому что я его не использую: все запросы в моих последних проектах выполняются через Django ORM либо через SQLAlchemy. Однако же, как только я получил более или менее ощутимую нагрузку — пришлось часть запросов переписывать на голом SQL, чтобы оптимизировать их и повысить производительность. А можно было бы приобрести несколько дополнительных серверов. По той же причине далеко не все нормальные формы используются в реальных базах данных: можно, конечно, сделать красиво, но не всегда при этом можно получить адекватную производительность. Все упирается в деньги, и приходится находить компромиссы. И я еще не сталкивался со сложными отчетами в своих Django-проектах, формировать которые с помощью ORM было бы вообще непристойно дорого. Когда мне нужно собрать статистику — голый SQL в собственных руках всегда выигрывает, потому что можно прямо сказать, каким образом ты хочешь получить данные в этот раз, из этой конкретной БД и СУБД, и не зависеть от «мнения» программы.

Я пожертвовал возможностью «срезать углы». Простотой. Документировать приходится тщательно уже для себя самого. Но выиграл в во всем, что приносит абстракция.

Вы в другом комментарии говорили, что создали для какой-то задачи ровно такой же абстрактный код для работы с БД. Почему не пошли дальше по этой идее? В чем проблема?
В масштабируемости идеологии, выбранной для обработки БД? Не смогли применить в остальных областях?

Я не говорил «ровно такой же». Кажется, я написал «нечто похожее».

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

Но это не значит, что я вообще не пошел ни по какому пути. Я пошел по другому пути: вынесению повторяющегося кода в библиотеки и утилиты. Сначала я делал внутренние API и разные модули к ним, чтобы легче было повторно использовать код. Но количество повторений все равно было большим: каждый раз одни и те же запросы к БД, одни и те же формочки. Потом зародилась идея сделать доступ к БД через объектную модель с автогенерацией таблиц по классам, или классов по таблицам (тогда еще не было ни ORM, ни ActiveRecord), а также систему виджетов. И ничего лучше PHP я тогда не знал. Так что, все это в итоге выглядело монструозно (спасибо синтаксису PHP), а страница генерировалась до секунды (спасибо медленным классам PHP). В итоге пришло понимание, что на PHP надо писать простой процедурный код.

А немного позже я перескочил на Python/Django, и (о чудо!) там есть все из того, что я хотел сделать, и даже больше. И, как выяснилось, все благодаря гибкости языка и наличию метапрограммирования. Так что, пока я возился с PHP, кто-то выбрал правильный язык и реализовал все то, чего так не хватало.

В итоге абстракции Django полностью удовлетворяют моим потребностям на сегодня, и я пишу только неповторяющийся код с новым функционалом. Есть другая проблема: в больших, сложных и нестраднартных проектах стало очень сложно ковыряться, так как каждый раз приходится долго искать подходящий слой абстракции и конкретное место, куда бы засунуть эту новую функциональность, чтобы все было стройненько. ООП в таких масштабах мне перестает нравиться, и я сейчас интересуюсь ФП. Но в любом случае, я ищу более простой способ программировать, а не способ избежать программирования. Я не хочу сказать, что программирования — это панацея. На сегодня просто нет других ёмких способов выразить абсолютно любую задачу для компьютера. Ваше изобретение я за такое не считаю — извините. Если хотите — объясню почему, но на примере. Пример конфигов — в студию, тогда можно предметно обсуждать.

Object
- не универсальная абстракция! )))

Хорошая статья. Только я не заметил телефона барыги в конце

А, вы в хорошем смысле! )))

Очень абстрактно написано про абстракции, очень абстрактно... Сколько раз ходил на ДОУ — намного лучше были вбросы, а тут хоть абстрагируйся в абстрал...

ORM. Мы не совсем, как бы, отказались от SQL. Мы просто нашли способ «зашить семантический разрыв». Если на пальцах объяснять, то реляции для нашей сисемы полностью видимы, и для этого не требуется вмешательство программиста. В зависимости от задачи система сама строит тот запрос к БД, который будет оптимальным, учитывая реальные, или как они названы «физические» связи внутри БД. .именно по этой причине я и забыл (!!!) SQL, а не перестал его использовать. Если за все время работы с проектом ты можешь ни разу не обратиться к теме — забываешь, как оно там.

Модель ДНК-РНК просто предоставила хорошую подсказку, что решение существует в принципе и немного показала как именно вопрос решать.

Прошу обратить внимание, что речь не идет об идеальной БД. Речь идет о понимании абстракции для разработки ПО. Мне кажется, что я нашел более выгодную секущую плоскость между субстанцией и акциденцией. И уж совсем без разницы на каком языке это писать, и какой движок БД использовать. Работает со всеми.

Спасибо, к стати, присмотрюсь пристальнее к

XML БД
система сама строит тот запрос к БД, который будет оптимальным
слишком громкое заявление

А чего тут громкого? Г-о вопрос... сами попробуйте!

А про який ваш код йде мова?

До речі, ідеальна абстрактна функція, яку ви описали, і яка робить ВСЕ, існує у багатьох мовах: eval.

В настоящее время проект называется DPGP. (Процессор данных общего назначения)
Тогда как на счет ))))))))

Простите, не совсем понял: как расшифровывается DPGP?

В таком случае, у Вас ус отклеился буквы перепутались.

давай уже про свои успехи. Что удалось автоматизировать? Каждый раз повторяешь код? Или что-то хоть можно по второму разу использовать? )))

Слушай, зачем тебе мои успехи в автоматизации? Ну ты прямо как будто на дуэль меня вызываешь. Я — скромный разработчик, занимаюсь в основном прикладными задачами, в последнее время — в основном с помощью Django. Ничего революционного я привнести пока не успел — главным образом потому, что почти все, что мне требовалось, уже сделали до меня.

Фреймвёрки — они как раз для автоматизации выполнения рутинных задач. Django, например, выполняет большую часть работы, которую я раньше каждый раз повторял на PHP. На последней своей PHP-работе я спросил у товарищей, кто какие средства автоматизации использует. Видимо, чтобы не чувствовать себя дураками, они поглумились над моим вопросом! Это — печаль. Они скорее всего так и продолжают вручную эскейпить SQL и HTML значения, при этом путая, где какую функцию нужно вызывать.

Единственное, что Django не может сделать в принципе — это читать мои мысли, так что описывать структуры данных и правила их движения и преобразования все же приходится ручками. Хотя, в стандартных случаях, хватает вообще только описания данных, а прочитать-изменить-удалить — для этого есть стандартные реализации, которые можно при необходимости лишь слегка кастомизировать.

Еще ручками приходится делать любую нестандартную функциональность, которой в моих проектах обычно много, но она везде разная, и никакая автоматизация не прочитает мои мысли. А если ручное действие повторяется — оно быстро программируется, и становится автоматическим. Это такие вещи, которые никакая система не додумается сделать самостоятельно. Например, понадобилось генерировать разные CSS под разные разрешения экрана, и их количество стало расти в геометрической прогрессии. Это — специфическая задача, она мало у кого возникает. Вручную — непродуктивно, взяли генератор, автоматизировали его использование. Сказать «удалось автоматизировать генерацию CSS» — это смешно, такая автоматизация является обычным делом в работе любого уважающего себя программиста.

Ты писал, что тебе удалось разнести написание кода и создание приложения. Мол, когда создаешь приложение — не кодишь, когда кодишь — не создаешь приложение. В каких-то задачах это может быть удобно, но не во всех. Язык программирования в моей работе является средством выражения мысли. Мысль можно, конечно, выразить как угодно, можно в виде диаграммы, например. Но ЯП гибче. А владение слепым методом набора на клавиатуре позволяет использовать его эффективнее, чем мышь. Конечно, не обязательно мышь, можно DSL какой-то изобрести. Но во многих случаях ЯП+Фреймвёрк — это и есть DSL, только с возможность дополнительной автоматизации. Если ты вдруг почувствовал, что описание данных становится монотонным и однообразным — пиши программу, и будет тебе автоматизация! У меня полно мелких скриптов в конфигах, которые разворачивают короткую мысль в длинные определения данных. Очень удобно!

Вообще, не вижу причины избегать кодирования. Вчера я потратил день на маленькую формочку из 10 полей. Ты думаешь, я целый день кодил? Нет, я целый день думал! Постоянно менял код туда-сюда, смотрел, что получается, и размышлял. При этом изменение кода занимало у меня минимум времени, большую часть времени занимали размышления, анализ задачи, моделирование различных сценариев использование, взвешивание достоинств и недостатков различных решений и поиск оптимального. Писать код — ни разу не взападло. Можно заменить написание программного кода на описание структур на DSL или каких-то простых структур данных, или даже на рисование диаграмм, но что это даст лично мне? Мне все равно придется думать о том, какие мне нужны данные и в какой форме, и как их лучше сохранить, чтобы решить текущие и будущие задачи.

А если ты повторяешься часто в своем коде — так это не парадигма виновата. Причина — в недостатке навыков.

Вот это все, в купе со своими личными дополнительными приблудами, можно использовать хоть по двадцатому разу. И там гораздо больше, чем может показаться на первый взгляд при беглом пролистывании.
docs.djangoproject.com/en/1.10

Могу порекомендовать почитать две вещи: определение шизофазии и “Топосы” Голдблатта.

In contrast to its name, object-oriented programming is essentially a categorical access to programming. Characteristics, such as encapsulation, inheritance, methods, and class or instance variables do realize what the Yoneda lemma suggests: to replace program entities by the behavior they can show under determined conditions, i.e., identification by behavior
— Guerino Mazzola, “The Topos of Music — Geometric Logic of Concepts, Theory, and Performance”

ага, спасибо на добром слове...)))))))))))

кроме того, прошу вас заметить, что программирование — чистой воды наука гуманитарная и весьма молодая. Большая часть программистов — ремесленники в своем деле, к тому же весьма занятые. Выбор водораздела между тем, что в программировании есть абстракция, а что нет — не простое дело. Математических методов тут не достаточно, так что приходится использовать смежные знания. Междисциплинарный подход же дает весьма не плохие результаты. Большего не могу сообщить ввиду коммерческой тайны. В статье и так сказано достаточно, чтобы человек знакомый с идеей «топосов» сделал верные выводы.

интересно, я один всё это прочёл?

Ну, не знаю. Я один это все написал. монографие! )))

Думаю, да. Вопрос — зачем?

Мало того, что прочитал — еще и прокомментировал!... ))))

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

Определённо, да.
Кто-то должен принимать на себя удар от припадков шизофреников. Лучше б, они сами, конечно...

Если вы не владеете ООП — нет причин искать причину !
Можно вместо этого собрать с десяток цитат авторитетнейших бородачей, которые подтвердят, что ООП суть зло (см. www.yegor256.com/...riented-programming.html

Ну а если уж о физике речь.. Математический аппарат теории относительности разработал не Эйнштейн, а в основном, математик Минковский. Его сообщик Давид Гильберт говорил: «На улицах нашего математического Гёттингена любой встречный мальчик знает о четырехмерной геометрии больше Эйнштейна. И все же не математикам, а Эйнштейну принадлежит то, что было здесь сделано.»

Ни Эйнштейн без мальчиков — ни мальчики без Эйнштейна! ))))

Спешил просветить народ! ))) Надо структурировать — правда ваша! )))

Підписатись на коментарі