Ортодоксальный ООП - это Smalltalk (и, пожалуй, Self - я про него слышал только то, что это Smalltalk, из которого удалили классы, т.е., вещь в духе JS).
Есть объекты (и только объекты - никаких примитивных типов, классы - тоже объекты, nil тоже объект), мы им посылаем сообщения. Switch'и и прочее ветвление на тему "если объект - экземпляр такого-то класса, то делай то-то" скорее признак дурного тона. Вы просто посылаете сообщение объекту, а то, как это будет обработано, зависит от класса объекта (или, для JS, приаттаченных к объекту функций).
Ну, объект в Smalltalk'е может даже сменить класс в рантайме, а любому классу даже в рантайме можно добавить/удалить/изменить методы. На всяких Java etc приходится страдать, громоздить неуклюжие конструкции из-за невозможности произвольно расширить классы (включая системные), но называть это ООП? Как говорится, Алан Кей совсем не имел это в виду, когда придумывал термин "ООП".
Откуда берутся основания для такой уверенности? В смысле, да, язык Java получил название от острова Java, но откуда вы взяли, что по-русски язык Java должен ("взял название") называться "Джава"? Вы таким путём и Лондон в Ландон переименуете.
Меня смутило, что после упоминания Smalltalk вы пишете "Go успел меня избаловать быстрой обратной связью. От идеи до работающего результата — всего пара шагов: простой запуск, моментальная компиляция, отсутствие лишних абстракций.". Как по мне, Smalltalk в подобном не побить никому.
"Советник" - это тоже жульничество. Да, меньшее, чем когда позволять Стокфишу полностью играть вместо себя, и наверняка труднее обнаруживается, но, тем не менее.
Для усиления собственной игры хотя бы регулярно решайте задачи на тактику. Тактика - это фундамент, основа (конечно, нельзя обойтись одним только фундаментом). Самой приятной для меня была программа CT Art 3 - выбираешь уровень 10, прорешиваешь каждую задачу, берёшь уровень 20, прорешиваешь всё, и так далее, и подборки там шикарные.
Прочитал когда-то в рубрике анекдотов: "Психолог говорит пациенту: 'Вы зря жалуетесь на комплекс неполноценности. Напротив, вы на редкость трезво оцениваете свои возможности'."
Саундтреки. Я люблю почти все песни в U, а в U2, MW и Carbon мог выключить то, что раздражает. В Undercover раздражало почти всё, а выборочного отключения лишили. Пришлось отключить музыкальное сопровождение полностью. Быть может, это одна из основных причин, почему я его не стал проходить.
Это типа как некоторые люди называют БТР'ы и САУ танками, например (или как Рогозин самолёты Л-39 истребителями назвал), и их это совершенно не смущает. Правда, если им объяснить разницу, они обычно не продолжают настаивать на своём. Геймпад не джойстик уже потому, что на типичном нынешнем геймпаде имеется два (мини-)джойстика.
Я как раз у себя налетел (правда, на Oracle). Сперва стал рассчитывать правильные параметры и ужаснулся. Потом попробовал эти параметры в деле - ещё раз ужаснулся. Они ведь рассчитаны именно про чтение с диска. Оптимизатор минимизировал и выбрал фуллскан. Проблема в том, что ОЗУ столько, что все данные уже были считаны и реальное время чтения и так, и так = 0, зато нагрузка уже на ядро процессора оказалась выше для фуллскана. Поэтому, я полагаю, 1.0 должно быть правильным ответом в такой ситуации.
Да, у винчестеров необходимость передвижения магнитной головки приводит к тому, что крупноблочным способом мы читаем то же количество данных намного быстрее, чем мелкоблочным. И это важно для оптимизатора - решить, будет ли он пользоваться индексами и делать фуллскан.
И да, у SSD магнитных головок нет, seek time=0. Одна только проблема - у них (по крайней мере тех, которые я тестировал) разница между крупноблочными и мелкоблочными чтениями по пропускной способности ещё выше!
Про большую важность объёма памяти, чем скорости процессора и количества памяти - как всегда, это не универсальный закон. Я вот имею ситуацию в одной БД, когда данные закешированы, поэтому упираемся в скорость одного ядра. А было бы много пользователей...
Писать "кластер" и подразумевать "кластер БД" - штука, сбивающая с толку. Кластеров много всяких, но в компьютерном контексте обычно всё-таки имеют в виду именно набор нескольких серверов + специализированный софт. Кластер БД же такая специфическая вещь, что я скорее удлинил бы наименование, чем сократил бы его (постгресовый кластер БД).
Путать просто Huge Pages и Transparent Huge Pages - огромная ошибка. Можно (и, возможно, нужно) THP выключить, а HP включить (/etc/sysctl.conf, параметр vm.nr_hugepages= ).
Я вам в комменте, на который вы отвечаете, показал пару примеров, что не "по сути мы говорим". Правда, примеры привёл на Smalltalk'е, где мне понятно, как расшифровывать блок кода, а на Java я про рантайм-расшифровку лямбды не знаю, и если это никак не возможно, то сильно ограничивает в возможностях оптимизации. Но всё-таки Java-коллекции (объекты с "коллекционными" интерфейсами) не обязаны быть стандартными (в смысле - взятыми из JDK), да и JDK даёт нам пример - параллельную обработку, так что "начиная с первого элемента списка и далее по одному элементу" не обязательно. Коллекцию, похожую на стандартную, но принимающую "самостоятельное" решение, параллелить обработку или нет, совсем не сложно вообразить.
Ещё важный момент: обработка исключений в Java для for и стримов очень разная. Что делать, если внутри лямбды произошла какая-то неприятность и хочется прекратить обработку остатка потока и выбросить исключение?
Но "select * from xxx where a=1" декларативный или процедурный? Я привык считать, что декларативный.
Далее, анaлогом "collection.filter(x -> x == 1)" на Smalltalk будет "collection select: [:x| x = 1]", в принципе, то же самое, за исключением нюансов (обработка исключений, из-за чего Smalltalk-код даже более "процедурный", чем Java-код).
Но в Smalltalk есть финт ("doesNotUnderstand:"), благодаря которому блок кода ([:x| x = 1]) можно расшифровать во время выполнения. Благодаря этому, в том числе, если в переменной collection будет реально содержаться query-объект (ORM-фреймворка), можно во время выполнения реконструировать "collection select: [:x| x = 1]" в "select * from xxx where a=1" и передать запрос базе данных. Или, если в collection коллекция какой-то особой структуры, то как-то оптимизировать выполнение для определённого типа блоков кодов, а не тупо гонять цикл (как оптимизатор в SQL-сервере при наличии определённых выражений во WHERE может воспользоваться статистикой).
Спросил у Гугля про concurrency, получил вот: "Concurrency means multiple computations are happening at the same time. Concurrency is everywhere in modern programming, whether we like it or not: Multiple computers in a network. Multiple applications running on one computer. Multiple processors in a computer (today, often multiple processor cores on a single chip) "
Или вот: "Concurrency refers to the ability of a system to execute multiple tasks through simultaneous execution or time-sharing (context switching), sharing resources and managing interactions. Concurrency improves responsiveness, throughput, and scalability in modern computing, including: Operating systems and embedded systems. "
Да, это с очень большой-большой натяжкой подходит к теме статьи, но всё-таки. Делали наши местные (Новосибирск, насколько я помню), так что довольно видны русские мотивы.
Кстати, гугль говорит, что Oracle LogMiner is deprecated in Oracle Database 19c and will not be supported in future Oracle Database releases.
Ортодоксальный ООП - это Smalltalk (и, пожалуй, Self - я про него слышал только то, что это Smalltalk, из которого удалили классы, т.е., вещь в духе JS).
Есть объекты (и только объекты - никаких примитивных типов, классы - тоже объекты, nil тоже объект), мы им посылаем сообщения. Switch'и и прочее ветвление на тему "если объект - экземпляр такого-то класса, то делай то-то" скорее признак дурного тона. Вы просто посылаете сообщение объекту, а то, как это будет обработано, зависит от класса объекта (или, для JS, приаттаченных к объекту функций).
Ну, объект в Smalltalk'е может даже сменить класс в рантайме, а любому классу даже в рантайме можно добавить/удалить/изменить методы. На всяких Java etc приходится страдать, громоздить неуклюжие конструкции из-за невозможности произвольно расширить классы (включая системные), но называть это ООП? Как говорится, Алан Кей совсем не имел это в виду, когда придумывал термин "ООП".
Откуда берутся основания для такой уверенности? В смысле, да, язык Java получил название от острова Java, но откуда вы взяли, что по-русски язык Java должен ("взял название") называться "Джава"? Вы таким путём и Лондон в Ландон переименуете.
Меня смутило, что после упоминания Smalltalk вы пишете "Go успел меня избаловать быстрой обратной связью. От идеи до работающего результата — всего пара шагов: простой запуск, моментальная компиляция, отсутствие лишних абстракций.". Как по мне, Smalltalk в подобном не побить никому.
"Советник" - это тоже жульничество. Да, меньшее, чем когда позволять Стокфишу полностью играть вместо себя, и наверняка труднее обнаруживается, но, тем не менее.
Для усиления собственной игры хотя бы регулярно решайте задачи на тактику. Тактика - это фундамент, основа (конечно, нельзя обойтись одним только фундаментом). Самой приятной для меня была программа CT Art 3 - выбираешь уровень 10, прорешиваешь каждую задачу, берёшь уровень 20, прорешиваешь всё, и так далее, и подборки там шикарные.
Прочитал когда-то в рубрике анекдотов:
"Психолог говорит пациенту: 'Вы зря жалуетесь на комплекс неполноценности. Напротив, вы на редкость трезво оцениваете свои возможности'."
Саундтреки. Я люблю почти все песни в U, а в U2, MW и Carbon мог выключить то, что раздражает. В Undercover раздражало почти всё, а выборочного отключения лишили. Пришлось отключить музыкальное сопровождение полностью. Быть может, это одна из основных причин, почему я его не стал проходить.
Это типа как некоторые люди называют БТР'ы и САУ танками, например (или как Рогозин самолёты Л-39 истребителями назвал), и их это совершенно не смущает. Правда, если им объяснить разницу, они обычно не продолжают настаивать на своём. Геймпад не джойстик уже потому, что на типичном нынешнем геймпаде имеется два (мини-)джойстика.
Я как раз у себя налетел (правда, на Oracle). Сперва стал рассчитывать правильные параметры и ужаснулся. Потом попробовал эти параметры в деле - ещё раз ужаснулся. Они ведь рассчитаны именно про чтение с диска. Оптимизатор минимизировал и выбрал фуллскан. Проблема в том, что ОЗУ столько, что все данные уже были считаны и реальное время чтения и так, и так = 0, зато нагрузка уже на ядро процессора оказалась выше для фуллскана. Поэтому, я полагаю, 1.0 должно быть правильным ответом в такой ситуации.
"0.1 – для SSD NVMe.
1.0 – для SSD без NVMe.
2.0 – для RAID из HDD.
4.0 – для одного HDD."
RAID для HDD seek time не уменьшает. А разница между мелкоблочным и крупноблочным чтением у SSD выше, чем у HDD.
Про скорость доступа.
Да, у винчестеров необходимость передвижения магнитной головки приводит к тому, что крупноблочным способом мы читаем то же количество данных намного быстрее, чем мелкоблочным. И это важно для оптимизатора - решить, будет ли он пользоваться индексами и делать фуллскан.
И да, у SSD магнитных головок нет, seek time=0. Одна только проблема - у них (по крайней мере тех, которые я тестировал) разница между крупноблочными и мелкоблочными чтениями по пропускной способности ещё выше!
Про большую важность объёма памяти, чем скорости процессора и количества памяти - как всегда, это не универсальный закон. Я вот имею ситуацию в одной БД, когда данные закешированы, поэтому упираемся в скорость одного ядра. А было бы много пользователей...
Писать "кластер" и подразумевать "кластер БД" - штука, сбивающая с толку. Кластеров много всяких, но в компьютерном контексте обычно всё-таки имеют в виду именно набор нескольких серверов + специализированный софт. Кластер БД же такая специфическая вещь, что я скорее удлинил бы наименование, чем сократил бы его (постгресовый кластер БД).
Путать просто Huge Pages и Transparent Huge Pages - огромная ошибка. Можно (и, возможно, нужно) THP выключить, а HP включить (/etc/sysctl.conf, параметр vm.nr_hugepages= ).
Я вам в комменте, на который вы отвечаете, показал пару примеров, что не "по сути мы говорим". Правда, примеры привёл на Smalltalk'е, где мне понятно, как расшифровывать блок кода, а на Java я про рантайм-расшифровку лямбды не знаю, и если это никак не возможно, то сильно ограничивает в возможностях оптимизации. Но всё-таки Java-коллекции (объекты с "коллекционными" интерфейсами) не обязаны быть стандартными (в смысле - взятыми из JDK), да и JDK даёт нам пример - параллельную обработку, так что "начиная с первого элемента списка и далее по одному элементу" не обязательно. Коллекцию, похожую на стандартную, но принимающую "самостоятельное" решение, параллелить обработку или нет, совсем не сложно вообразить.
Ещё важный момент: обработка исключений в Java для for и стримов очень разная. Что делать, если внутри лямбды произошла какая-то неприятность и хочется прекратить обработку остатка потока и выбросить исключение?
Некстати:
Но "select * from xxx where a=1" декларативный или процедурный? Я привык считать, что декларативный.
Далее, анaлогом "collection.filter(x -> x == 1)" на Smalltalk будет "collection select: [:x| x = 1]", в принципе, то же самое, за исключением нюансов (обработка исключений, из-за чего Smalltalk-код даже более "процедурный", чем Java-код).
Но в Smalltalk есть финт ("doesNotUnderstand:"), благодаря которому блок кода ([:x| x = 1]) можно расшифровать во время выполнения. Благодаря этому, в том числе, если в переменной collection будет реально содержаться query-объект (ORM-фреймворка), можно во время выполнения реконструировать "collection select: [:x| x = 1]" в "select * from xxx where a=1" и передать запрос базе данных. Или, если в collection коллекция какой-то особой структуры, то как-то оптимизировать выполнение для определённого типа блоков кодов, а не тупо гонять цикл (как оптимизатор в SQL-сервере при наличии определённых выражений во WHERE может воспользоваться статистикой).
Т.е., какую-то декларативность можно высосать.
Как насчёт последовательного удвоения? Если на первый раз - тысяча, то на второй - две, на третий - четыре... на десятый раз 512 тысяч...
Спросил у Гугля про concurrency, получил вот: "Concurrency means multiple computations are happening at the same time. Concurrency is everywhere in modern programming, whether we like it or not: Multiple computers in a network. Multiple applications running on one computer. Multiple processors in a computer (today, often multiple processor cores on a single chip) "
Или вот: "Concurrency refers to the ability of a system to execute multiple tasks through simultaneous execution or time-sharing (context switching), sharing resources and managing interactions. Concurrency improves responsiveness, throughput, and scalability in modern computing, including: Operating systems and embedded systems. "
City Car Driving. https://store.steampowered.com/app/493490/City_Car_Driving/
Да, это с очень большой-большой натяжкой подходит к теме статьи, но всё-таки. Делали наши местные (Новосибирск, насколько я помню), так что довольно видны русские мотивы.