Можно и так, даже кое-кто так и делал. Данные обрабатывали во встроенных процедурах, сейчас можно и ЯП в базах данных использовать. Лично я с таким не встречался, те кто видел, вспоминали об этом как об ужасном кошмаре.
По идее БД умеет две вещи, хранить данные и выдавать подмножества хранимых данных. Но делает это хорошо. Если мы запихаем туда еще и обработку данных, что улучшится? Ничего. Все то, что мы делаем сейчас снаружи просто придется делать внутри базы. Но теперь мы делаем это из кирпичиков типа {БД}<->{логика обработки на ЯП}<->{Библиотеки для обработки данных}, а так все будет запихано в базу данных и вместо набора кирпичей получим один бетонный блок. Потеряем гибкость, а выигрыша не будет.
Хочу высказать несколько давно назревших мыслей насчет ООП. Сам я его недолюбливаю за то, что его пихают во все дырки.
ИМХО 1) Почему ООП получил такое распространение? КМК потому, что это единственная парадигма программирования, в которй хотя бы как-то связно разработана пошаговая методика декомпозиции, которой можно обучать. Можно с ней спорить, можно ее не любить, но она хотя бы есть. Другие "Волшебные слова", такие как KISS, SOLID, больше напоминают набор благих пожеланий.
ИМХО 2) Что мне не нравится 1) То, что ООП пихают во все области, даже там, где оно не очень-то и подходит. ИМХО 3) Что мне не нравится 2) Засилие в ООП Явистов И C++-ников, они тащат свое видение ООП везде, в том числе и в Питон. Это приводит к сумашедшему оверинжинерингу.
ИМХО 4) Моя практика 1) Иногда полезно придумать свою парадигму и писать в ней, если придуманная парадигма хорошо ложится на задачу. Например писать на классах, но не в ООП.
Роль языка клея к успеху Python точно отношения не имеет, выбор альтернатив огромен.
Поверьте мне, имеет, я использую Питон почти с самого начала, когда на выбор клея были: bash, tcl и Perl. Я воспринял его как "Perl" aбез его недостатков. А тогда собственно и гугла-то еще не было. Как сказал кто-то (и это было верно еще в прошлом тысячелетии): "При всем богатстве выбора, альтернативы Питону нет!"
Следующий шаг в развитии языка обязательно будет связан с развитием его синтаксиса. Смысл синтаксиса языка программирования заключается в том, чтобы предложить программисту точные изобразительные средства для решения повседневных задач. В Python'е такими средствами являются отступы, генераторы, итераторы и декораторы (замыкания и yield'ы), всевозможные коллекции и возможность реализовать собственный вычислительный объект, функционирующий как коллекция. Если в практике встречается какая-то идиома, она должна быть в явной форме выражена в синтаксисе языка. Есть ли у Вас такая идиома на примете?
А я вот думаю по другому, особенно про это: "Если в практике встречается какая-то идиома, она должна быть в явной форме выражена в синтаксисе языка."
Набор базовых идиом языка должен быть ограничен, особенно в таком языке, как Питон, который является и клеем и языком работы с данными и еще 100 примененией. Почему? Потому, что ядро такого языка желательно иметь: А) компактное. Б) Легкое для изучения.
Питон, собственно и был задуман таким. Например из циклов только for и while.
Жил как-то я в квартире с садиком на одной из окраин Лондона... Так вот, пугливость лис держится примерно на одном и том же уровне. Непугливых ждет быстрая смерть под колесами машин. С другой стороны слишком пугливой лисе быть тоже нельзя, так и проживешь всю коротенькую жизнь забившись под кустом так и не добравшись ни до одного мусорного контейнера. :)
Мой прогноз: Питон будут и дальше интенсивно улучшать, за счет улучшений он ухудшится настолько, что придется выдумавать ему замену, без всех этих синтаксических сахаров, отказов от ГИЛ и т.д. Кстати, вот эта фраза: "без необходимости прибегать к громоздкому multiprocessing", хорошо показывает, что автор не понимает самых основ устройства программ и операционных ситсем. Почему multiprocessing такой бронебойно устойчивый, а многопоточность - источник проблем с надежностью. Например браузеры были многопоточными, но потом пришлось их переделывать на мультипроцессорные.
Создание процессов — это более затратная операция для ОС, чем создание потоков. Инициализация процесса требует больше времени
Это справедливо для Windows, для Linux практически разница очень небольшая. То же самое для памяти, из-за Copy-On-Write дополнительное количество памяти при порождении процесса в Линуксе невелико.
Будет бится пореже, вот и все. Размер сердца это в основном производное от тренировок:
"Длительная тренировка при максимальном ударном объёме — способ растянуть сердце за счёт потока крови. Оно растягивается довольно легко: объём можно увеличить в 1,5-2 раза."
Не возражаю по существу, скажу только, что в приведенном Вами примере (Скажем сердце получилось на 30% больше) скрее всего никто даже ничего не заметит что с этой особью что-то не так, пластичность и тренировка органов все скомпенсируют и все. Кроме генов организм тренируется и приспосабливается в очень широком диапазоне.
Скажем жиртрест на 120 кг и марафонец, пробегающий 40 км могут быть одним и тем же человеком в разные этапы своей жизни.
Конечно, все результат мутаций. Я просто хотел обратить внимание, что многие считают, что для того чтобы приспособиться нужно ждать походящей мутации тысячи лет. Но для мнгих вещей мутации давно проихошли, и если они не очень вредные, то отбор их не отбраковывает и они находятся в пуле готовых для применения. Причем для применения немедленно, буквальн в течении нескольких поколений.
Хвосты исчезли потому, что они перестали быть нужными. Это причина. Остальное - механизм. Который может быть разным. Хвосты кстати не исчезли, они просто стали очень маленькими.
А вот кстати, сейчас, с развитием генетики и преподаванием ее в школе, все уперлись в мутации. А ведь первый и самая быстрый механизм эволюции, это то, что в популяции наличествует пул разных признаков. И для многих вещей эволюця в жестко изменишвшихся условиях может сработать практически мгновенно. Если уже сучествуют особи с нужными признаками. Если нет таких особей, тогда да, придется ждать мутацию. Ну или вымирать.
И второе. Как тут уже писали, у высших обезьян хвосты все-таки пропали!
В случае чуть более-менее сложных логик, описываемый подход (с использованием словаря обработчиков, где значения - обработчики, а ключи - строки воходных логических параметров) все равно значительно лучше, чем как match/case, так и паттерна стратегия, ИМХО. Таким подходом еще деды на ассемблере пользовались. Он прост и надежен, как АК-47.
Это же Java, там так нельзя!
Не совсем понимаю, что воспроизводится, не могли бы Вы привести пример?
Можно и так, даже кое-кто так и делал. Данные обрабатывали во встроенных процедурах, сейчас можно и ЯП в базах данных использовать. Лично я с таким не встречался, те кто видел, вспоминали об этом как об ужасном кошмаре.
По идее БД умеет две вещи, хранить данные и выдавать подмножества хранимых данных. Но делает это хорошо. Если мы запихаем туда еще и обработку данных, что улучшится? Ничего. Все то, что мы делаем сейчас снаружи просто придется делать внутри базы. Но теперь мы делаем это из кирпичиков типа {БД}<->{логика обработки на ЯП}<->{Библиотеки для обработки данных}, а так все будет запихано в базу данных и вместо набора кирпичей получим один бетонный блок. Потеряем гибкость, а выигрыша не будет.
Не, 15 лет назад, все уже было.
Хочу высказать несколько давно назревших мыслей насчет ООП. Сам я его недолюбливаю за то, что его пихают во все дырки.
ИМХО 1) Почему ООП получил такое распространение? КМК потому, что это единственная парадигма программирования, в которй хотя бы как-то связно разработана пошаговая методика декомпозиции, которой можно обучать. Можно с ней спорить, можно ее не любить, но она хотя бы есть. Другие "Волшебные слова", такие как KISS, SOLID, больше напоминают набор благих пожеланий.
ИМХО 2) Что мне не нравится 1) То, что ООП пихают во все области, даже там, где оно не очень-то и подходит.
ИМХО 3) Что мне не нравится 2) Засилие в ООП Явистов И C++-ников, они тащат свое видение ООП везде, в том числе и в Питон. Это приводит к сумашедшему оверинжинерингу.
ИМХО 4) Моя практика 1) Иногда полезно придумать свою парадигму и писать в ней, если придуманная парадигма хорошо ложится на задачу. Например писать на классах, но не в ООП.
Где-то так. Простите за сумбур.
Поверьте мне, имеет, я использую Питон почти с самого начала, когда на выбор клея были: bash, tcl и Perl. Я воспринял его как "Perl" aбез его недостатков. А тогда собственно и гугла-то еще не было. Как сказал кто-то (и это было верно еще в прошлом тысячелетии): "При всем богатстве выбора, альтернативы Питону нет!"
Следующий шаг в развитии языка обязательно будет связан с развитием его синтаксиса. Смысл синтаксиса языка программирования заключается в том, чтобы предложить программисту точные изобразительные средства для решения повседневных задач. В Python'е такими средствами являются отступы, генераторы, итераторы и декораторы (замыкания и yield'ы), всевозможные коллекции и возможность реализовать собственный вычислительный объект, функционирующий как коллекция. Если в практике встречается какая-то идиома, она должна быть в явной форме выражена в синтаксисе языка. Есть ли у Вас такая идиома на примете?
А я вот думаю по другому, особенно про это:
"Если в практике встречается какая-то идиома, она должна быть в явной форме выражена в синтаксисе языка."
Набор базовых идиом языка должен быть ограничен, особенно в таком языке, как Питон, который является и клеем и языком работы с данными и еще 100 примененией. Почему? Потому, что ядро такого языка желательно иметь:
А) компактное.
Б) Легкое для изучения.
Питон, собственно и был задуман таким. Например из циклов только for и while.
Жил как-то я в квартире с садиком на одной из окраин Лондона... Так вот, пугливость лис держится примерно на одном и том же уровне. Непугливых ждет быстрая смерть под колесами машин. С другой стороны слишком пугливой лисе быть тоже нельзя, так и проживешь всю коротенькую жизнь забившись под кустом так и не добравшись ни до одного мусорного контейнера. :)
Мой прогноз: Питон будут и дальше интенсивно улучшать, за счет улучшений он ухудшится настолько, что придется выдумавать ему замену, без всех этих синтаксических сахаров, отказов от ГИЛ и т.д.
Кстати, вот эта фраза:
"без необходимости прибегать к громоздкому
multiprocessing",хорошо показывает, что автор не понимает самых основ устройства программ и операционных ситсем. Почему
multiprocessingтакой бронебойно устойчивый, а многопоточность - источник проблем с надежностью. Например браузеры были многопоточными, но потом пришлось их переделывать на мультипроцессорные.В наших краях, в бСССР, если дикая лиса не боится людей, то от нее нужно держаться как можно дальше - это один из признаков бешенства.
Лисы еще и прыгаютдостаточно неплохо, забор 1.8 метра перелазят.
из собак нет
Делают, и из волков тоже. Не такие дорогие но делают.
Думаю их терпят потому, что на острове нет бешенства.
Это справедливо для Windows, для Linux практически разница очень небольшая. То же самое для памяти, из-за Copy-On-Write дополнительное количество памяти при порождении процесса в Линуксе невелико.
Будет бится пореже, вот и все. Размер сердца это в основном производное от тренировок:
"Длительная тренировка при максимальном ударном объёме — способ растянуть сердце за счёт потока крови. Оно растягивается довольно легко: объём можно увеличить в 1,5-2 раза."
Не возражаю по существу, скажу только, что в приведенном Вами примере (Скажем сердце получилось на 30% больше) скрее всего никто даже ничего не заметит что с этой особью что-то не так, пластичность и тренировка органов все скомпенсируют и все. Кроме генов организм тренируется и приспосабливается в очень широком диапазоне.
Скажем жиртрест на 120 кг и марафонец, пробегающий 40 км могут быть одним и тем же человеком в разные этапы своей жизни.
Конечно, все результат мутаций. Я просто хотел обратить внимание, что многие считают, что для того чтобы приспособиться нужно ждать походящей мутации тысячи лет. Но для мнгих вещей мутации давно проихошли, и если они не очень вредные, то отбор их не отбраковывает и они находятся в пуле готовых для применения. Причем для применения немедленно, буквальн в течении нескольких поколений.
Хвосты исчезли потому, что они перестали быть нужными. Это причина. Остальное - механизм. Который может быть разным. Хвосты кстати не исчезли, они просто стали очень маленькими.
А вот кстати, сейчас, с развитием генетики и преподаванием ее в школе, все уперлись в мутации. А ведь первый и самая быстрый механизм эволюции, это то, что в популяции наличествует пул разных признаков. И для многих вещей эволюця в жестко изменишвшихся условиях может сработать практически мгновенно. Если уже сучествуют особи с нужными признаками. Если нет таких особей, тогда да, придется ждать мутацию. Ну или вымирать.
И второе. Как тут уже писали, у высших обезьян хвосты все-таки пропали!
В случае чуть более-менее сложных логик, описываемый подход (с использованием словаря обработчиков, где значения - обработчики, а ключи - строки воходных логических параметров) все равно значительно лучше, чем как match/case, так и паттерна стратегия, ИМХО. Таким подходом еще деды на ассемблере пользовались. Он прост и надежен, как АК-47.