Comments 192
Просто оставлю ссылку:
del
Нужны ли алгоритмы? Есть такая пословица: "Заставь дурака Богу молиться, так он себе лоб расшибёт". Нужны, но в меру и при умном использовании, а не на собеседовании давать и решать эти алгоритмические головоломки. Чтобы не увеличивать количество ненависти в мире. Там была когда-то такая Матрица Компетентности Программиста, в Гугле можно найти, там написано сколько всего программисту желательно знать ещё кроме алгоритмов.
Я вам блольше скажу. Алгоритмы, нынче, даже у тестировщиков на собеседованиях спрашивают.
Спрашивают это одно, но бывают случаи когда прямо на собеседовании дают головоломки написать код на красно-чёрно-серо-буро-малиновое дерево. Могли бы просто говорить: "Наша дев команда не хочет раздувать штат. Это менеджер хочет раздуть штат, чтобы потом провести сокращения"
Автора статьи я бы взял.
Если в проекте есть 1-2 человека с хорошей математикой, человек разумный всегда сможет с ними проконсультироваться, если вдруг перформанс будет недостаточен.
Но именно то подход, который применял автор - показывает адекватность подхода. Надо решить - решили. Надо оптимизировать - попробовали. Главное, что программист понимает суть поставленной задачи от начала и до конца, а не "я свою джиру сделал, а дальше пусть ее кто-то интегрирует".
Адекватный человек вовремя догадается, что может быть вот тут нужен алгоритм, или хотя-бы консультация со знающим человеком.
Правда раньше можно было описать проблему на реддит/SO и получить в ответ "юзай вот такой алгоритм", и уже про него отдельно прочитать. А сейчас можно спросить у chatgpt.
Умея программировать, изучить и реализовать конкретный математический алгоритм не составит слишком большого труда. Поэтому те, кто прям крутят математикой налево и направо, в большинстве случаев востребованы там, где пишут специализированный софт, где пишут библиотеки, где пишут кодеки и движки. А не просто прикладной софт.
p.s. В свое время еще на Ansi C, придумал двусторонний список, ибо надо было хранить кастомный структуры, и сперва для вставки нужного объекта, проходил вперед, находил и вставлял, потом подумал что можно же сделать ссылку назад, получился двухсторонний список, и вставки/удаление упростились до элементарной операции. Про сложные алгоритмы не думал, просто писал игрушку еще в школе.
Любая программа это алгоритм, поэтому любой программист может сам свой алгоритм придумать. Просто некоторые особенно удачные и часто неочевидные алгоритмы систематизированы и поименованы. Нужно ли знать наизусть, как они сделаны? Да нет конечно. Но как минимум надо просто знать о их наличии (хотя бы какого рода бывают) и где их искать если что, уметь отличать NP полные задачи, хотя бы замечать экспоненциальную сложность. Понимать проблему останова и т.п. То есть какая-то минимальная база важна.
Ну и по-моему, (здесь уже не уверен, после такой статьи-то) любому программисту понимание работы некоторых алгоритмов (особенно когда потратил кучу времени пытаясь решить самостоятельно) может доставить истинное наслаждение. Я, например, однажды достиг катарсиса, разбираясь с алгоритмом Брезенхема для окружности.
Именно. " ...делали девочки, стирая пробелы, переводя каретки и завершая файл тремя девятками. Здесь алгоритмы были не нужны." — как это "не нужны"??? Девочки именно что следовали алгоритму ("набор инструкций, описывающих порядок действий исполнителя для решения определённой задачи"): "стереть пробелы, перевести каретку, завершить файл тремя девятками, повторить".
Хотите задачку? Попробуйте алгоритмы Брезенхема для плоскости, замощённой не квадратами, а шестиугольниками. Для прямых решение получилось интересное. А как для окружностей?
Кстати, по поводу алгоритмов Брезенхема, то в моем тогдашнем софте как раз использовался похожий алгоритм построения линий, суть которого сводилась к вычитанию из большего смещения меньшего, и если огребался флаг знака (значение уходило в минус), то к нему прибавлялось большее смещение, а к курсору прибавлялась единица по Х и У. Если же значение в минус не ушло, то менялась только одна из координат - по большему смещению. Вычитано это было бегло из какой-то книжки о графике, после чего уже самостоятельно было придумано, что начинать вычитать надо не из целого смещения, а из его половины.
Ну и про окружность, то классе в седьмом-восьмом я обнаружил, что квадрат следующего числа равен квадрату предыдущего +2N+1, где N - само число. Т.е. квадрат пяти равен квадрату четырех плюс четыре умножить на два плюс один: 16 + 4 * 2 + 1 = 25. В итоге я придумал, как целочисленно построить круг. Ну и реализовал это на ассемблере. А потом еще из-за соотношения сторон, не равного единице, делил это на три и умножал на два по У. Интересное было время! А не так давно игрался с китайским дисплеем с алика за три копейки на электронных чернилах, скачал у вендора с гита драйвер для lolin32, и нашел там кучу целочисленных алгоритмов для графики: точки, линии, круги, элипсы, дуги... Так что сейчас кружок нарисовать - это не к алгоритмам, а к библиотекам..
классе в седьмом-восьмом я обнаружил, что квадрат следующего числа равен квадрату предыдущего +2N+1, где N - само число. Т.е. квадрат пяти равен квадрату четырех плюс четыре умножить на два плюс один: 16 + 4 * 2 + 1 = 25.
А ведь мог бы дотерпеть до девятого (где, помнится, изучают производные) и узнать, что 
...
(Нет, я ни в коей мере не имею в виду, что Вы сделали что-то не так — наоборот, "самому открыть для себя что-то новое" — это важная (и приятная) часть обучения. Но, к сожалению, бОльшая часть вещей в этом мире уже украдена открыта до нас...)
А ведь мог бы дотерпеть до девятого (где, помнится, изучают производные)
Странно, зачем так долго ждать: формулу квадрата суммы, из которой это прямо следует, проходят ещё до седьмого класса. Но, видимо, у нормальных школьников ее принято проходить мимо.
формулу квадрата суммы, из которой это прямо следует
Во многих знаниях премного печали, досточтимый сэр. Не подумал о настолько простом варианте — у меня в мозгу сразу высветилось, что разность между соседними квадратами — та, которая 
— есть функция линейная, ибо см. выше.
Чета мне показалось, что дх2/дх = х, а не 2х+1. Бес попутал?
(x^n)' = n*x^(n-1)
Да, как-то уснуть не мог и гонял в голове все эти х^2' -> 2x, откуда и следует это самое 2х+1, но в 7-м классе нас этому еще не учили, и решение было найдено чисто эмпирически. Да, зная математику получше, понимаешь, что решение тривиально, при том не зная этой математики, но имея это решение, вполне можно было нарисовать круг целочисленно. И, поверьте, есть столько народу, которые прошли эту всю математику в школах и ВУЗах, но круг целочисленно ни за какие коврижки не нарисуют. Какай-то в этом есть необъяснимый феномен.
в 7-м классе нас этому еще не учили
здесь пишут что умножение на скобки проходят в 6 классе: (x+1)^2 =(x+1)(x+1)=x^2+2x+1
Так что в 6м классе это вполне возможно "открыть"
Скажу по секрету, только никому не говорите: когда пишешь какую-то функцию, пусть и по перекладыванию джосона, пусть на языке 1с, не важно, всегда пишешь алгоритм. Чисто по определению алгоритма.
Хотя понятно, что речь не об этом. Как по мне, знание базовых алгоритмов, понимание их алгоритмической сложности и практика решения алгоритмических задачи всегда полезна, и особенно перекладывателям джесонов. Ибо именно в их среде легко найти тройные вложенные циклы где в самом внутреннем цикле будет вызов какого-нибудь метода, типа, ЧегонибудьService.getЧегонибудьDetails(), который делает запрос, к базе, или лезет во внешние ресурсы, при этом всегда один и тот-же и мог-бы быть вызван за пределами цикла и просто данные потом использованы в этих циклах.
Я видел это миллион раз в разных вариациях. У самых сеньеристых сеньеров. Если же имеешь практику решения каких-нибудь литкодовских задачек, не на отвали, а для себя, то как-то привыкаешь следить за алгоритмической сложностью алгоритмов, которые пишешь, или ревьюишь у других, и тем самым делаешь мир в целом чище.
:)
В программировании на 1С запрос в цикле считается моветоном не только лишь всеми - факт. Начинающих падаванов вот прям зомбируют, чтобы они это не делали.
А по поводу алгоритмов, то любой список действий - это да, алгоритм. Но я указал, что под алгоритмами в рамках этой конкретной статьи я считаю такие, которые делают дело быстрее, чем наивный подход.
У меня такое наивное подозрение, что запрос в цикле может породить квадрат...
Квадрат — это плохо!
Стучать будет!
— А почему у поезда колёса круглые, но стучат?
— Формулу для площади круга помнишь?
— Ну да, пи эр квадрат...
— Ну вот квадрат и стучит.
Там не квадрат, там намного хуже может быть чисто за счет диких накладных расходов на эту операцию. Любое обращение к СУБД, хоть проиндексированной и оптимизированной в хлам, по определению будет намного медленнее работы с заранее полученной таблицей значений в памяти. Не говоря уже о том, что запрос запросу рознь, и одно дело читать какие-то служебные флаги из регистра, и совершенно другое - грести тяжеленные данные из табличных частей документов пополам с регистрами накопления, где объем одной выборки может измеряться шестизначным числом.
Любое обращение к СУБД, хоть проиндексированной и оптимизированной в хлам, по определению будет намного медленнее работы с заранее полученной таблицей значений в памяти.
Вообще-то, нет. Иначе, для ускорения работы скачивали бы всю БД в память.
Иначе, для ускорения работы скачивали бы всю БД в память.
Redis так и делает, например :)
Если объем данных в БД превышает физический объем доступной памяти (что обычно и бывает, причем, превышение как минимум кратное, если не на порядки), то... Дальше варианты - виртуальная память со свопом, одноуровневая память где что-то располагается в памяти, что-то на диске.
Так или иначе, обращения к диску все равно будут. И профит тут неочевиден.
Дальше варианты - виртуальная память со свопом, одноуровневая память где что-то располагается в памяти, что-то на диске.
В подавляющем большинстве БД, кроме оперативных и мастер данных, которые и так быстро оказываются в кеше, есть еще старые и архивные данные. Поэтому, на практике, деградация производительности наблюдается только при доступе к таким редко используемым данным.
И Вы забываете самое главное. Даже Redis вынужден сбрасывать свои данные на диск. А уж ACID этого просто требует.
превышение как минимум кратное, если не на порядки
На порядки - это должна быть уж очень специфичная СУБД. Типовое требование - объем памяти 20-50% от размера БД, в зависимости от задач.
Так или иначе, обращения к диску все равно будут. И профит тут неочевиден.
Для тех, кто давно пользуются даже обычными РСУБД, не говоря уже о Hana или ClickHouse - очевиден. Хорошо продуманная стратегия кеширования и спекулятивное чтение творят чудеса. Я так чаще упираюсь все же в ядра CPU, а вовсе не в производительность СХД (точнее 40-гигабитки к СХД, так как сам СХД способен на большее).
Типичная картина, когда запрос ограничен 24 ядрами из 32-х:
Я потому и упомянул Hana с ClickHouse, показав, что тут все далеко не однозначно. И если Redis бездумно грузит в память действительно всю БД, то другие СУБД требуют загрузки в память только той части БД, которая необходима, позволяя не грузить в память ту часть БД, которая просто не нужна для текущих запросов. По той простой причине (скрин выше), что это не дает никаких преимуществ.
Redis может позволить себе грузить все базу данных в память, только потому, что он не поддерживает SQL. А поддержка SQL, хочется Вам этого или нет, требует создания временных объектов плохо предсказуемых размеров. В том числе в разы превосходящих суммарные размеры таблиц, участвующих в запросе.
Ну и все же некорректно сравнивать Redis, не поддерживающую ACID, с ACID СУБД. WAL/TransactionLog тоже может расти до размеров, превышающих размер данных в БД.
Я бы аккуратно поспорил на тему бездумности. Мб вы просто с такими задачами не сталкивались. Есть масса чисто in-memory DB, в том числе с ACID и поддержкой SQL. В некоторых задачах ждать пока данные для запроса поднимутся с диска в память недопустимо.
Да даже в MS SQL можно создать таблицы (а может даже целые базы - не упомню), которые целиком и полностью в памяти хранятся.
А вот и цитата с мелкомягклого сайта относительно ACID:
Таблицы, оптимизированные для памяти, по умолчанию полностью устойчивы. Как и транзакции на (стандартных) дисковых таблицах, транзакции на оптимизированных для памяти таблицах полностью соответствуют классификации ACID (atomic, consistent, isolated, durable — атомарные, целостные, изолированные и устойчивые). Оптимизированные для памяти таблицы и скомпилированные в собственном коде хранимые процедуры поддерживают только подмножество функций Transact-SQL.
Да даже в MS SQL можно создать таблицы (а может даже целые базы - не упомню), которые целиком и полностью в памяти хранятся.
Сами таблицы хранятся полностью в памяти, а вот для обеспечения устойчивости (durable) на диске ведется журнал в директории $FSLOG, а транзакции и данные фиксируются тоже на диске в директории $HKv2. Что, кстати, приводит к заметной деградации производительности при модификации in-memory таблиц. Почитайте, если интересно.
Я бы аккуратно поспорил на тему бездумности. Мб вы просто с такими задачами не сталкивались. Есть масса чисто in-memory DB, в том числе с ACID
Для того, чтобы спорить, нужно хотя бы указать, о каких СУБД идет речь. Я не представляю, как реализовать ACID, без фиксации данных в постоянном запоминающем устройстве. Последняя буковка не вписывается без этого.
А надо как на ZX Spectrum: либо все данные целиком помещаются в ОЗУ, либо никак))
Иначе, для ускорения работы скачивали бы всю БД в память.
Вы забываете про время и ресурсы сети/памяти на скачивание всей базы. А так-то вы правы, кроме случаев, когда сервер БД много мощнее клиента.
У вас через всю статью сквозит, что «господин Журден не знал, что говорит прозой».
Достаточно очевидно, что асимптотическая сложность не играет большой роли, когда данных мало. Опять-таки, очевидно, что в старые компьютеры данных помещается сильно меньше чем в современные. Как вы написали «1,2 Гигабайта, что для современного компьютера ниачём».
То есть, масштабы используемой памяти сильно выросли, поэтому в ЦОДах надо держать в голове асимптотическую сложность почти всегда. А раньше этого не надо было, а наоборот, нужно было уменьшать время обработки одного элемента. Поэтому сейчас можно писать на Питоне, но следить за сложностью, а раньше нужно было писать на ассемблере, но за сложностью следить было не обязательно.
асимптотическая сложность не играет большой роли, когда данных мало
Достаточно типичная проблема для больших систем, которые живут долго и развиваются в течении жизни - увеличивается не только количество данных, но и количество процессов, с этими данными работающих Т.е. нагрузка на систему растет не только по данным, но и по процессам и в какой-то момент система перестает справляться с возложенными на нее задачами т.к. в основу старых процессов были положены какие-то "нативные" алгоритмы, которые на момент разработки устраивали по производительности, а на данный момент уже не устраивают.
Решение проблемы экстенсивным путем, переходом на более мощное железо, это крайняя мера т.к. очень затратно. Поэтому сначала будет использоваться интенсивный путь решения - оптимизация алгоритмов. Переход от нативных к более сложным и более эффективным.
Как раз сейчас проходили этот этап. Очень много задач "на оптимизацию" - переписывание старых модулей, потребляющих слишком много времени и ресурсов. Сам недавно переписывал 6-7 таких модулей. Код 16-го года. Тогда у нас было... Не знаю сколько, наверное, миллионов 20 клиентов. Сейчас 50. Плюс количество бизнес-процессов увеличилось. И да, с тех пор железо менялось (как минимум один раз, если не два). Но все равно - наступил момент когда время работы старых модулей перестало укладываться в рамки допустимого временного окна и пришлось брать их в полную переработку. Там уже вопрос не в рефакторинге кода, а в полном его переписывании. Т.е. берем бизнес-логику и реализуем ее заново, максимально эффективно. Где-то другие таблицы используем, где-то какие-то кеши, где-то добавляем витрины, где-то перестраиваем запросы, вынося из них "тяжелую" логику на постобработку и т.д. и т.п.
В результате в данном конкретном случае получилось на том же процессе ускориться в среднем раза в четыре.
Решение проблемы экстенсивным путем, переходом на более мощное железо, это крайняя мера т.к. очень затратно. Поэтому сначала будет использоваться интенсивный путь решения - оптимизация алгоритмов.
Странное утверждение. Из моего опыта как раз наоборот - железо дешевле людей и сначала пытаются увеличить железо. Если это не помогает, идут к людям.
Вы вот чуть ниже приводите как раз эту стратегию в пример, а вовсе не ваше утверждение.
Совершенно не странное. Мы вот работаем на платформе IBM i (AS/440). Сервер
IBM Power E980:
120 процессорных ядра Power9
RAM (Оперативная память) - 12Тб
LAN (Сетевые контроллеры) - 10Гигабит
Storage - 400Тб на SSD
Operation System: IBM i 7.4
В курсе сколько такая машинка стоит? И как ее сейчас купить? Перевод банка с 50млн клиентов на новое железо (а банк нельзя "закрыть на санитарный день") - та еще развлекуха. Это чуть чуть сложнее и чуть дороже чем проапгрейдить домашний комп или сервер ООО "Сукин и Сын" на 100 сотрудников.
Избавление от старого неэффективного кода в любом случае хорошо. И введение "нефункциональных требований" (по производительности и эффективности) на основе накопленного опыта и огромного количества статистик Performance EXplorer (PEX) - основного нашего инструмента для нагрузочного тестирования через которое проходят все поставки.
Так что в первую очередь интенсивный путь и только потом уже экстенсивный, но никак не наоборот. Тем более, когда четко видно что можно ускориться по софту - есть еще резервы (тот же PEX показывает что в старом коде не все гладко).
Думаю, что конкретно ваш случай очень узкоспецифичный. Вы уперлись в потолок апгрейда мейнфрейма, архитектура, подозреваю, не позволяет горизонтально масштабироваться на несколько серверов и это загоняет вас в оптимизацию кода.
На самом деле нет. По всем позициям нет.
Это не мейнфрейм (мейнфрейм - это IBM z)
Там нет потолка - эти сервера отлично кластеризуются (и у нас не один сервер, а кластер) и горизонтально масштабироваться можно. Но это сильно дороже чем оптимизировать работающий код. Неужели вы думаете что тут не умеют деньги считать? Здесь на все первый вопрос - "сколько на этом заработает банк?" - сколько надо вложить сейчас и как скоро это окупится и начнет приносить прибыль.
Неоптимизированный код сродни несвежим продуктам. Может быть для кого-то это норма - для нас нет. Посему на весь новый код сейчас очень жесткие требования, а старый - там выявляются проблемы и исправляются. Что позволяет продлить срок службы серверов, а не менять их каждый год просто потому что у разработчиков руки растут непойми откуда.
И да, периодически железо обновляется. Когда-то у нас стояли Power7, потом Power8, сейчас Power9. Думаю, что и Power10 (они уже существуют) тоже в свое время будет. Как только это действительно станет рентабельным. 10-е поколение, кстати, еще более масштабируемо (по тем описаниям, которые были в сети) - там непосредственно на кристалле размешен контроллер шины, позволяющий объединять машинки так, что они работают как одна, включая совместное использование памяти и всех прочих ресурсов. Условно - ставите 4-процессорную машинку с 10Тб памяти и 200Тб диска, по необходимости еще одну, подключаете к первой и вот у вас 8-процессорная машина с 20Тб памяти и 400Тб диска. Нужно еще? Подключаете еще. И по прежнему для вас это один сервер.
Условно - ставите 4-процессорную машинку с 10Тб памяти и 200Тб диска, по
необходимости еще одну, подключаете к первой и вот у вас 8-процессорная
машина с 20Тб памяти и 400Тб диска. Нужно еще? Подключаете еще. И по
прежнему для вас это один сервер.
Интересно как это работает. Потому, что при нынешних скоростях лишние пол метра кабеля между корпусами будут очень заметно замедлять работу внося соответствующие задержки просто из-за ограниченной скорости света. А пропускную способность шины равную шине проца сложно представить (даже с увеличенным временем отклика). И на сколько я знаю это актуально даже в пределах 1й материнки, если слотов много (там еще электрические проблемы вылезают).
Именно из-за этих топологических проблем память разбита аж минимум на 4 уровня (3 уровня кэша процессора и RAM). По идее память из соседнего сервера это память следующего уровня, с еще большей задержкой доступа. Но планировщик находится в процессоре. По этому нужен какой-то драйвер, который бы приоритизировал выделение памяти и миграцию по ядрам. Возможно я видел что-то такое в ядре линукса, но не уверен. Но если архитектурно большая часть процессов шарится по большей части памяти, то такая оптимизация даст не много.
И именно с точки зрения оптимизации это не выглядит лучшим решением. Как по мне, проще раскидать сервисы по отдельным серверам, тогда поток данных между серверами будет гораздо меньше и более прогнозируемым и обычного 10GE будет даже избыточно.
Интересно как это работает
Возможно сейчас уже не так, но еще в 2008 году IBM использовала для этой цели HyperTransport. Суммарная длина шины ограничена ~0.6 метрами, что вполне позволяет соединять ей соседние стойки. Зато на HT легко реализуется NUMA. Издержки заметны, но в мультизадачной среде, правильные настройки affinity процессоров позволяют их минимизировать.
Вы уперлись в потолок апгрейда мейнфрейма
Даже если у вас гуглевские PCшки, добавляя функциональность вы рано или поздно упрётесь в какие-то внешние — физические, финансовые или административные ограничения.
Например, если одни сервер потребляет 100 ватт, то 1000 серверов потребляет 100 кВт — а это уже ощутимые деньги на электричество, серьёзная проводка, вопросы охлаждения и т.д. И просто увеличить в 4 раза кол-во серверов станет несколько накладно.
А в случае серьёзных датацентров может оказаться, что для ввода ещё сотни серверов надо строить новый энергоблок ближайшей электростанции. Просто потому, что на данный момент резервы распределены, и кого-то придётся отключать.
железо дешевле людей и сначала пытаются увеличить железо
Так было раньше, когда действительно производительность одного ядра CPU, скорости внутренней и внешней памяти росли двукратно каждые пару лет.
Сейчас экстенсивный путь развития вертикального масштабирования себя изжил. А для горизонтального масштабирования требуется рефакторинг. Причем, часто, очень даже не простой. И то, что раньше работало на монолите, теперь приходится переводить, например, на микросервисную архитектуру. Что, в первую очередь, человеческий труд, а не просто закупка нового железа. И спрос с просто эффективных алгоритмов сейчас сместился на, пусть и не столь эффективные, но поддерживающие параллельные и распределенные вычисления алгоритмы.
Да все это есть давно уже. И параллельное и распределенное вычисление на этой платформе работает. И микросервисы тут не уперлись (дались они вам, эти микросервисы - там проблем не меньше чем пользы). Все и так модульное и все в отдельных заданиях крутится. И внедряются и тестируются модули независимо друг от друга, и два модуля в разных заданиях полностью изолированы друг от друга не хуже контейнеров...
Почитайте про Power9, Power10, про NUMA и CAPI. И никакого рефакторинга не нужно (см. TIMI в IBM i).
распределенное вычисление на этой платформе работает
Рассказывайте это кому-то другому. С распределенными вычислениями на AS/400 все совсем не радужно. И описанная Вами конфигурация это только подтверждает. Три десятка средненьких 32-х ядерных серверов с парой терабайт оперативки и с такой же парой СХД по 200 ТБ стоят на порядок дешевле кластера из двух описанных Вами AS/400, а с программным обеспечением ориентированным на распределенную обработку будут заметно производительней и, тем более, надёжней. Существенно более тяжелые системы уже так переехали даже с z/OS, а не AS/400. И Вы переедете, если Вы в РФ.
Можно примеры тех, кто переехал? И сравнение производительности?
Те обзоры, что я читал, говорят об обратном.
https://www.tadviser.ru/index.php/Проект:Слезть_с_IBM.%D0%9E%D0%B4%D0%BD%D0%B0%D0%B8%D0%B7_%D0%BA%D1%80%D0%B8%D1%82%D0%B8%D1%87%D0%BD%D1%8B%D1%85_%D0%B2%D1%8B%D1%81%D0%BE%D0%BA%D0%BE%D0%BD%D0%B0%D0%B3%D1%80%D1%83%D0%B6%D0%B5%D0%BD%D0%BD%D1%8B%D1%85_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC_%D0%A0%D0%96%D0%94_%D0%BF%D0%B5%D1%80%D0%B5%D0%B5%D1%85%D0%B0%D0%BB%D0%B0_%D0%BD%D0%B0_Postgres
Только не спрашивайте, почему не стали шардировать данные. Я бы точно стал.
Во-первых, РЖД - это госкорпорация (или корпорация с госучастием, или как там оно у них называется). И вопрос это больше политический, нежели технический. Тоже самое касается и ПФР (там процесс аналогичный)
Во-вторых, я не в курсе что там у них крутится на аске - не факт что именно то, для чего аска предназначена.
В третьих, нет никаких данных о том, что даст сравнимую производительность и сколько оно будет стоить.
И, наконец, ну мигрировали куда-то. Ок. На сегодня вопрос закрыли. А завтра? У нас вот за три года количество клиентов увеличилось с 36млн до 50млн. Сколько можно наращивать количество серверов? 5? 10? 20? 50? В какой момент вам придется выкинуть старое и перетаскивать все на новое? Будет ваша платформа поддерживать аналог TIMI на аске, или с переходом на новые процессора вам придется пересобрать под них весь код чтобы он был оптимизирован под новые процессоры?
вопрос это больше политический, нежели технический
Ну так и Вам потребуется уходить со своей любимой i 7.4 и не менее любимой DB/2, на которые сертификаты ФСТЭК были приостановлены еще в марте прошлого года. Теоретически, можно полностью исключить обработку и хранение персональных данных на Вашей системе, но практически это вряд ли оправдано. И уже сейчас Вы стоите перед нелегким выбором. Либо обновление версий (закон обратной силы не имеет) и риск многомиллионных штрафов (мораторий на плановые проверки до 2030 года не исключает внеплановые проверки и инспекционные визиты), либо переход на сертифицированное программное обеспечение.
я не в курсе что там у них крутится на аске
Во-первых, это некультурно писать ответ, даже не ознакомившись со ссылками. Во-вторых, к них была не AS/400, а кластер IBM Mainframe Parallel Sysplex на z/OS. Это несколько мощнее.
нет никаких данных о том, что даст сравнимую производительность и сколько оно будет стоить
То, что производительность сравнима, могут подтвердить сотни тысяч пользователей АСОУП. Я лично подтверждаю, что по логам интеграции с АСОУП-3 провалы производительности были в сентябре-октябре, но в ноябре, когда они уменьшили нагрузку системные таблицы на порядок, сократив использование временных таблиц, я этого уже не замечаю. Был бы у них до этого опыт с PostgreSQL - и этого бы не произошло. Баги всплывали еще на прошлой неделе. Но это тоже было ожидаемо. Исправляют.
Сколько можно наращивать количество серверов?
При правильно настроенном шардировании - бесконечно. К тому же есть Beowulf: "Since 2017, every system on the Top500 list of the world's fastest supercomputers has used Beowulf software methods". Beowulf кластеры из обычных компьютеров содержат до тысячи нод включительно (NASA).
Будет ваша платформа поддерживать аналог TIMI на аске, или с переходом на новые процессора вам придется пересобрать под них весь код чтобы он был оптимизирован под новые процессоры?
Вернитесь в XXI век. Технологии .NET (CIL), Java (JVM) и node.js (V8) избавляют от такой необходимости. Под новые процессора оптимизируются только компиляторы из байт-кода, что не требует пересборки приложений. И если TIMI тупо компилирует байт-код при запуске в машинный код, то идеология CIL, JVM и V8 намного сложнее, так как первичная компиляция выполняется очень быстро без оптимизации, а уже в процессе выполнения, по результатам профилирования, производится более медленная оптимизирующая компиляция наиболее нагруженных объектов. Впрочем тут немало копий уже сломано. К тому же CIL и V8 сейчас развиваются быстрее, чем JVM (камень в сторону Oracle).
Во-первых, это некультурно писать ответ, даже не ознакомившись со ссылками. Во-вторых, к них была не AS/400, а кластер IBM Mainframe Parallel Sysplex на z/OS. Это несколько мощнее.
Во-первых, по ссылке текст недоступен. Только заголовок. Вот вторых IBM z - это не мощнее. Это принципиально другое.
АСОУП-3 провалы производительности были в сентябре-октябре
Баги всплывали еще на прошлой неделе.
Надеюсь, вы понимаете, что для банка такое в принципе недопустимо? Вряд ли вас порадует если все ваши счета вдруг обнулятся или доступ к ним заблокируется и вам скажут "мы тут на новую систему переходим, извините, поправим в ближайшее время, в не переживайте так сильно..."
То, что производительность сравнима, могут подтвердить сотни тысяч пользователей АСОУП.
Какой ценой? Погуглите на тему cost-efficiencies of ibm i по сравнению с другими системами.
Вот тут, например:
IBM i/Power i Acquisition Costs
35% Less than the Windows-based server
46% Less than the Linux/Oracle server combo
IBM i/Power i Ongoing Costs
49% Less than the Windows-based server
53% Less than the Linux/Oracle server combo
Либо обновление версий (закон обратной силы не имеет) и риск многомиллионных штрафов (мораторий на плановые проверки до 2030 года не исключает внеплановые проверки и инспекционные визиты)
На дворе декабрь 23-года. Как думаете, этот вопрос, если бы он действительно стал так остро, не поднимался бы уже?
И, кстати, у нас есть возможность хранить ПД на внешних системах (которых несколько десятков штук). Это вообще не проблема. На аске работает АБС, но это сильно не весь банк.
Технологии .NET (CIL), Java (JVM) и node.js (V8) избавляют от такой необходимости
Ну да, ну да. Не в курсе, что банки (страховые и прочие коммерческие расчеты) работают с фиксированной точкой, нативной поддержки которой нет и не будет во всем, что вы перечислили? Т.е. у вас нет и не будет возможности просчитать запись из БД в байтовый буфер и сразу с ней работать, не оборачивая ее всякими временными объектами (а это все накладные расходы).
Кроме того, любой интерпретатор байткода - это само по себе уже дополнительные накладные расходы.
И если TIMI тупо компилирует байт-код при запуске в машинный код
Один раз, при запуске на новом железе.
Вообще, очень странная позиция - вместо того, чтобы обеспечить у себя контроль качества кода и мониторинг нагрузки с выявлением узких мест (прежде всего), вы предлагает по каждому чиху наращивать мощности железа. Вам уже указали на то, что это несет дополнительные расходы не только на само железо, но и на энергетическую инфраструктуру (ту же систему бесперебойного питания серверов в частности).
Но если вы так настаиваете - могу еще предложить сэкономить на тестировщиках - сразу не упало - валим на прод. Хороший баг сам вылезет, потом багфиксами закроем.
Я бы понял такую позицию от продавца серверов - ему выгодно впаривать свой товар. Или от чиновника, сидящего на откатах от закупок. Но для технического специалиста, отвечающего за работоспособность системы это непонятно.
Надеюсь, вы понимаете, что для банка такое в принципе недопустимо? Вряд ли вас порадует если все ваши счета вдруг обнулятся или доступ к ним заблокируется и вам скажут "мы тут на новую систему переходим, извините, поправим в ближайшее время, в не переживайте так сильно..."
Уже несколько раз "не радовало" в МКБ и в ВТБ. Пару раз именно с сообщением "переходим на новую систему, проведение операций не доступно". И совершенно аналогичные АСОУП баги у обоих тоже встречал - баланс по счетам правильный, но не совпадает с суммой отображаемых операций. Не идеализируйте. Как бы Вы ни тестировали систему перед релизом, баги в ней все равно будут по определению.
Погуглите на тему cost-efficiencies of ibm i по сравнению с другими системами.
Не подменяйте понятия. Возрастание стоимости масштабирования в системах IBM достаточно быстро становится экспоненциальным, а в том же Beowulf - она остается линейной. Если бы было по Вашему, то в TOP-500 суперкомпьютеров были бы обычные кластеры мейнфреймов, что далеко не так. При том, что как я уже указал, Beowulf используют все суперкомпьютеры с 2017 года.
На дворе декабрь 23-года. Как думаете, этот вопрос, если бы он действительно стал так остро, не поднимался бы уже?
А он и поднимается повсюду. Вы новостей что-ли не читаете? Кто-то выжидает возвращения IBM, MS и Oracle, осознавая, что обновление аппаратно-программного обеспечения с приостановленной сертификацией противозаконно. Кто-то идет на риск, рассчитывая, что пронесет, так как его бизнес слишком мелок и не критичен для того, чтобы профильное министерство разрешило проведение проверки (мораторий продлили до 2030 года). Кто-то уже близок к тому, чтобы упереться в ограничения текущей архитектуры, и потому вынужден срочно переходить на сертифицированное аппаратно-программное обеспечение. Для кого-то такая миграция настолько дорога, что дешевле хоть каждый месяц платить по 18 млн. рублей штрафа, лишь бы не производить миграцию.
Точно знаю, что в холдинге СУЭК, НТК, ЕвроХим и СГК совет директоров еще в прошлом году установил мораторий на обновление аппаратно-программных средств с приостановленной сертификацией. С очень большой вероятностью, аналогичное решение принял и совет директоров Вашего банка. Если бы Вы указали, о каком банке идет речь, то можно было бы это проверить.
Не в курсе, что банки (страховые и прочие коммерческие расчеты) работают с фиксированной точкой, нативной поддержки которой нет и не будет во всем, что вы перечислили?
Простите, но несете бред. Decimal/numeric типы поддерживаются во всех перечисленных системах чуть-ли не с момента их рождения. Вы и вправду искренне считаете, что тот же OEBS на Java или AX на C# используется для финансового учёта без этого? А если Вы про упакованный десятичный формат, то с появлением SIMD инструкций он катастрофически проигрывает по производительности целочисленному с фиксированной точкой.
Кроме того, любой интерпретатор байткода - это само по себе уже дополнительные накладные расходы.
Я где-то употребил слово "интерпретатор"? Во всех перечисленных системах производится компиляция байт-кода, а вовсе не интерпретация.
Один раз, при запуске на новом железе.
В CIL, JVM и даже V8 это тоже возможно, но на практике редко используется. Ведь в общем случае контейнер/приложение может запускаться на любом хосте или даже на разных ядрах одного гетерогенного хоста. Более того, может потребоваться оптимизация кода даже в зависимости от процессора из-за различий в скорости доступа к памяти в мультипроцессорных системах. Если же учесть, что подавляющее большинство приложений выполняются неизмеримо дольше, чем требуется для компиляции, то чаще всего речь идет тут о тысячных долях процента от общего времени выполнения.
А вот само наличие "горячей" оптимизирующей компиляции по результатам профилирования нагрузки дает возможность динамической адаптации машинного кода к конкретному профилю нагрузки, чего не позволяет однократная компиляция, как в TIMI.
Вообще, очень странная позиция - вместо того, чтобы обеспечить у себя контроль качества кода и мониторинг нагрузки с выявлением узких мест (прежде всего), вы предлагает по каждому чиху наращивать мощности железа.
У Вас глюки. Такое утверждать мог лишь подросток или инфантильный взрослый, страдающий от юношеского максимализма. Любой проект требует экономического обоснования. Если экономически выгодней нарастить мощности железа - то выбирается именно это. Если экономически выгодней оптимизация или даже рефакторинг - то выбирается он. И начинал я как раз наоборот, с совершенно противоположного:
Вам уже указали на то, что это несет дополнительные расходы не только на само железо, но и на энергетическую инфраструктуру (ту же систему бесперебойного питания серверов в частности).
Вы бы заглянули в структуру затрат своего же банка. Будете очень сильно удивлены, насколько ничтожны затраты на амортизацию оборудования и коммунальные услуги по сравнению с затратами на ФОТ. Например, в Альфа-банке затраты на оплату труда в 12-13 раз выше, чем на амортизацию ОС и коммунальные услуги в сумме. То есть Альфа-банку даже 10% рост затрат на амортизацию и коммунальные услуги выгодней, чем 1% рост затрат на оплату труда.
для технического специалиста, отвечающего за работоспособность системы это непонятно
Вот именно поэтому я, после высшего технического, получил еще и высшее экономическое образование. Потому что даже на уровне синьора или архитектора, не говоря уже о линейном руководителе, недостаточно только технических знаний без понимания экономических основ рентабельности производства (в том числе и программного обеспечения). А Вам бы рекомендовал все же повзрослеть и избавиться от юношеского максимализма. Интенсивный и экстенсивный пути развития всегда сочетаются для получения максимального эффекта.
Простите, но несете бред. Decimal/numeric типы поддерживаются во всех перечисленных системах чуть-ли не с момента их рождения
Как в Java или C# объявить переменную типа DECIMAL(15, 0) без создания объекта какого-либо класса? Ну то есть что чтобы вот у нас int i, а вот decimal d(15, 0)?
А если это date? time? timestamp? varchar?
Да, в java есть BigDecimal. Но оно ничего общего с тем DECIMAL что лежит в БД по представлению в памяти не имеет. От слова совсем.
Т.е. вы не можете прочитать с диска запись (надеюсь не секрет, что в итоге там все сводится к чтению M байт по смещению N в буфер) и сразу этот буфер использовать без создания разного рода объектов типов DATE, TIME, etc из кусков этого буфера.
Как это делается на аске (с нулевыми затратами на конструирование объектов в рантайме, чисто на статических структурах и без динамической работы с памятью, которая тоже не бесплатна) я уже неоднократно показывал. Повторяться не буду.
Во всех перечисленных системах производится компиляция байт-кода
А байткод прямо выполняется процессором и не требует дополнительной прослойки? Ну да, ну да...
Да, он выполняется быстрее, чем полный интерпретатор. Но это не исполняемый код. Уж поверьте, что такое байткод знаю. И сам писал скриптовые языки с компиляцией в байткод.
То есть Альфа-банку даже 10% рост затрат на амортизацию и коммунальные услуги выгодней, чем 1% рост затрат на оплату труда.
Т.е. выгоднее держать команду косоруких джунов и раз в полгода покупать новый сервер потому что они не умеют написать эффективный код?
Интенсивный и экстенсивный пути развития всегда сочетаются для получения максимального эффекта.
Я где-то говорил обратное?
Или вы почему-то решили, что для оптимизации узких мест в коде надо обязательно повышать ФОТ?
Я вообще-то возражал против категоричного утверждения о том, что "не хватает производительности - докинем новый сервер".
Докинем. Но только после того, как убедимся что дальнейшая оптимизация кода слишком затратна или невозможна.
без создания объекта какого-либо класса
Зачем создавать объект, если для статического или стекового объекта это может выполнено компилятором? Вы и в C/C++ базовыми типами не обойдетесь для работы с decimal, что совершенно не мешает этим языкам лидировать по производительности.
Да, в java есть BigDecimal. Но оно ничего общего с тем DECIMAL что лежит в БД по представлению в памяти не имеет. От слова совсем.
Потому что в БД свои требования для внутреннего представления, данных, а в разных языках программирование - совсем другие. Это же относится и к DB/2 (я так понял речь именно про нее), так как она тоже вынуждена хранить даже просто целые числа в одном и том же виде, вне зависимости от того, на big-endian, little-endian или mixed-endian CPU она в данный момент функционирует. Поэтому в подавляющем большинстве СУБД данные хранятся вовсе не в машинном представлении CPU, на которой она сейчас запущена, а в своем внутреннем формате. Аналогично и в любом сетевом протоколе endianess строго определяется стандартом и не зависит от CPU.
вы не можете прочитать с диска запись (надеюсь не секрет, что в итоге там все сводится к чтению M байт по смещению N в буфер) и сразу этот буфер использовать без создания разного рода объектов типов DATE, TIME, etc из кусков этого буфера.
Если DB/2 поступает именно так, то легче сразу повеситься, чем мигрировать её БД с одной платформы на другую. А кластер DB/2 в гетерогенной среде превращается в фантастику. Если endianess CPU в DB/2 распространяется и на протокол связи с клиентом - то вообще слов нет, кроме нецензурных. Выгоды же при этом никакой, так как подобные преобразования при необходимости выполняются CPU на порядок быстрее, чем чтение из памяти этих данных. Если же говорить об ARM, то он такие преобразования выполняет автоматически в том же такте, что и операция (префикс rev).
А байткод прямо выполняется процессором и не требует дополнительной прослойки? Ну да, ну да...
Вы точно читать умеете? Могу повторить. А Вы попросите кого-то Вам это прочитать:
И если TIMI тупо компилирует байт-код при запуске в машинный код, то идеология CIL, JVM и V8 намного сложнее, так как первичная компиляция выполняется очень быстро без оптимизации, а уже в процессе выполнения, по результатам профилирования, производится более медленная оптимизирующая компиляция наиболее нагруженных объектов.
Один раз, при запуске на новом железе.
В CIL, JVM и даже V8 это тоже возможно, но на практике редко используется. Наличие "горячей" оптимизирующей компиляции по результатам профилирования нагрузки дает возможность динамической адаптации машинного кода к конкретному профилю нагрузки, чего не позволяет однократная компиляция, как в TIMI.
Разве TIMI позволяет такую оптимизирующую рефлексию машинного кода? Что-то я о таком не слышал.
выгоднее держать команду косоруких джунов и раз в полгода покупать новый сервер потому что они не умеют написать эффективный код?
Очень мало вероятно. По моему опыту, джун всегда убыточен. В следующий раз, прежде чем задавать такие глупые вопросы, просчитайте экономическую рентабельность. Тогда хоть будет что обсуждать.
Я где-то говорил обратное?
Именно так:
Так что в первую очередь интенсивный путь и только потом уже экстенсивный, но никак не наоборот.
Вы явно высказались, что вместо сочетания интенсивного и экстенсивного пути развития, Вы хотите применять интенсивный путь до экстенсивного, а не использовать их совместно, в зависимости от экономической рентабельности в конкретной ситуации.
Или вы почему-то решили, что для оптимизации узких мест в коде надо обязательно повышать ФОТ?
Возможно у Вас полный барадак в учете затрат. Возможно, кто-то ведет его за Вас. Но каждый час работы сотрудника списывается на конкретный центр затрат. И если сотрудник сейчас занимается "оптимизацией узких мест в коде", то он не занимается, например, новой функциональностью срочно необходимой в связи с приказом Центробанка. А значит на эту новую функциональность необходимо привлечь кого-то другого. Но так как бизнес не может себе позволить сотрудников, ничем не занимающихся и свободных для привлечения куда угодно, то в общем случае - увеличив затраты на оплату труда расширив штат.
Иными словами, если руководство решает, что на "оптимизацией узких мест в коде" следует тратить не 640 человекочасов в месяц, а 1280, то это решение подразумевает наем еще четырех сотрудников, занимающихся только этим. С соответствующим ростом затрат на ФОТ. И то, что подобное решение было принято в Вашем банке когда-то раньше, ничего не меняет. С момента принятия этого решения затраты на оплату труда возросли, что требует оборотных средств ежемесячно.
Я вообще-то возражал против категоричного утверждения о том, что "не хватает производительности - докинем новый сервер".
Для ряда задач (Confluent, Cassandra, Spark и т.п.) - это совершенно правильное решение. Их оптимизировать обойдется несравнимо дороже, а шансы на сколь-либо значимый результат этой оптимизации - ничтожны. В общем случае - опять таки, требуется экономическое обоснование. Если, например, на оптимизацию модели прогнозирования мне нужно хотя бы три месяца и при этом, я не могу гарантировать, что на одной A100 нейронная сеть станет обучаться даже в полтора раза быстрее, то закупка второй A100 точно даст двукратный прирост производительности и точно обойдется дешевле, чем затраты работодателя на мой труд в течении этих трех месяцев. Причем закупить и установить ее можно за несколько дней, что тоже немаловажно, если решить проблему нужно было еще вчера.
Почитайте про Power9, Power10, про NUMA и CAPI. И никакого рефакторинга не нужно
NUMA и никакого рефакторинга??? Попробуйте написать программу для параллельной обработки чего либо там, ориентируясь на SMP, а потом тупо запустите её на двухпроцессорном сервере. И попробуйте добиться полного использования вычислительных мощностей машины. Ха, ха, ха.
Как-то один товарищ писал здесь про зависимость производительности серверов от количества планок установленной памяти. Ну как бы всем должно быть понятно, что если в процессоре 8 каналов памяти, а вставлено две планки, то работают только два. На двух сокетах надо ставить уже 16 планок. При том я нередко даже в очень больших конторах видел сервера - под тот же 1с, - в которых на два сокеты было 4 модуля памяти. И с этим вот вообще не получается бороться, т.к. админы - они вообще не про алгоритмы, хотя в их работе этих алгоритмов (бест практис) - тоже выше крыши.
Из моего опыта как раз наоборот - железо дешевле людей и сначала пытаются увеличить железо. Если это не помогает, идут к людям.
Да, но:
1. Если конкретное место однопоточно, то для добавления железа тем или иным образом придётся идти к людям — расшивать либо в параллельную обработку, либо в сервисы.
2. Если там сложность высокого порядка (квадрат/куб), то скоро упрёмся в какие-то проблемы с железом: либо его нет, либо некуда поставить, либо ещё что.
3. Если система живёт долго, лет 10, то она, скорее всего, достигла потолка аппартной части, и использует её в ситуациях пиковой нагрузки почти на 100%. А расширение этой системы упирается в какие-то серьёзные ограничения, скажем, размер центра. Ну потому, что «сначала увеличивали железо».
То есть, к людям приходится довольно часто ходить.
Тут еще такой момент - когда сопровождение видит конкретные проблемы в конкретных (особенно старых) модулях, то проще и быстрее переделать несколько модулей и получить кратный прирост производительности в наиболее узких местах, чем сразу ставить еще один сервер и переносить на него старый ресурсозатратный код.
Как пример - был у нас один процесс, который с ростом количества обрабатываемых данных занимал до 12-ти часов (и это при параллельной обработке в 10 потоков). На тех самых "нативных" алгоритмах.
Сейчас он полностью переписан и занимает меньше часа. Да, там стало сильно сложнее в плане алгоритма (и пришлось ряд попутных задач реализовать), но вот так вот.
Что надо сделать по железу чтобы в 12 раз ускориться? Я сомневаюсь что это можно только железом решить за какие-то осмысленные деньги.
Сперва будут покупать новое железо. Оптимизация 1 процесса в системе стоит от 5к долларов, иногда сотни тысяч долларов. Проще купить железо чем оплатить неделю разработки
асимптотическая сложность не играет большой роли, когда данных мало
Ой не скажите. На эти грабли вполне можно наступить с со списком из нескольких сотен элементов.
Не далее как несколько месяцев назад в одном из наших сервисов вынужденно меняли архитектуру. Сервис по большому счёту представляет собой QUIC сервер, на котором каждому из сконфигурированных проектов выделен свой IP адрес. В силу разных исторических причин в "архитектуре до" для каждого из проектов создавался свой сокет, слушавший на его адресе и порту 443. И с ростом числа проектов это начало презирядненько жрать процессор.
Как выяснилось (c), в ядре Linux раскладывание UDP пакетов по сокетам сделано так: сначала за O(1) в хэш-таблице находится порт, а потом линейным поиском по списку сокетов на этом порту ищется нужный IP. Потому что сколько сокетов на одном порту нормальные люди откроют: один, ну может пять если у них какие-то особые потребности. "Асимптотическая сложность не играет большой роли". Но это ж у нормальных, а у нас были многие сотни, и этот линейный поиск начал всерьёз влиять и на пожираемый процессор, и на пропускную способность, и на latency.
В "архитектуре после" сокет сделали один, и раскидывание пакетов по обработчикам проводили уже в user-space с более оптимизированными алгоритмами. Метрики улучшились прямо на глазах.
1) Автор явно выбрал неверное название для статьи. Верное - почитайте мои ностальгические воспоминания про якобы почти не-программиста, который уделывал и западных, и наших крутых программеров. Про алгоритмы тут процентов пять максимум.
2) "На дворе стояли 90-е — начало компьютерной эры человечества". Ну вот не надо грязи. Начало было гораздо раньше.
3) про сортировку кружочков ребёнком - девочка сразу видела все кружочки и сразу выбирала наибольший (точнее, сравнивая попарно, построечно несколько раз, быстро двигая глазами). Попросите ее так отсортировать 50 кружков и она не сможет. А вот видеть, что очередной кружок больше нижнего из уже отсортированных - сможет.
4) вьювер - блин, как же меня достает это а-ля деревенское произношение (типа как "маде ин Япан")
5) "на С из кеша ОС битовая матрица формировалась..." - из какого такого кэша? Вот тут поподробнее, что за кэш и так далее.
вьювер - блин
а что? обычный англицизм, я так говорил еще с 80-х, почему бы мне бросать это делать?
вьюер - англицизм, вьювер - рунглицизм
в СССР было принято чтение в латинской транскрипции (меня поправят как это правильно называлось), поэтому например Вильям Шекспир, Вальтер Скот, Гудзон и т.п. Вероятно да, это рунглицизм, но то что он есть, не должно вызывать негодования. Люди, пользующиеся такими словами уйдут и останутся только истинные англочитающие товарищи ломающие себе язык.
Ну и "вьюер" писать в быту, как и "уотсап", как и другие слова мне кажется непрактично, поэтому - вацап, тимвьювер, браузер и т.п. Если уж на то пошло - нет слова "компьютер" вот вам транскрипция
computer [kəmˈpjuːtə]
мне кажется вас проклянут, если вы заставите русского человека так говорить.
Можно спорить о том, как правильно читать "william", "whatsup" и прочее. Это инвариантные случаи. Но в слове "view" нет второй "в" и никогда не было. Никто же не читает "ренаулт", "куеуе", "бузинесс".
Кринге, блин.
В слове "doctor" звук "r" тоже не произносится в британском произношении, что не мешает ему звучать в американском. Это даже не трогая русское слово "доктор".
Вышеупомянутый "computer", аналогично, имеет звук "r" в американском произношении, но не имеет в британском.
Что касается "view", то русский язык достаточно богат, чтобы не заимствовать это слово из английского языка. В переводах я везде вижу слово "представление", а вовсе не "вью". Но даже по аналогии, слово "clown" пришедшее из английского языка, звучит как "клоун", без лишних звуков. И говорим мы "ноу-хау", а не "кноув-хаув" )
Никто же не читает "ренаулт"
Ну тут как повезет. ДДТ ("dust") в русском языке устоялся, как "дуст", а вовсе не "даст". И травили тараканов дустом. А если Вы, говоря о "xerox", скажете "зиракс", а не "ксерокс", то Вас вообще не поймут.
Что касается "view", то русский язык достаточно богат
А что касается viewer? Как с этим?
Просмоторщик!
В зависимости от контекста, это может быть и зритель, и читатель, и просмотрщик, и досмотрщик, и осмотрщик.
Контекст тут конкретный: средство для просмотра чего-либо. Каковы будут ваши варианты?
Либо просмотрщик, либо программа просмотра, если требуется уточнение контекста, что имеется в виду именно программа, а не устройство (например, просмотрщик микрофильмов).
Коряво получается, однако.
Почему? В библиотеках даже 40 лет назад называли просто "просмотрщик", так как программ просмотра тогда не было. Сейчас их надо как-то разделять, если контекст не ясен. На микрофильмах очень много осталось до сих пор не отцифрованного.
Почему?
Потому что написать-то можно, но произносить неудобно.
Ну это исключительно Ваше личное субъективное мнение. Причем на уровне двухлетнего ребенка, многие из которых коверкают слова именно потому, что "произносить неудобно". На Эйяфьядлайёкюдль с непривычки даже дикторы центрального телевидения язык ломали. Но ничего, быстро привыкли. Из-за этого Эйяфьядлайёкюдль никто не переименовал )))
Eyjafjallajökull происходит от eyja [ˈɛɪja] — остров, fjall [fjatl̥] — гора и jökull [ˈjœkʏtl̥] — ледник.
По исследованию американских лингвистов, название ледника могут правильно произнести лишь 0,005 % населения Земли[13]. Исландская певица Элиза Гейрсдоттир Ньюман сочинила песенку, помогающую выучить слово Эйяфьядлайёкюдль[14][15]. Русская транскрипция Э́йяфьядлайёкюдль довольно близко фонетически передаёт произношение названия исл. Eyjafjallajökull.
Довольно близко != точно.
Ну это исключительно Ваше личное субъективное мнение. Причем на уровне двухлетнего ребенка
Хамите? А зря: к вашему сведению, в языке слова, которые произносить неудобно, могут меняться под это самое удобство. Не верите? Посмотрите про происхождение слова "близорукость".
А пример про исладский вулкан отношения к делу не имеет: поговорили про него досужие разговоры и забыли. А вот viewer - штука используемая часто, и не дикторами, которым бабло платят за говорение, а обычными людьми. Забыть не получится, называть как-то придется. Лучше - удобно.
Хамите?
Нисколько. Просто забыл уточнить что имелось ввиду знание языка на уровне двухлетнего ребенка. Скорее всего, для Вас русский язык не родной, поэтому Вы не знакомы со словами осмотрщик или досмотрщик. Если человеку мешает только изменение приставки давно устоявшихся в русском языке слов с о- или до- на совершено обычную в русском языке приставку про- - то это действительно уровень человека только начинающего осваивать язык.
в языке слова, которые произносить неудобно, могут меняться под это самое удобство
Это не относится к словам, различающихся только приставками, с одинаковым корнем слова и суффиксом.
Нисколько. Просто забыл уточнить что имелось ввиду знание языка на уровне двухлетнего ребенка. Скорее всего, для Вас русский язык не родной,
Вы, похоже, так старались меня задеть, но не подать при этом виду, что придумали в качестве отмазки полную ерунду: на уровне двухлетнего ребенка можно знать язык только как родной (да - не полностью и неточно) и никак иначе: в этом возрасте дети по-другому язык изучать не могут.
Вы не знакомы со словами осмотрщик или досмотрщик.
Таки знаком. И со многими другими порождениями канцелярита - тоже. И даже писать на канцелярском диалекте русского языка умею, вот!
Но это не делает эти слова менеее корявыми: сочетание "трщ" - оно неудобно. А спасает их от изменения только крайне узкая - профессиональная, область их применения, за пределами которой эти слова никому не нужны.
Возьмем, к примеру "досмотрщика". У вас, наверняка, были знакомые, в 90-х, которые челночили и с этими "досмотрщиками" по жизни сталкивались. И что, разве кто-то из них рассказывал, что его на таможне "досмотрщик досматривал"? Вряд ли - скорее, нормальный человек бы сказал, что его "таможенник прошмонал".
А вот с viewer такое не проканает - больно уж часто такие программы обычнми людьми используется.
Это не относится к словам, различающихся только приставками, с одинаковым корнем слова и суффиксом.
Доказательство будет? А оно тут нужно: в произношении приставки и суффиксы настолько ничем не выделяются, что их выделению приходится специально детей в школе учить.
порождениями канцелярита
С каких пор словообразование в русском языке стало "порождениями канцелярита". Слово "смотреть" знаете, надеюсь? А то что корень в нем "смотр" в курсе? А то что суффикс "-щик" есть в русском языке не слышали? А приставку "про-" никогда не используете?
Раз Вы не в курсе, то канцелярит - это стиль речи, по Чуковскому, характеризующийся двумя признаками:
Сложностью и запутанностью предложений
Обилием сложных словосочетаний
Никакой связи со словообразованием этот термин вообще не имеет.
крайне узкая - профессиональная, область их применения
Особенно слова надсмотрщик )))
Гугл выдает полмиллиона страниц с этим словом. Но Вам мало...
нормальный человек бы сказал, что его "таможенник прошмонал".
Для Вас это нормально. Для меня - безграмотно. Образованный или хотя бы просто культурный человек не употребит слово "шмон" в фразе "стою в очереди на досмотр в аэропорту".
Доказательство будет?
Чего? Того что в словах надсмотрщик, просмотрщик, осмотрщик и досмотрщик корень смотр, суффикс -щик, а приставки над-, про-, о-, и до- соответственно? И Вы еще обижаетесь, когда я утверждаю, что Вы не знаете русского языка?
С каких пор словообразование в русском языке стало "порождениями канцелярита". Ну, если не кацелярита - то примерно того же искуственного в языке, что несовместимо с живым языком.
Если не канцелярита, то чего-то такого же далекого от живого русского языка: я не лингвист, чтобы разбираться в сортах этой ерунды.
Особенно слова надсмотрщик )))
Ну, область там другая, но распространенность в живом языке - примерно такая же. Много ли при вас в нашей действительности кого-то называли "надсмотрщиком".? К примеру, на Прекрасном ИТ, где пишут все больше на живом языке, использовалось вместо этого слово "погонщик". Количество написанных страниц не роляет: их редко кто читает вслух. И я уж не говорю о том, что в русском письменном языке много всяких странностей накопилось: те же -тся и -ться, хоть бы: никто ведь так не произносит, но многие зачем-то тщательно выписывают, да ещё и стараются не перепутать.
Для Вас это нормально. Для меня - безграмотно. Образованный или хотя бы просто культурный человек не употребит слово "шмон" в фразе "стою в очереди на досмотр в аэропорту".
Вам важно выглядеть "образованным" или "культурным" человеком? А для меня важно быть порядочным человеком, т.е. не форма, а содержание. А поскольку я - носитель русского языка во всех его разновидностях - письменной, устной и матерной, то я сам способен понять - какое слово уместно в каком контексте. Кстати, если вы заметили, мат - который там тоже должен был бы быть в реале - я опустил: в контексте комментариев на Хабре он неуместен.
Чего?
Доказательство того, что вы написали в той цитате, которая перед была вопросом о доказательстве. Разве вам это не очевидно из контекста: цитаты и вопроса к ней?
PS Я уверен, что от своего желания доказать свою правоту (что "viewer" должен быть "просмотрщиком" и не волунет) любым способом вы все равно не отступистесь, так что думаю, с вами дискутировать дальше по этому вопросу смысла нет.
Тем более, я хотел вам указать совсем на другое: вы изначально подменили тезис, став обсуждать перевод слова view вместо viewer - и эта подмена существенно некорректна, с учетом того факта, что отглагольные существительные в английском образовывать куда проще, чем в русском. И если вы готовы признать хотя бы это, то я буду даже доволен.
и стараются не перепутать.
Что значит "стараются"? Мне вообще не понятно, как их можно перепутать - слова же вообще разные получаются.
Мне вообще не понятно, как их можно перепутать
Что тут непонятного: и "-тся", и "-ться" произносятся одинаково: "-ца" (или "-цца").
Ударение ставится по разному. Например, тру́дится и труди́ться.
Ну, бывает, что и одинаково ставится: говорится и говориться.
Но самое главное - два возможных варианта правописания, которые невозможно отличить по произношению (к тому же - не совпалающему ни с одним из вариантов). И чтобы правильно писать, нужно зазубрить некое правило. Зачем это надо, разве это разумно?
одинаково ставится: говорится и говориться.
Я что-то не представляю себе случая употребления слова "говориться", если оно не является частью составного сказуемого. И наоборот, "говорится" не может быть его частью. Может быть кто-то подскажет исключения. Было бы интересно.
И чтобы правильно писать, нужно зазубрить некое правило.
Совершенно не надо. В школе я стабильно писал не только сочинения, но даже диктанты на пять, почти не помня правил. Достаточно перечитать хотя бы всех русских классиков, чтобы грамотность стала автоматической.
Зачем это надо, разве это разумно?
Бессмысленный вопрос. В любом языке можно найти то, что кажется неразумным, не понимая, как за сотни лет он развивался и почему именно к этому пришел. И если тут хотя бы правила есть, то в любом языке имеется большее или меньшее количество словарных слов, правильное правописание которых никаким правилам не подчиняется. Просто так сложилось, например, при заимствовании из другого языка.
Я что-то не представляю себе случая употребления слова "говориться", если оно не является частью составного сказуемого.
Во-во, пошли эти самые правила: составное сказуемое->неопределенная форма->значит, втыкаем 'ь'. Но произношение-то все равно то же самое? И какой смысл так мучаться, как школьники годами мучаются? Глупость это IMHO.
Совершенно не надо. В школе я стабильно писал не только сочинения, но даже диктанты на пять, почти не помня правил. Достаточно перечитать хотя бы всех русских классиков, чтобы грамотность стала автоматической.
Для начала - таки приходится: как раз для выработки автоматизма грамотности. Но читать "всех русских классиков" для этого не обязательно: тренировка навыка творит чудеса. Я вот тоже диктанты на пятерку писал, хотя классиками особо не заморачивался: скучные они, даже детективы, которые за авторством Достоевского. Но зато я читал много детективов и фантастики советских времен, и это, похоже, помогает освоению правописания не хуже.
Но вопрос то в другом - в осмысленности такой грамотности вообще. Но про это Мери Шелли уже давно написал, лет двадцать назад где-то.
Бессмысленный вопрос. В любом языке можно найти то, что кажется неразумным, не понимая, как за сотни лет он развивался и почему именно к этому пришел.
Вопрос не бессмысленный, по крайней мере - для того, кого заставляли изучать диалектику (вас должны были заставлять, кстати), ибо "не все существующее есть действительное", а мне как раз только это "действительное" хотелось бы, и ничего лишнего. Ну, а за остальное - спасибо, Кэп.
пошли эти самые правила
Ну как еще показать окружающим, что Вы занимаетесь откровенной демагогией? Только вынуждая Вас самого признавать, что Вы обсуждаете русский язык игнорируя его правила.
читал много детективов и фантастики советских времен, и это, похоже, помогает освоению правописания не хуже.
Непонятно только как. Ведь словарный запас всех "детективов и фантастики" вместе взятых с трудом дотягивает только до четверти словарного запаса Пушкина. А диктанты тем и отличаются от сочинений, что не сам выбираешь слова, а пишешь именно те, что диктуют.
изучать диалектику
А вот Вам это явно не довелось:
"не все существующее есть действительное"
так как в диалектике со времён Аристотеля "не всё возможное, есть действительное", а вовсе не Ваша отсебятина.
я не лингвист
Оригинально. То есть, Вы решили критиковать словообразование в русском языке, не разбираясь в обсуждаемой теме? )))
Много ли при вас в нашей действительности кого-то называли "надсмотрщиком".?
Вот видите. Для меня источник русского языка - это художественные произведения русских писателей. А в произведениях Чехова, Льва Толстого, Пушкина, Фонвизина, Гоголя и многих других это слово не редко встречается. А Вы апеллируете то к спекулянтам-челнокам, то к IT сленгу.
став обсуждать перевод слова view вместо viewer
Лгать нехорошо:
И только потом:
отглагольные существительные в английском образовывать куда проще, чем в русском
Что в итоге делает русский язык более богатым, чем английский. По количеству слов, примерно, двукратно.
Ваш аргумент не выдерживает никакой критики, так как очень многое зависит от корня. Даже тот же "viewer" переводится еще как "зритель" и "читатель". Но в русском языке омонимы встречаются намного реже, чем в английском, и для новых слов их пытаются избегать. Пусть даже применением столь возмутившего Вас суффикса -щик.
Лгать нехорошо:
Да нехорошо - не делайте так. Вы там написали слово view, которое на русский язык действительно переводится легко и заимствовать его не требуется. Но речь-то изначально в дискуссиии шла про другое слово - viewer, за что я вас и спросил. Из цитированной последовательности комментариев (непрерывной, кстати) это видно.
Оригинально. То есть, Вы решили критиковать словообразование в русском языке, не разбираясь в обсуждаемой теме? )))
Опять попытка подмены. С какого бодуна вы взяли, что я решил критиковать некое "словообразование". Мне не понравился результат такого словообразования, на что я имею право (да-да, судить о вкусе яичницы могут не только курицы).
Вот видите. Для меня источник русского языка - это художественные произведения русских писателей. А в произведениях Чехова, Льва Толстого, Пушкина, Фонвизина, Гоголя и многих других это слово не редко встречается. А Вы апеллируете то к спекулянтам-челнокам, то к IT сленгу.
Я это понял, но рациональным это не считаю.
Потому что язык - это средство общения, а потому рационально в качестве источника языка, живого языка, брать окружающих носителей этого языка. По-моему, так разумнее, не находите? Да, со старыми текстами давно умерших людей я тоже знаком. Только вот мнение, что надо брать за пример их именно язык, а не живой русский, я разумным не считаю: основной функции языка как средства общения оно противоречит.
И да, не понимаю вашего отрицательного отношени к людям, вам, якобы, неравным. Они ведь - такие же люди, которых, говорят, бог создал равными. Например, среди челноков 90-х (по крайней мере - мне знакомых) было немало людей, закончивших вузы и даже поработавших по специальности: ну, не всем повезло по блату зайти со своими программами в Сбербанк и далее - в представительство инофирмы, а потому приходилось крутиться). Правда образование у них было, по словам Михал Михалыча, "никакое, то есть - высшее техническое" - но и у вас ведь тогда тоже такое же было, да?
Ну, а IT сленг я в целом, кстати, не одобряю. И, в частности, вариант "вьювер" я не отстаивал, как бы вам это ни казалось. И, если вас это интересует - не собираюсь: даже "вьюер" (с произносимой 'й' после гласной, как это по-русски положжено) мне и то больше нравится - чисто по произношению.
Что в итоге делает русский язык более богатым, чем английский. По количеству слов, примерно, двукратно.
Опять вы ушли от существа вопроса: что подмена viewer на view сильно упрощает проблему перевода? Какое к нему отношение имееет богатство языка в целом, если в отдельном, нужном для перевода здесь и сейчас, аспекте он беднее того, откуда перевод нужен? Почему вы так не хотите вести дискуссию по существу вопроса?
Пусть даже применением столь возмутившего Вас суффикса -щик.
Я уже всерьез начинаю думать, что вы действительно меня настолько не понимаете, что даже "стремление выглядет значительным"((с)Карнеги) это не объясняет: мне же не не понравилось сочетание букв "трщ" (между которыми так и норовит влезть гласный звук), и я об этом писал, но вы почему-то это в упор не видете.
Из цитированной последовательности комментариев (непрерывной, кстати) это видно.
Ну если бы Вы прочитали содержимое скринов, то увидели бы, что отвечал я совсем не Вам и именно на слово view. Но Вы столь уверены в своих заблуждениях, что даже просто прочитать, то что Вам пишут не считаете нужным )))
С какого бодуна вы взяли, что я решил критиковать некое "словообразование". Мне не понравился результат такого словообразования
Если бы Вам просто не понравился результат, то молчали бы в тряпочку. Но Вы то стали его критиковать. Если Вам не нравится, что 2+2=4, то это критика сложения, а не вовсе не числа 4.
среди челноков 90-х (по крайней мере - мне знакомых) было немало людей, закончивших вузы
Можно закончить ВУЗ и остаться безграмотным. А можно не заканчивать и быть грамотным.
не всем повезло по блату
Как и мне. Мама погибла, отцу до меня дела нет, да и ничем за 1500 км от меня помочь он не мог, сам без денег сидел. Вот и приходилось и мороженным торговать, и фуры разгружать, и некондицию с завода ремонтировать на продажу, но продолжать при этом учиться и программировать, повышая свою квалификацию, что и принесло в итоге вполне ожидаемые плоды.
Какое к нему отношение имееет богатство языка в целом, если в отдельном, нужном для перевода здесь и сейчас, аспекте он беднее того, откуда перевод нужен?
В Вашей фразе целый ряд ложных утверждений. Во-первых, богатство языка, это в том числе и возможности его словообразования. И в обсуждаемом случае имеющихся в языке приставок, корней и суффиксов достаточно. Во-вторых, странно говорить о "беднее", если рассматриваемое слово, только на вскидку, имеет целых пять разных переводов на русский язык, в зависимости от контекста. Нет смысла заимствовать в русский язык слово "viewer", которое вне контекста обозначает "зритель" и только в более узких сферах - "телезритель", "осмотрщик", "окуляр стереоскопа", "просмотрщик". Особенно с учётом того, что последнее слово в русском языке существует уже более века. За технологию микрофильмирования и разработку просмотрщиков микрофильмов Буринский получил Ломоносовскую премию еще в 1898 году. И вот через 125 лет у Вас вдруг появляется идея исключить слово "просмотрщик" из русского языка, заменив его иностранным. Очень оригинально )))
сочетание букв "трщ" (между которыми так и норовит влезть гласный звук)
Не норовит. Сочетание, конечно, слегка неуклюжее, но куда там вставить гласную - не могу себе представить.
Нет никакого американского английского языка. Есть британский и есть те, кто говорят на нём с ошибками.
А где Вы увидели, что я писал об американском английском языке? В английском языке есть два официальных стандартизированных диалекта - британский и американский. К тому же выше речь шла вообще о произношении. Например, если отъехать всего на несколько сотен километров от Москвы - сразу это замечаешь. Например, Вологодско-Костромская речь отличается от среднерусской речи оканьем, а Курско-Орловская - аканьем. Или Вы будете доказывать, что наречий и, тем более диалектов, русского языка нет, а "есть те, кто говорят на нём с ошибками"? Начните тогда с наиболее известного противостояния между Питером и Москвой - бордюр или поребрик )))
К слову, на периферии москвичей по говору весьма точно идентифицируют.
Скорее вы говорите о том, что в словах вилка и тарелка нет мягкого знака, но это не мешает ему звучать на Кавказе "вилька, тарелька". Также и с английским словом doctor, которое в штатах произносят по-своему.
Давайте Вы все же акценты не будете путать с диалектами. Хотя бы, чтобы не выглядеть демагогом подменяющим понятия.
Именно поэтому я и предложил Вам начать с бордюра и поребрика, что явно относится к диалектам.
Скажите это Елизавете II, высказывание которой я процитировал.
С каких пор Елизавета II получила право устанавливать стандарты языка? Ладно еще в Великобритании. Но какое отношение она имеет к США? Еще раз, в английском языке есть два официальных стандартизированных диалекта - британский и американский. И никакой Елизавете II это не изменить.
Ну уж у кого кого, а у английского монарха побольше прав говорить о том такое английский язык, чем у пары диванных аналитиков с популярного-технического сайта из русскоязычного сегмента интернета ))
Говорить монарх Великобритании может что угодно. Но юридически его слова никакой силы не имеют не только для Содружества, но и для самой Великобритании. Тем более у нее нет прав указывать США, каким должен быть SAE.
пары диванных аналитиков
Прошу прощения, но я ссылаюсь на законодательно принятые стандарты английского языка в Великобритании (SBE) и США (SAE), чем и отличаюсь от такого действительно диванного аналитика, как Вы )
Начните тогда с наиболее известного противостояния между Питером и Москвой - бордюр или поребрик )))
В смысле - с того, под каким одним словом правильно объединять два изначально разных понятия?
С точностью наоборот. Когда один тот же объект в Питере называют поребрик, а в Москве - бордюр. Неплохо так же разобраться со спором батона с булкой, водолазки с бадлоном и гречки с гречей. Это я только по питерскому и московскому диалектам проехался.
Если не ошибаюсь, то в профессиональной терминологии (у дорожных строителей) есть общий термин для обоих понятий - "бордюрный камень".
Это тоже самое, что называть булыжником мостовую. Бордюр (или поребрик) изготавливается из бордюрного камня.
И американский и британский диалект произошли от одного предка. И британский с тех пор изменился сильнее. Разделение bath/trap произошло именно в современном британском, а не было присуще предку из царицы морей. Так что кто еще говорит неправильно,
Никто же не читает "ренаулт", "куеуе", "бузинесс".
Я читаю, особенно "куеуе", хотя знаю, как оно на английском правильно читается. Долгие-долгие годы изучения немецкого дают о себе знать.
А char часто хочется прочитать как "хар" или хотя бы "шар" (по аналогии с немецким "chance")
Ну в явном виде редко встречается, но бывают и ренаулты и пеугеоты, ну и что уж кривить душой - никто не говорит "хёнде", а все говорят "хюндай".
А для себя, в своей компании, я люблю эти слова говорить так как написаны, меня это немного веселит. Вне компании я конечно стараюсь говорить так, чтобы меня поняли, но если я скажу "хёнде" то скорее все подумают что я имею в виду "хонда".
Слово queue - как я понял вы его именно написали, я не знаю как читать правильно, поэтому оно для меня всегда "куеуе", так же со словами типа "length" или "through", в моей голове они звучат как "ленгтх" и "троугх", это в первую очередь связано с тем, что я пишу всегда диктуя себе в голове и если я продиктую "фро" или как оно там правильно, то я сам не буду понимать что мне написать, мне нужны буквы, а не звуки. Ну а "length" я всегда называл "ленч", абсолютно не знаю откуда это повелось.
Но в слове "view" нет второй "в" и никогда не было
Скажу больше, там нет первой "в", как изучавший немецкий я там вижу "фив", а ваша "queue" - это "квойе" (ˈkvɔɪ̯ə), ну и "business" это всё же "бузинес" ([buˈziːnəs]), хотя у немцев двойная "s" будет как "ß".
Скажу больше, там нет первой "в", как изучавший немецкий я там вижу "фив", а ваша "queue" - это "квойе" (ˈkvɔɪ̯ə)
У Вас таки лучше немецкий сохранился. У меня это вспоминается только после некоторого напряжения памяти. Но по английски правильно все равно произносить не хочется.
Как ни странно, но я всегда считал что в школе плохо учил немецкий, хотя спокойно читал немецкие газеты и переводил всё что в учебнике. Немецкий мне кажется более стройным и понятным, но в жизни совсем не пригодился, разве что лет 5 назад познакомился с игрой Rust (не с ЯП) и там был какой-то сервер с бандой немцев, я им даже что-то писал и понимал ответы :) Но в целом мышление именно из-за программирования сильно ушло в английский, хотя касательно слов и написания в голове конечно кордебалет полный.
У нас еще поборники чистоты английского часто вообще забывают что английский мир очень неоднородный и как минимум делится на british и american, где всё тоже весело.
Лично мне не приходится вести переписку или общаться на английском, поэтому я всё делаю так как мне удобно и когда я программируя пишу public void SomeClass, то я диктую - публик воид СомеКласс. Я уверен что Джону и Майклу в Дакоте глубоко плевать как я это произношу в своей голове )
Renault и queue вообще слова французского происхождения.
тимвьювер
Как можно так говорить и писать при наличии слова «интервьюер», которое успело достаточно обрусеть и стать широкораспространённым?
Тут ведь главное чтобы меня понимали, мне по большому счёту вообще всё равно. А большинство тех с кем идёт переписка или общение говорят и пишут "тимвьювер". Тут же нужно понимать что кроме английского люди и немецкий изучают, а изучавшие английский дай бог "spar" без ошибок прочитать смогут.
Ну и до того как начать доколупываться к таким иностранным словам неплохо бы русский язык чтобы все знали идеально, чего совсем не наблюдается.
PS: вот вы знаете такое слово "файликмультифора"? А я знаю и говорю я его регулярно, потому что половина людей знает что такое файлик, а вторая половина - мультифора и чтобы не выяснять кто и как меня поймёт я говорю так чтобы было понятно всем. Тупость? Ну наверное, но мне главное чтобы меня понял рядовой гражданин, а не чтобы одарённый филолог одобрил.
Математику пусть знает заказчик или бизнес-аналитик — вот им она полезна, т. к. позволит правильно поставить задачу.
А кто должен знать какие данные должен предоставить заказчик: сам заказчик или программист?
Автор работает в институтах, решая местные прикладные задачи. Могут предложить, что его заказчики это учёные, которые вполне могут объяснить свою задачу со стороны домена в мельчайших подробностях. За программистом остаются технологии.
Когда заказчик не может сформулировать задачу, про какие данные вы у него спросить сможете? Я работал на заводе, хотели внедрять ERP, за 3 года ни один отдел не смог подготовить ничего. Вы предлагаете мне ходить между 1500 человек, осваивать все техпроцессы и готовить данные? У завода столько денег нет чтобы меня на это сподвигнуть.
Я тут недавно читал, что алгоритм бинарного поиска (целиком рабочий) опубликовали сильно позже того, как открыли. Так что не сказать что это мелочи.
Ну и с вашим подходом все можно назвать не алгоритмом и не математикой - надо нам фигуру подвигать, да что там те векторы, сложил,вычел. Надо фильтр написать простой, да тоже самое. Но все же нет, работает это не так
Дело в том что это работает и везде, причем и в коммерческих продуктах. А алгоритмический перфекционизм он существует где-то там, но где - нам не говорят.
Алгоритм бинарного поиска используется для поиска страницы в книге. Я буду сильно удивлён, если Пушкин искал нужные ему отрывки линейным просмотром.
Сомневаюсь что это бинарный поиск, возможно вариация на тему, но не классический. Простой пример, вам нужна 174 страница, вы открыли книгу на половине, там 215 страница, вы не станете нижнюю часть книги делить пополам, вы возьмёте несколько страниц и посмотрите на результат, например 191, возьмете еще несколько, станет 176, а потом по одной.
Ой, "целиком рабочий" - это без переполнения со сложением? Тот, что вместо m = (a+b)/2 делает m = a+(b-a)/2? Да просто пару десятков лет инта хватало с большим запасом, вот и не парились с обработкой данных, которые едва влезают в тип.
В школах и непрофильных специальностях вузов изучали (80-90-е) наивные алгоритмы, сдавали зачеты и вопрос закрывался. Возможно на профильных в москвах это было иначе. Мы на теории и технологии программирования даже бинарный поиск не изучали, сортировок вообще не касались. Потом я всё это читал у Страуструпа, но до применения никогда дело не доходило, так как оперирование большими объемами данных никогда не происходило и всё делалось или наивным способом или std:sort.
Вот одна моя история когда я столкнулся с проблемой, у меня была локальная sql таблица с 200000 записей и любые манипуляции онлайн происходили по 10-15 секунд, что было очень неудобно. Я создавал два потока и кешировал запросы, а при простое - склеивал базы. Это работало, но иногда ломались сами базы. Для чего они у меня постоянно бэкапились.
А чуть позже я рассказал о проблеме своему знакомому 1С-нику и он сказал - а ты в памяти держи базу и обновляй только в конце работы или по кнопке или по закрытию окна. Попробовал - оно стало работать моментально и без потоков, проблема с поломкой баз тоже ушла.
Всё. И это за 35 лет. Жизнь у всех разная как и профессиональная деятельность, поэтому как я во всех подобных статьях и пишу - умение в алгоритмы пригодится вам только на позиции уметора алгоритмов. А 99 ваших коллег будут писать:
if (a==1) then
if (a==2) then
...
if (a==21837463653) then
и получать ту же зарплату что и вы.
Убили как-то друг друга программист компьютерной графики и фронтенд-разработчик, споря о том, должен ли программист отлично знать линейную алгебру. Попадают к апостолу Петру и просят рассудить:
– Апостол Пётр, – говорит программист компьютерной графики, – я не выдержал и стал душить его, макаку вебную, ожидая, что он согласится со мной.
– Нет, это я не стерпел и стал душить его, олимпиадника сутулого, ожидая, что он согласится со мной, – перебил фронтенд-разработчик.
Не выдержав, программисты снова сцепились.
– Лучше бы вы дедлоков избегали... – проворчал Пётр.
А какие у разработчиков ui дедлоки то? Ui на своем потоке рисуется, все знают что если его завесить, то хорошим дело не кончится. Так что оба этих товарища делоки создадут с очень малой вероятностью, ну на ui слое как минимум
Ну классика же! Если при сохранении одной формы сначала выполняется UPDATE первой таблицы, а затем уже агрегаты сохраняются во второй, а на другой форме сделано с точностью наоборот, dead lock рано или поздно поймаете.
Ну, тут дедлоки были про несколько другое (:
Ну например- если я фетчу данные из нескольких мест, обрабатываю/комбинирую их и делаю составное представление, причем запросы не коммутативны - получается классическая проблема асинхронищы, в точности как в бековском программировании.
Где параллельные процессы - REST запросы, а вьюшка - разделяемый ресурс
Выскаду своё личное скромное мнение, я считаю что хранение алгоритмов обязательно для каждого специалиста в сфете т.к. это база на которой построена по сути вся информатика, это все равно что быть программистом и не знать что ПК опирирует нулями и единицами, а не строками символов и т.д. и это уже не говоря о том что функции ( базовые конструкции большинства языков программирования это по сути частное представление тех же алгоритмов, но уже созданных человек для решения какой-то конкретной задачи).
НО! На сколько хорошо и глубоко нужно вникать в эту тему это уже другой вопрос и для каждого человека ответ будет разным.
Программист прикладного уровня должен знать в первую очередь архитектуру приложений и как её строить, как писать читабельный код, и как умело пользоваться теми ресурсами ПК которые были ему выделенны для решение конкретно это решения, и это уже не говоря о том что почти во всех высокоуровневых языках программирования все необходимые базовые алгоритмы уже давным давно интегрированны в различные библиотеки и фреймворки, и расписывать огромный алгоритм каждый раз когда вам надо отсортировать какой-либо набор данных это будет как минимум глупо, а как максимум безумие.
В итоге: Да, знать алгоритмы должен каждый IT специалист, точно так же как каждый специалист должен знать и понимать устройство того с чем он работает (ПК), для большинства программеров знания базовых алгоритмов будет более чем достаточно что бы работать 10 - 20 лет в своей сфере и чувствовать себя комфортно, но узко направленным специалистам в какой-то конкретной сфере может понадобится значительно расширить свои познания для того что бы успешно работать с какими-то конкретными технологиями.
Умный математик с Уральских гор нарисовал для него какой-то скрипт
реально умный математик применил бы awk с вызовом из bat-файлов. для MS DOS были реализации. работали даже на 8086 (т.е. i386 не обязателен), работали заведомо быстрее Quattro Pro.
вывод: алкаш не ту книжку подарил. надо было такую:
http://flibustaongezhld6dibs2dps6vm4nvqg2kp7vgowbu76tzopgnhazqd.onion/b/402132
Те, що преподают? - Нет.
Взять даже дурака как джуна с улицы и научить сначала на примерах, потом с вкраплениями теории на порядок проще. Чем брать с курсов универов и т.п. самоуверенного дурака с инициативой и переучивать...
По факту сначала будет обучение "Логике": если A => B => C, то A => C (=> равно "следует).
Далее часть простой доказательной геометрии, как получать нужный результат, расписывая все "ходы". А потом, когда школьный базис будет на уровне нормального 3банщика старой норм школы - тогда можно говорить даль.
Ибо нарот вообще дупля не режет просто в очевиднейших вещах...
Ну и главное - нахрен всяких HR. Пусть вместо них собеседуют клинические психологи - набор же не в кунсткамеру или палату №6. А остальному научим, так и быть. лишь бы человек нормальный, вменяемый, адекватный был)
У нас было два семестра численных методов. Ну всякие там Рунге-Кутта, системы линейных и нелинейных уравнений, диффуры, вот это вот всё. Первый семестр на Фортране, а второй - на Паскале (дело в середине девяностых). За тридцать лет что-то писать "с нуля" не потребовалось практически ни разу, в основном потому, что есть хорошие мат библиотеки, где всё это реализовано. Но курс был пройден в общем не зря, так как несколько поворачивает мышление в алгоритмическую строну, плюс даёт возможность ориентироваться в алгоритмах. Несколько книжек по алгортимам у меня всегда под рукой, если что туда всегда можно заглянуть. Четырёхтомник Кнута как справочник - вполне хорош.
Пример - в этом году у меня был довольно жёсткий по срокам проект, и мне в помощь выдали девушку-контрактора, мастерицу на все руки, работающую удалённо. По ходу работы возникает необходимость сделать несложную аппроксимацию полиномом. Я ставлю задачу - смотри, я отдаю тебе два массива - по х и по y, ты строишь по ним полином второй степени и возвращаешь коэффициенты и ошибку. Потом я даю тебе y, а ты смотришь корни и возвращаешь мне обратно х, тот что меньше. Точки сидят на полиноме хорошо, метод наименьших квадратов вполне подойдёт. Вроде всё просто, работы максимум на полдня, да и то если с перекурами. Это притом, что в мат библиотеке есть готовые функции, ну и весь интернет полон исходников, надо только знать где и что искать. Даю ей день - завтра мне понадобится. На следующий день вижу с трудом вымученную кусочно-линейную интерполяцию... По итогу это почти неделю заняло, но в конце она разобралась.
Математика это вообще сложно на самом деле. Я иногда такие перлы творю с всякими векторными преобразованиями, хотя казалось бы... Так что если понятно вам, не значит, что понятно всем. Иногда мат аппарата не хватает, а улучшать его - всегда время.
Вам это давали, вам хорошо. А я учился на инженерной специальности, и программирование свелось к одному семестру Паскаля раз в две недели и куче пар скриптового языка прочностной программы. В итоге, когда мне на первом году работы понадобилось для решения одной задачи искать площади под графиками - я написал метод Симпсона, потому что понятия о библиотеках не имел, а переходы в коде были сделаны через if. Потому что иначе я не умел, а решить задачу было надо.
IMHO, самое главное, что дает высшее образование, вовсе не знания по специальности, а умение быстро изучить любой предмет в рамках своей сферы (технической, медицинской, экономической и т.п.) самостоятельно. Порой даже изучить, использовать (например, сдав экзамен или завершив проект) и забыть. А работать, используя только то, чему научили - это уже уровень среднего специального (профессионального) образования, а вовсе не высшего.
Все же сам ты болтаешься в своем болоте.
Общение с коллегами полезно.
Общаться могут и люди со средним специальным образованием.
Иногда даже полезна смена коллектива. Открываются новые вещи, которые не использовались ранее в старом коллективе.
Это не значит что я против самообразования или только за общение.
Совершенно не понял связи между Вашим ответом и тем, что написал я. Общение - это одно, беспрерывное самообразование, жизненно необходимое в столь быстро развивающейся отрасли, как IT - совсем другое. И они никак не могут заменить друг друга. И никак не мешают друг другу.
Я о том, что:
ВО не дает (не только ВО дает) умение самостояльно изучить предмет. ВО также может дать и знания. А может и не дать.
Образование (или умение учиться) - это одно. А иногда (часто) коллега может показать то, что ты ранее не видел.
Если после множества курсовых и дипломных проектов студент так и не научился самостоятельно изучать предметы, то, на мой взгляд, диплом он получил нечестным путём. Ну или ВУЗ вообще никакой, что у него курсовые и дипломные проекты можно защитить, не изучив что-то самостоятельно.
Даже работая в крупных компаниях интеграторах, я намного чаще узнавал то, что не видел ранее, вовсе не у коллег, а изучая предмет по книгам и в интернете. Понятно, что встречаются какие-то самописные системы или фреймворки, у которых просто нет качественной документации. Тут уже без помощи коллеги изучение по исходникам будет слишком медленным. Но это, скорее исключение, чем правило.
Студент мог и не научиться самостоятельно изучать предметы. Но мог и уметь до вуза. Мог научиться и без вуза. Я просто не понимаю выражения "не дает знания, а учит учится". Это как? Учит гуглить? Хотя в интернетах нет многого, что есть в книгах.
Я не имел в виду, что коллеги чаще. Я о том, что можно вариться в своем болоте, но иногда смотреть на других. А еще бывает полезно парное программирование. Не на постоянной основе.
Да, я знаю такие случаи. Но, например, академические знания по техническим наукам, экономике или юриспруденции легче получать в ВУЗе, чем осваивать их самостоятельно. Слишком уж высоким уровнем самокритики нужно обладать человеку, что экзаменовать себя на уровне стороннего экзаменатора. А на практике эти знания проверить сложно. Можно только упереться в их нехватку.
Это как? Учит гуглить?
Поисковик может лишь помочь найти книгу, научную статью, реферат или диссертацию. В редких случаях - готовый ответ. Немного разобраться в теме можно поспрашивав в конференциях. Но действительно хорошо изучить предмет можно лишь объясняя его на тех же конференциях задающим по нему вопросы.
Хотя в интернетах нет многого, что есть в книгах.
И какую же книгу нельзя найти в интернете? Даже купить электронную версию книги намного проще, чем бумажную, которой может просто не быть в запасах.
Опять не понял о чем Вы. Вот тут сейчас каждый из нас "варится в своем болоте" или все же учится у других? Ну за исключением тех, кто тут ради собственного ЧСВ, а не ради самообучения.
Чтобы изучить - надо знать, что такое в принципе есть. И нужен всё-таки стимул для изучения.
Я этого Симпсона написал на C# в Матлабе, изучив и Шарп и Матлаб (до нужного мне предела) самостоятельно. И программа уже лет восемь работает, исправно считая нужные мне параметры. То есть предмет в достаточной для меня рамке я изучил, а не использовал только существующие знания.
Но для того, чтобы изучить предмет - надо знать, что такой предмет в принципе есть. Я этого на тот момент не знал и считал, что переходы через if - единственно верный путь. А потом узнал, что не единственно.
Чтобы изучить - надо знать, что такое в принципе есть.
Это как раз и есть одна из главных составляющих самообучения - отслеживание нововведений и стороннего опыта. Если не по статьям и рефератам, то хотя бы по новостным сайтам своей профессиональной тематики.
Я этого Симпсона написал ... считая нужные мне параметры
Почему то мне кажется, что тиражируемость и масштабируемость этого решения нулевая, а кроме Вас его никто не сможет поддерживать. А это признаки любительского программного продукта. И именно по одной их этих причин даже гениальные начинания в Open Source оказывались ненужными и забытыми.
Если не по статьям и рефератам, то хотя бы по новостным сайтам своей профессиональной тематики.
Именно что своей. Моя специальность - проектирование и испытание некоторых изделий. А программирование - не моя. Программу я использовал как вспомогательный инструмент для решения задачи, которая до меня делалась вручную, для каждой кривой отдельно.
И здесь - вопрос более широкий, о границах своей компетентности в решении задач при условии, что заведомо компетентного сотрудника в организации не имеется. То есть - либо я делаю задачу вручную и постоянно на это трачу кучу времени, либо я максимально быстро пишу программу как умею, либо погружаюсь в не свою специальность, при том что остальную работу с меня никто не снимает, и компетентен-то я в ней.
Вообще могу по опыту сказать, что таких штук написано очень много. Написано плохо, написано на единственно известном сотруднику языке, написано так, что никто кроме сотрудника не разберется. Потому что, например, специалисту проектированию виброопор ставится задача - подобрать оптимальную развесовку дизеля на этих опорах. Он может либо вспомнить вузовский учебник по сопромату и посчитать как учили в вузе - на бумажке в несколько итераций и потом повторить для каждого нового изделия, либо накидать простую программу, которая будет считать это быстро. Вариант "Заказать программу настоящему программисту" у него отсутствует, а осваивать правильное программирование самому ради одной программы на сто строк - нерационально. Так и рождается специфический неподдерживаемый софт.
И, что характерно, аналогичная ситуация наблюдается (вот буквально позавчера) в другую сторону. Если у человека есть сварочный аппарат, куча ненужного железа и задача "сделать ключ на внутренний шестигранник 22" - он не будет окунаться в сопромат, а сварит так, чтобы оно точно выдержало. Потратив больше железа, чем можно было бы, но железа-то куча, его не жалко, а прикипевшую заглушку надо открутить как можно быстрее.
Простите, если я Вас чем-то задел или обидел. Никаких претензий к Вам не имею. Вы сделали что могли, как смогли и получили требуемый результат. Вы молодец!
Он может либо вспомнить вузовский учебник по сопромату и посчитать как учили в вузе - на бумажке в несколько итераций и потом повторить для каждого нового изделия, либо накидать простую программу, которая будет считать это быстро.
Ну программу писать для этого, на мой взгляд, излишество. Когда мне потребовалось перепроверить проект нового дома, который мне строят, я всё пересчитал в Maxima. Благо после того, как в ней получились общие формулы, считать по ним, подменяя переменные, можно многократно. И правильно, что пересчитал. По ряду мест строители перезаложились в несколько раз, а по ряду - наоборот, запас был ниже допустимого.
так, чтобы оно точно выдержало
Но при конструировании такое не проходит, так как лишняя масса, особенно движущихся деталей, начинает тянуть за собой остальное.
прикипевшую заглушку надо открутить как можно быстрее
По моему опыту, это не тот случай, где сила всё решает. WD-40, слесарный молоток и терпение тут дает намного лучший результат, чем оторванная головку болта, который даже экстрактором потом не достать - только высверливать. К тому же в данном случае излишняя масса существенно усложняет отжиг, закалку и отпуск, без правильного проведения которых в месте сварки даже с 40ХФА, не говоря уже о 50ХФА, гарантированы напряжения и трещины. Чему только в деревне не научишься )
Ну программу писать для этого, на мой взгляд, излишество. Когда мне потребовалось перепроверить проект нового дома, который мне строят, я всё пересчитал в Maxima
Это тоже вариант (правда, я обычно беру Mathcad), и первые разы я так и делал, но программа получилось более гибкой. А следующей итерацией стало затолкать это в прочностную программу (ANSYS), и кроме развесовки я получил возможность видеть формы колебаний.
оторванная головку болта, который даже экстрактором потом не достать - только высверливать
Не, с заглушкой было несколько иначе. Там была коническая резьба, диаметром около 40 мм, и в заглушке - шестигранное углубление под ключ 22 мм. Завернуто оно (20 лет назад и на фумку) было так, что ударный гайковерт с моментом 500 Нм эту заглушку не взял. Тогда наш слесарь просто взял шестигранный пруток, приварил к нему другой пруток так что получился вороток, и всё это мы провернули двумя метровыми трубами. И сила таки решила, и оно выдержало.
я обычно беру Mathcad
Ну для частных целей покупать лицензию на MathCAD - это тоже излишество. Я согласен, что он удобней и функциональней Maxima, но мне такие дебри просто ни к чему. К тому же Maxima замечательно живет на смартфоне и планшете, чего не скажешь о MathCAD
взял шестигранный пруток, приварил к нему другой пруток
Так в этом и проблема, что слизать в круг шестигранник из обычного прутка можно даже полуметровым рычагом. Сам убедился. Нужна хром-ванадиевая сталь. Лучше 50ХФА, но можно, как в китайских инструментах, ограничиться 40ХФА. А вот ее варить можно, только с отжигом, закалкой и отпуском, чтобы при быстром нагреве и остывании не образовалось напряжений и трещин. Так что Вам просто крупно повезло.
ударный гайковерт с моментом 500 Нм эту заглушку не взял
И не возьмет. Это Вам любой опытный автомеханик скажет. Аналогичные заглушки в картерах дифференциалов именно так прикипают. Масло то меняется там раз в 100-150 тыс. пробега. Так что приезжают к ним автомобили, где эти заглушки лет по 10 не трогали. Особенно на заднем дифференциале сливная пробка всю грязь собирает. А сорвешь резьбу - будешь менять чуть ли не весь дифференциал. Поэтому именно слесарный молоток тут в помощь. Пять-десять минут обстукивания с поливанием WD-40 - и заглушка начинает идти. Главное не торопиться.
мне правда интересно, а как много программистов в СССС и РФ изучали в вузе ЯП до состояния профи?
я в вузе изучал Бейсик, Clipper/FoxPro, C, Pascal, Delphi, ASM, просто я учился в двух разных вузах, разные преподы. Но ни у одного не было цели научить нас программированию как таковому. И уже работая я изучал то что мне было нужно.
ВУЗ это же про методики обучения, про умение читать литературу, анализировать, системно мыслить.
И даже сегодня я вижу много молодых людей, которые в мир программирования зашли через питона или C# сразу в ООП и что они программируют совсем иначе и чаще всего сильно лучше меня. Мне кажется это правильно.
В МИЭТ была неплохая кафедра прикладной математики. Уже на первом курсе курсовая была по распознаванию образов на ЕС-1033 (FORTRAN и PL/I). Много математики уже было на FORTRAN, вот и получался такой бутерброд.
программируют совсем иначе и чаще всего сильно лучше меня
Это уже опыт. Но вроде бы лучше программируя, такие часто сыпятся на задачах, требующих более глубоких знаний. Например, недавно пришлось самому писать класс на С# для поддержки Java BigDecimal в Protobuf/Confluent, так как это оказалось быстрее, чем объяснять разработчику, чем дополнительный код отличается от прямого и big-endian от little-endian. А задача откровенно разовая.
ВУЗ это же про методики обучения, про умение читать литературу, анализировать, системно мыслить.
У нас даже был предмет о каких-то методиках, но всем на него было пофиг.
Вот какие методики Вы недавно применяли? Вы научились им в вузе? Или они применяются неосознанно?
Что такое уметь читать литературу, а что такое не уметь?
Умение системно мыслить - а это не скорее черта характера? Или когда черта характера - это чересчур?
Вот какие методики Вы недавно применяли
Не уверен что это именно так работает. Это выработанное бессознательное. Человек с высшим берёт в правую руку палку, встает в позу, а человек со средним образованием много прыгает в боксерской позе. Условно.
Вы научились им в вузе?
Любой предмет - это методика работы с чем-то. Да, я учился в вузе, а значит я учился методикам.
Или они применяются неосознанно?
Думаю да.
Что такое уметь читать литературу, а что такое не уметь?
Ну как же, а "Смотрю в книгу и вижу фигу"? Книга, особенно для вузов, это структурированный документ, с ним учат работать, эти навыки позднее помогают работать с неструктурированными документами. Находить соответствия, выделять главное и т.д.
Умение системно мыслить
Мне кажется это приобретаемый навык. В моем случае я всё в жизни воспринимаю как решение алгоритмической задачи, а всё что не поддается такой классификации (даже не смогу вспомнить что именно, например отношения людей), то мне уже даётся сложно.
Отношения людей — это тоже алгоритмическая задача, просто её решение сильно усложнено тем, что в ней участвует огромное число скрытых параметров, все из которых узнать невозможно в принципе. Например, одна девушка признавалась, что в раннем детстве некий парень её как-то там обидел. При этом он был блондином — и поэтому теперь для любого блондина у неё сразу по умолчанию -100 баллов к привлекательности. Если некий блондини сейчас попытается к ней подкатиться, то с вероятностью 99,99% он пойдёт лесом — но понять "но почему???" никогда не сможет.
Все верно. Главное - знать что не знаешь. Тогда при необходимости сможешь узнать.
Совсем не обязательно знать все алгоритмы "изнутри" (уметь их реализовать самостоятельно). Но знать какие бывают, понимать в целом как оно работает и представлять основные их особенности и граничные условия для применения желательно хотя бы для того, чтобы в каждом конкретном случае выбрать наиболее подходящий.
Кнут нужен на уровне знания, какие алгоритмы и структуры есть и где их применять, да. Чтобы как минимум сходу выбрать подходящий, как максимум – пролистать соответствующий раздел. Главное – чтобы человек там, где не разбирается, не лепил что попало.
Оксюморон какой-то )
Непрекращающиеся разговоры на тему "надо/ненадо" свидетельствуют о следующих фактах:
Уборщицы выступают за узкую специализацию - я уборщица и больше ничего от меня не требуйте!
Дворники шестого разряда указывают уборщицам на редкие ситуации, когда махать шваброй реально нужно уметь.
Руководители клининговой конторы считают бабло и понятия не имеют о глупых (по мнению руководства) разговорах персонала.
Если кто-то хочет ограничить свои знания - ну пожалуйста, кто же против? Зачем им возражать? Но возражения появляются с завидной периодичностью. Почему так?
Потому что дух ограниченности, при его массовом распространении, убивает интерес у дворников шестого разряда. И дворники негодуют. Плюс дворники хотят, что бы их оценивали выше уборщиц. Но нужно обоснование. И вот оно - я знаю алгоритм махания шваброй, а уборщица не знает! То есть дворники нашли простой критерий, как им выделиться на фоне уборщиц. Осталось доказать начальству, что этот критерий обязателен к применению. В гуглах и прочих амазонах уже получилось, а что, остальные дворники, рыжие что-ли?
Немного по другому - всё сводится к обычному доминированию. Я хочу быть выше (по деньгам, статусу, всему остальному). Как мне выделиться? Я умею в алгоритмы! Но кому это нужно?
Итак, стремление к доминированию привело броуновское движение дворников к согласию по главному тезису - мы лучшие (это аксиома), а значит мы должны доминировать (это тезис). Доказательство - мы знаем, что такое алгоритм. Всё по шаблону - дано, условия, решение. Вот какие мы молодцы.
Ну и что, если знание алгоритмов действительно не нужно уборщицам? Ведь вопрос же не в поиске эффективного решения для какого-то там начальства (и правда, зачем оно нам?), проблема же в доминировании.
ЗЫ.
Мне самому неприятно, что нами правят уборщицы. Но извините, ставить доминировать вместо них тех, кто подменяет эффективность в широком смысле формальным определением весьма узко трактуемого понятия, есть ситуация типа "менять шило на мыло". Даже если все гуглы на свете приняли диктат дворников.
На мой взгляд, не надо приравнивать знание алгоритмов к зубрёжке их на литкоде. В моей практике нужны две вещи. Во-первых, представление о том, какие алгоритмы применимы в конкретной ситуации, чтобы за пять минут нагуглить нужный, даже если деталей не помнишь. Назовем это математической и алгоритмической базой. Во-вторых, требуется умение рассчитать сложность алгоритма и выбрать из нагугленных наиболее эффективный, опять в конкретной ситуации. Просто чтобы не тратить время в пустую, кодируя все варианты и сравнивая их.
Что касается даже сортировки, то, во-первых, ряд задач, требующих на первый взгляд сортировки, эффективней решить и без неё. Например, для поиска нужных элементов в массиве можно его отсортировать и применить двоичный поиск, а можно создать хеш таблицу. И для каких-то задач эффективней будет первое, а для каких-то - второе. Во-вторых, для разных наборов данных разные алгоритмы могут очень сильно выигрывать или проигрывать в эффективности относительно друг друга. Например, применять QuickSort для почти отсортированных данных - не лучшая идея. Например, timesort тут может оказаться в разы эффективней. При этом совершенно не требуется кодировать алгоритм сортировки. Почти все уже давно закодированы. Нужно уметь выбрать наиболее эффективный.
Вот что я считаю "знанием алгоритмов". Теперь меня можно покусать и попытаться переубедить.
Ну, таким макаром можно дойти и до того, что программисту и знание четырех арифметических операций не нужно. Давно вы в столбик числа складывали/умножали/делили? Вот то-то. Однако, это нонсенс - программист без умения складывать, умножать, вычитать, делить. Хотя в некоторых профессиях такое часто встречается.
Вернемся к бинарному поиску. Да, вам скорей всего никогда не потребуется изобретать этот велосипед, но... хотя бы поверхностное знание сути этого алгоритма полезно для выбора алгоритма, для понимания будущих проблем (зависимость от объема данных).
Пример: У вас есть список объектов, вы знаете, что список этот пока небольшой и заморочки не нужны, вы принимаете решение сделать простой линейный поиск, но... в уме подразумеваете, что в случае чего вы сможете резко ускориться (и знаете на сколько), применив бинарный поиск, но пока это излишне.
Вопрос: понадобилось вам знание алгоритма бинарного поиска? С одной стороны, в реализации вы его его не применили, но с другой стороны - в анализе ситуации вы его учли и отбросили сознательно, взвесив все за и против.
Давно вы в столбик числа складывали/умножали/делили?
Ежесекундно.
Да, вам скорей всего никогда не потребуется изобретать этот велосипед
Наоборот, велосипеды изобретаются постоянно, как раз незнание этому способствует.
для понимания будущих проблем (зависимость от объема данных)
Я с большим объемом данных пересекался только однажды, изобрел свой велосипед, проблема закрыта. Про BigO узнал в 45 лет на Хабре. До того дня программировал, и после этого знания в моей программерской жизни ничего не поменялось, разве что когда делаю два FOR по N то знаю что это O(N*N). Что бинарный поиск это бинарный поиск никогда не знал, узнал тоже тут, но именно таким поиском пользовался сам еще с 90-х, сам придумал. Но только если данных больше некоторого значения, иначе проще линейно.
Вопрос: понадобилось вам знание алгоритма бинарного поиска? С одной стороны, в реализации вы его его не применили, но с другой стороны - в анализе ситуации вы его учли и отбросили сознательно, взвесив все за и против
Когда я пишу программы то примерно в 80% случаев я реализую наивный подход во всем. Программу заставляю работать, а потом, когда реализация готова занимаюсь оптимизацией, но только если это реально что-то даст. Например есть ли разница в работе программы 0.002 мс или 0.4 мс? Так-то разница в 200 раз, но вы дольше будете запускать программу, чем она будет выполняться. Мест, где написание софта объемно, критично и ответственно - весьма хватает, но еще больше тех мест, где это не важно абсолютно, именно поэтому "взвесив все за и против" выбирается почти всегда наивный подход. Времена 8-битных машин далеко позади, там счёт шёл на каждый такт ЦПУ, сейчас за этим нужно следить только в строго обозначенных направлениях. Например неповоротливость сайта куда сильнее зависит от того, что в него напихали видео на 500 мб и анимашек на джаве и CSS всяких, чем от того как именно вы выводите текст на экран через p, div или table.
Убеждать себя что алгоритмы не нужны это как пардон мочиться против ветра - вроде все получается, но есть какой-то странный сайд эффект. Хочешь писать код в достойном месте за хорошие деньги - с 99% вероятностью тебя попросят решить что нибудь из литкода, за вас уже все давно решили
Кому-то наверно нужны.
Кому-то не нужны.
Не было бы вопроса, если бы всем были нужны или всем не нужны.
Кому-то в одной степени, кому-то в другой.
Удивительно странный вопрос с учётом того, что программирование - это написание программ, а программа - это и есть совокупность алгоритмов. Так что знание и понимание алгоритмов как дисциплины - не просто полезный, но строго обязательный навык. Это всё равно что спросить "нужно ли водителю знать ПДД" или "должен ли врач знать анатомию".
вы немного запутались, автор во фразе "нужно ли знать алгоритмы" говорит о знании определенных алгоритмов для решения конкретных задач - поиск, сортировка, сжатие и т.п. То есть классы задач, которые являются универсальными алгоритмами.
А вот то о чем говорите вы - это создание неуниверсального алгоритма. Если бы написание вами программы было универсально, то мы давно имели бы в библиотеке std всю вашу программу. Но в реальности в библиотеки попадают в основном умножения матриц, поиски и т.п. Так что ваше описание уместно, но не в тему.
Алгоритмы - и есть программист. Программист - это и есть алгоритмы, квинтесенция алгоритмов, газонокосильщик алгоритмов.
90-е это не начало компьютерной эры человечества, более того, к тому времени отрасль уже успела пройти кризис видеоигр 80х, а многие вкусные и легкодоступные плоды отрасли уже были съедены. В плане научной карьеры в computer science уже почти ничего не оставалось для новых открытий, а в плане бизнеса отношение заработанных денег к деньгам, затраченным на разработку ПО тоже уже прошло свой пик.
Да, тогда всё было ещё далеко не так плачевно, как сейчас, океан всё ещё был голубым, а не багровым и работа программиста ещё была творческой, а не рабским трудом на скрам-галере, но это был уже не золотой век, скорее серебряный.
Почему же программисту всё же надо знать, или хотя бы быть знакомым с алгоритмами и структурами данных?
Поясню при помощи аналогии. В 19-м веке медицина уже серьёзно развивалась, хирурги делали уже довольно сложные операции, прекрасно зная строение человеческого тела. Но всё равно эпидемии внутри больниц уносили огромное количество жизней. Например, если в родильном отделении у кого-то из женщин начиналась родильная горячка, то эпидемия в среднем уносила жизни 60% женщин в этом отделении. И вот один венгерский врач сделал открытие: если тупо мыть руки и стерилизовать инструменты перед тем, как покопаться у очередной беременной в интересном месте, то процент смертей резко снизился с 60% до 1%.
К чему я это? А к тому, что вам могут дать такую задачу, которую за 5 минут можно эффективнейшим образом решить с помощью какого-то известного алгоритма. Но... Вы алгоритмы не изучали, и поэтому даже не подозреваете, что такой метод существует. И гуглить не будете, потому что не знаете, что это поможет, не знаете, как сформулировать запрос. В итоге вы весь рабочий день изобретаете свой велосипед, который, скорей всего, будет далёк от эффективности известного алгоритма. И да, ваш велосипед точно так же может быть в 60 раз хуже, как и эта ситуация с роженицами.
Поэтому, совет: структуры данных изучите основательно, потому что они очень часто будут вам встречаться, а с алгоритмами хотя бы ознакомьтесь, чтобы в нужный момент ваш мозг подсказал вам, что в этой конкретной задаче можно использовать вот этот конкретный алгоритм, реализацию которого и загуглить быстренько...
Прикольная статейка, заставляет задуматься над интересными мыслЯми, и при этом написана довольно интересно. Автор статьи может вполне ходить на лекции в школы или вузы с данной статьёй и уверен дети будут слушать, для школьников некоторые места могут быть сложными для осмысления, но их не сложно переработать в более простые.
А я сам пошёл думать как использовать полученную информацию и переосмысливать всё содеянное раньше)
Алгоритмы, безусловно, как и любые знания нужны и не только программистам. Сказать мягче, знание, что есть алгоритм или похожий алгоритм, уж точно не помешает. А сам алгоритм можно всегда найти, как здесь писали, либо в книге, либо на просторах инета.
Автор же все свои "наивные" с его точки зрения алгоритмы реализовывал с помощью самых передовых алгоритмов, например, сортировки, зашитых в компиляторах. Это как пользование сотовым телефоном, нажал наивно пальцем по монитору или кнопке и готово, можно вести диалог. Никаких наук знать не надо, тем более зачем изучать.
И, да, ему не довелось применить какой-либо алгоритм для убыстрения своих задач. Следует только посетовать, что не попалась ему действительно сложная задача, в которой нужно не изобретать "наивный" алгоритм, а применить существующий из огромного набора.
Навскидку, нахождение НОД (наибольший общий делитель) двух чисел можно решать "наивным" алгоритмом, разложив на множители каждое число и выбрав одинаковые. А можно применить алгоритм Евклида. Для небольших чисел разница во скорости - мизерная, а для больших - существенная. Ну и от железа многое зависит, для современных компьютеров разница даже для достаточно больших чисел будет небольшая. Вот и возникает иллюзия - алгоритмы не нужны!
когда я вижу взрослого дядю, который не может в это «вдуплить».
Обучал программированию и школьников, и взрослых. Нередко встречаются люди с, я бы назвал (да простят меня профессионалы), "алгоритмическим кретинизмом", по аналогии с географическим. Линейный алгоритм даже с условным переходом объяснить, еще куда ни шло, а вот цикл... не "вдупляют" хоть тресни. Не страшно! Можно пойти в юристы, или на худой конец в HR-ы :).
Я думаю, вопрос нужно или не нужно знать алгоритмы и структуры данных, как и ответ почти на все любые другие вопросы, лежит где-то по середине. Все это нужно знать, но в меру. Мера зависит от вашей работы. В науке все это нужно знать, в клепании вебсайтов все это не нужно. Тут дело же в том, умеет ли разработчик думать в правильном русле, когда надо.
К примеру две ситуации:
1) Разработчики которые не хотят изучать алгоритмы, говорят, а вот когда надо тогда разберемся. На самом деле, разобраться с проблемой требующей знания алгоритмов или там структур данных -- не тривиальная задача. Вы может и разберетесь, но на уровне "черного ящика". Возможно, этого будет и достаточно, а возможно и нет, и тогда без мат. базы вы пойдете спрашивать как раз тех, кто сечет. А может быть еще хуже. Вы даже не поймете, где проблема.
2) Разработчики которые секут в алгоритмах, но имею мало опыта в промышленном программировании. Вот они могут никогда не встретить задач, требуюищх их квалификации при работе, но отсутствие опыта - это прямолинейный процесс. Человек, который изучал алгоритмы и наработал такую вот мат. часть, скорее всего, спокойно наберет такой же опыт в промышленном программирвоании, которого ему не хватает. А вот, человек, который имеет опыт в промышленном программировании, далеко не факт, что сможет в алгоритмы и структуры данных.
То есть, один, как бы "доказал" что умеет думать, а второй доказал,что имеет опыт. И вот иметь такой ахеренный опыт, который итервьюера приведет в восторг, ну это надо еще умудриться получить в жизни.
Если программисту достаточно уметь в обходимасства и т.д. то это не программист, это кодер. По сути, обезьянка для набивания кода.
Нормальный программист как раз сам составляет механику процесса. Есть простые задачи, где механизм очевиден и однозначно, а есть множество других, где надо бы пора кинуть мозгами над оптимальным решением, да и над решением в принципе.
Автору попадались в основном задачки первого типа и он допустим ошибку выжившего.
Человек знающий алгоритмы может придумать более интересное решение, чем располагающий исключительно наивными методами.
Банальной иллюстрацией подобного может быть способ обмена значениями двух переменных. Наивный использует ещё одну переменную. Знающий алгоритмы пойдёт через сумму.
Банальной иллюстрацией подобного может быть способ обмена значениями двух переменных. Наивный использует ещё одну переменную. Знающий алгоритмы пойдёт через сумму.
...а знающий свою команду использует ещё одну переменную, чтобы это место читалось однозначно, а не как непонятно зачем добавленная хитрость.
Знающий алгоритмы пойдёт через сумму.
...а знающий про арифметическое переполнение INT-ов и двоичную логику пойдёт через XOR.
Так всё-таки нужны программисту алгоритмы или нет?