Закон вирта программы становятся медленнее куда шустрее чем компьютеры становятся быстрее
Как и любая другая сфера деятельности, мир разработки не лишён интересных и известных правил, принципов и законов. Программисты, разработчики, менеджеры и архитекторы часто упоминают их в разговорах. И как правило, мы склонны делать вид, что понимаем нашего собеседника, в то время как представления не имеем о каком-то Бруксе, Муре или Вирте.
Эти законы состоят из правил, принципов или известных слов великих и вдохновляющих людей мира разработки. В то же время все они интересные и забавные.
В этой статье вы познакомитесь с одними их самых известных законов в мире разработки.
Закон Мёрфи
Наверное, один из самых известных законов, по большей части из-за того, что он применим не только к разработке.
Всё, что может пойти не так, пойдёт не так.
Первый вывод: если программа работает, возможно, не вы её написали.
Второй вывод: язык ругательств — единственный, которым все программисты одинаково хорошо владеют.
18–20 ноября, Онлайн, Беcплатно
Итог: компьютер сделает не то, что вы хотите, а то, что напишете.
Оборонительное программирование, управление версиями, сценарий судного дня (на случай этих проклятых зомби-атак), TDD, MDD и т. д. являются хорошими практиками для защиты от этого закона.
Закон Брукса
Большинство разработчиков рано или поздно — осознанно или не очень — сталкиваются с законом Брукса, который гласит:
Добавление рабочей силы на последних стадиях разработки продукта замедлит его релиз.
Если сроки близятся к концу, а проект не готов, простое увеличение количества программистов скорее всего не обернётся ничем хорошим. Анализ уровня эффективности программирования, методики разработки, архитектуры и т. д. с большей вероятностью принесут пользу. Или нет, что означает, что где-то замешан закон Хофштадтера.
Закон Хофштадтера
Этот закон был сформулирован и назван в честь Дугласа Хофштадтера. Он гласит:
Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.
Речь идёт о точной оценке времени, необходимого для выполнения достаточно сложных задач. Рекурсивная природа закона отражает всю трудность оценки задач, несмотря на усилия и понимание сложности задачи.
Поэтому всегда нужно иметь запас времени, прежде чем давать какую-либо оценку.
Закон Конвея
Любой программный продукт отражает организационную структуру, создавшую его.
Или ещё более ясно:
Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникаций в этой организации.
Закон основан на том, что для того, чтобы отдельно взятый модуль ПО работал, несколько авторов должны часто общаться друг с другом. Поэтому структура ПО будет отражать социальные границы организации, которая его создала.
Закон Постела или Принцип надёжности
Будьте консервативны в том, что отправляете, и либеральны в том, что принимаете.
Изначально Джон Постел сформулировал это как принцип, обеспечивающий надёжность реализаций TCP. Также этот принцип воплощён в HTML, что многие называют причиной его успеха или неудачи, смотря кого спросить.
Принцип Парето или Правило 80/20
Для многих явлений 80 % последствий вытекают из 20 % причин.
Этот принцип стоит за печальной истиной — 80 % багов вытекают из 20 % кода.
Иными словами, 20 % сотрудников выполняют 80 % работы в компании. Проблема в том, что не всегда понятно, какие именно 20 %.
Принцип Питера
Довольно удручающий закон, особенно если вы испытали его на собственном опыте.
В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности.
Принцип Керкгоффса
Криптографическая система должна быть безопасна, даже если о ней известно всё, кроме небольшого фрагмента информации — ключа.
Это главный принцип, лежащий в основе криптографии с публичным ключом.
Закон Линуса
Названный в честь Линуса Торвальдса, создателя Linux, этот закон гласит:
При достаточном количестве наблюдателей ошибки выплывают на поверхность.
Этот закон был описан с помощью известного эссе «Собор и Базар», в котором объясняется разница между двумя свободными моделями разработки ПО:
- Модель Собора, в которой исходный код доступен при каждом релизе, но код, написанный между релизами, доступен только ограниченному кругу разработчиков.
- Модель Базара, в которой код выкладывается в Интернет и доступен каждому.
Вывод: чем доступнее исходный код для публичного тестирования, проверки и экспериментов, тем быстрее будут обнаружены всевозможные баги.
Закон Мура
Мощность компьютеров на единицу стоимости удваивается каждые 24 месяца.
Более популярная версия гласит:
Количество транзисторов интегральной схемы удваивается примерно каждые 18 месяцев.
Производительность компьютеров удваивается каждые два года.
Закон Вирта
Программы становятся медленнее куда шустрее, чем компьютеры становятся быстрее.
Как тебе такое, закон Мура?
Правило 90-90
Первые 90 % кода отнимают 90 % времени. Остальные 10 % кода отнимают оставшиеся 90 % времени.
И в итоге получаем 180 %, что подчёркивает сложность оценки времени на разработку.
Принцип оптимизации Кнута
Преждевременная оптимизация — корень всех зол.
Сначала нужно писать код, затем искать узкие места, а затем исправлять их!
Профессор Никлаус Вирт был прав. Создатель языка Pascal, соавтор технологии структурного программирования, лауреат премии Тьюринга в 1995 году заметил:
«Замедление программ происходит куда быстрее, чем ускорение компьютеров»
С тех пор это высказывание считается законом Вирта. Он фактически нивелирует закон Мура, согласно которому количество транзисторов в процессорах удваивается примерно с 1965 года. Вот что пишет Вирт в статье «Призыв к стройному софту»:
«Около 25 лет назад интерактивный текстовый редактор умещался всего в 8000 байт, а компилятор в 32 килобайта, тогда как их современные потомки требуют мегабайтов. Стало ли всё это раздутое программное обеспечение быстрее? Нет, совсем наоборот. Если бы не в тысячу раз более быстрое железо, то современное программное обеспечение было бы совершенно непригодным».
Проблема разработки современного программного обеспечения стоит очень остро. Вирт указывает на один важный аспект: время. Он предполагает, что главной причиной появления раздутого программного обеспечения является нехватка времени на разработку.
Сегодня появилась ещё одна причина ожирения софта — абстракция. И это гораздо более серьёзная проблема. Разработчики никогда не писали программы с нуля, но раньше это не вызывало осложнений.
Дейкстра и Вирт пытались улучшить качество кода и разработали концепцию структурированного программирования. Они хотели вывести программирование из кризиса, и в течение некоторого времени программирование рассматривалось как настоящее ремесло для настоящих профессионалов. Программисты заботились о качестве программ, ценили ясность и эффективность кода.
Те времена прошли.
С появлением языков более высокого уровня, таких как Java, Ruby, PHP и Javascript, к 1995 году, когда Вирт написал свою статью, программирование стало более абстрактным. Новые языки значительно облегчали программирование и многое брали на себя. Они были объектно-ориентированными и поставлялись в комплекте с с такими вещами, как IDE и сборка мусора.
Программистам стало легче жить, но за всё приходится платить. Чем легче жить, тем меньше думать. Примерно в середине 90-х программисты перестали думать о качестве своих программ, пишет разработчик Робин Мартин в своей статье «Никлаус Вирт был прав, и в этом проблема». В то же время началось широкое использование библиотек, функциональность которых всегда намного больше, чем необходимо для конкретной программы.
Поскольку библиотека не создана для одного конкретного проекта, она, вероятно, имеет немного больше функциональных возможностей, чем действительно нужно. Никаких проблем, скажете вы. Однако всё накапливается довольно быстро. Даже люди, которые любят библиотеки, не хотят изобретать велосипед. Это приводит к тому, что называется адом зависимостей. Никола Дуза написал пост об этой проблеме в Javascript.
Проблема не кажется такой уж большой, но в реальности она серьёзнее, чем вы можете подумать. Например, Никола Дуза написал простое приложение для ведения списка дел. Оно работает в вашем браузере с HTML и Javascript. Как вы думаете, сколько зависимостей оно использовало? 13 000. Тринадцать. Тысяч. Пруф.
Цифры безумны, но проблема будет только расти. По мере создания новых библиотек число зависимостей в каждом проекте также будет увеличиваться.
Это означает, что проблема, о которой предупреждал Никлаус Вирт в 1995 году, со временем только усугубится.
Робин Мартин предполагает, что хороший способ приступить к решению проблемы — разделить библиотеки. Вместо того, чтобы создавать одну большую библиотеку, которая делает всё возможное, просто создать много библиотек.
Таким образом, программист должен только выбрать библиотеки, которые ему действительно нужны, игнорируя функциональные возможности, которые он не собирается использовать. Мало того, что он сам устанавливает меньше зависимостей, но и в используемых библиотеках тоже будет меньше своих зависимостей.
К сожалению, миниатюризация транзисторов не может продолжаться вечно и имеет свои физические пределы. Возможно, рано или поздно закон Мура прекратит действовать. Некоторые говорят, что это уже произошло. В последние десять лет тактовая частота и мощность отдельных ядер процессоров уже перестала расти, как раньше.
Хотя хоронить его рано. Есть ряд новых технологий, которые обещают прийти на смену кремниевой микроэлектронике. Например, Intel, Samsung и другие компании экспериментируют с транзисторами на углеродных наноструктурах (нанонитях), а также с фотонными чипами.
Эволюция транзисторов. Иллюстрация: Samsung
Но некоторые исследователи подходят с другой стороны. Они предлагают новые системные подходы к программированию, чтобы значительно повысить эффективность будущего программного обеспечения. Таким образом, можно «перезапустить» закон Мура программными методами, как бы фантастически это не звучало в свете наблюдений Никлауса Вирта об ожирении программ. Но вдруг у нас получится обернуть эту тенденцию вспять?
Недавно в журнале Science была опубликована интересная статья учёных из лаборатории компьютерных наук и искусственного интеллекта Массачусетского технологического института (CSAIL MIT). Они выделяют три приоритетные области для дальнейшего ускорения вычислений:
- лучшее программное обеспечение;
- новые алгоритмы;
- более оптимизированное железо.
«Но в настоящее время для достижения дальнейших успехов в таких областях, как машинное обучение, робототехника и виртуальная реальность, потребуются огромные вычислительные мощности, которые миниатюризация уже не может обеспечить, — говорит Лейзерсон. — Если мы хотим использовать весь потенциал этих технологий, мы должны изменить наш подход к вычислениям».
В части программного обеспечения предлагается пересмотреть стратегию использования библиотек с излишней функциональностью, потому что это является источником неэффективности. Авторы рекомендуют сконцентрироваться на главной задаче — повышении скорости выполнения программ, а не на скорости написания кода.
Во многих случаях производительность действительно можно повысить в тысячи раз, и это не преувеличение. В качестве примера исследователи приводят перемножение двух матриц 4096×4096. Они начали с реализации на Python как одного из самых популярных языков высокого уровня. Например, вот реализация в четыре строки на Python 2:
В коде три вложенных цикла, а алгоритм решения основан на школьной программе по алгебре.
Но оказывается, что этот наивный подход слишком неэффективно использует вычислительную мощность. На современном компьютере он будет выполняться около семи часов, как показано в таблице ниже.
| Версия | Реализация | Время выполнения (с) | GFLOPS | Абсолютное ускорение | Относительное ускорение | Процент от пиковой производительности |
|---|---|---|---|---|---|---|
| 1 | Python | 25552,48 | 0,005 | 1 | — | 0,00 |
| 2 | Java | 2372,68 | 0,058 | 11 | 10,8 | 0,01 |
| 3 | C | 542,67 | 0,253 | 47 | 4,4 | 0,03 |
| 4 | Параллельные циклы | 69,80 | 1,97 | 366 | 7,8 | 0,24 |
| 5 | Парадигма «Разделяй и властвуй» | 3,80 | 36,18 | 6727 | 18,4 | 4,33 |
| 6 | + векторизация | 1,10 | 124,91 | 23224 | 3,5 | 14,96 |
| 7 | + интристики AVX | 0,41 | 337,81 | 52806 | 2,7 | 40,45 |
Переход на более эффективный язык программирования уже кардинально повышает скорость выполнения кода. Например, программа на Java будет выполняться в 10,8 раз быстрее, а программа на С — ещё в 4,4 раза быстрее, чем на Java. Таким образом, переход с Python на C означает повышение скорости выполнения программы в 47 раз.
И это только начало оптимизации. Если писать код с учётом особенностей аппаратного обеспечения, на котором он будет выполняться, то можно повысить скорость ещё в 1300 раз. В данном эксперименте код сначала запустили параллельно на всех 18 ядрах CPU (версия 4), затем использовали иерархию кэшей процессора (версия 5), добавили векторизацию (версия 6) и применили специфические инструкции Advanced Vector Extensions (AVX) в версии 7. Последняя оптимизированная версия кода выполняется уже не 7 часов, а всего 0,41 секунды, то есть более чем в 60 000 раз быстрее оригинального кода на Python.
Более того, на графической карте AMD FirePro S9150 тот же код выполняется всего за 70 мс, то есть в 5,4 раза быстрее, чем самая оптимизированная версия 7 на процессоре общего назначения, и в 360 000 раз быстрее, чем версия 1.
Что касается алгоритмов, исследователи предлагают трёхсторонний подход, который включает в себя изучение новых проблемных областей, масштабирование алгоритмов и их адаптацию к лучшему использованию преимуществ современного оборудования.
Например, алгоритм Штрассена для перемножения матриц ещё на 10% ускоряет самую быструю версию кода номер 7. Для других проблем новые алгоритмы обеспечивают ещё большую прибавку в производительности. Например, на следующей диаграмме показан прогресс в эффективности алгоритмов для решения задачи о максимальном потоке, достигнутый в 1975−2015 годы. Каждый новый алгоритм увеличивал скорость вычислений буквально на несколько порядков, а в последующие годы ещё оптимизировался.
Эффективность алгоритмов для решения задачи о максимальном потоке на графе с n=10 12 вершин и m=n 11 рёбер
Таким образом, улучшение алгоритмов тоже вносит свой вклад в то, чтобы «эмулировать» закон Мура программным путём.
Наконец, с точки зрения аппаратной архитектуры, исследователи выступают за оптимизацию аппаратного обеспечения таким образом, чтобы проблемы можно было решить с меньшим количеством транзисторов. Оптимизация включает в себя использование более простых процессоров и создание аппаратного обеспечения, адаптированного к конкретным приложениям, как графический процессор адаптирован для компьютерной графики.
«Оборудование, настроенное для конкретных областей, может быть гораздо более эффективным и использовать гораздо меньше транзисторов, позволяя приложениям работать в десятки и сотни раз быстрее, — говорит Тао Шардль, соавтор научной работы. — В более общем плане оптимизация аппаратного обеспечения будет ещё больше стимулировать параллельное программирование, создавая на микросхеме дополнительные области для параллельного использования».
Тренд на параллелизацию виден уже сейчас. Как показано на диаграмме, в последние годы производительность CPU растёт исключительно благодаря увеличению количества ядер.
Производительность по тесту SPECint отдельных ядер, а также одно- и многоядерных процессоров с 1985 по 2015 годы. В качестве базовой единицы взят микропроцессор 80386 DX образца 1985 года
Для операторов дата-центров даже минимальное улучшение производительности ПО может означать большую финансовую выгоду. Неудивительно, что сейчас инициативы по разработке собственных специализированных CPU ведут такие компании как Google и Amazon. Первая выпустила тензорные (нейронные) процессоры Google TPU, а в дата-центрах Amazon работают чипы AWS Graviton.
За лидерами отрасли со временем могут последовать владельцы других ЦОД, чтобы не проиграть конкурентам в эффективности.
Исследователи пишут, что раньше стремительный рост производительности процессоров общего назначения ограничивал возможности для развития специализированных процессоров. Сейчас такого ограничения нет.
«Рост производительности потребует новых инструментов, языков программирования и аппаратного обеспечения, чтобы обеспечить более эффективное проектирование с прицелом на скорость, — говорит профессор Чарльз Лейзерсон, соавтор научной работы. — Это также означает, что программистам следует лучше понимать, как сочетается софт, алгоритмы и аппаратное обеспечение, а не рассматривать их по отдельности».
С другой стороны, инженеры экспериментируют с технологиями, которые могут обеспечить дальнейший рост производительности CPU. Это квантовые вычисления, 3D-компоновка, микросхемы со сверхпроводимостью, нейроморфные вычисления, использование графена вместо кремния и др. Но пока эти технологии на стадии экспериментов.
Если производительность CPU в самом деле перестанет расти, то мы окажемся в совершенно другой реальности. Возможно, нам в действительно придётся пересмотреть наши приоритеты в программировании, а специалисты по ассемблеру станут на вес золота.
На правах рекламы
Нужен мощный сервер? Наша компания предлагает эпичные серверы - виртуальные серверы с CPU AMD EPYC, частота ядра CPU до 3.4 GHz. Максимальная конфигурация впечатлит любого — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe.
Это полушутливое высказывание, популяризированное Никлаусом Виртом в 1995 году стало настоящим бичём современности примерно в 2006м году.
Не смотря на то, что скорость работы компьютеров становится выше в соответствии с законом Мура, закон Вирта утверждает, что увеличение производительности аппаратной части ещё не означает ускорения работы как таковой.
"Есть мнение, что прогресс в аппаратной части излечит все недостатки программ, однако внимательный наблюдатель может заметить, что программы перерастают компьютеры в размерах и медлительности."
Закон Вирта также иногда называется Законом Пейджа, в честь Ларри Пейджа, основателя Google, который упомянул его в своём выступлении, о чём упомянул Сергей Брин на конференции Google I/O в 2009 году. Внезапно, да?
Закон Гейтса — это вариант закона Вирта, названный в честь основателя Microsoft Билла Гейтса. Это шутливое наблюдение, утверждающее, что скорость программного обеспечения уменьшается на половину каждые полтора года, что сводит на нет все преимущества закона Мура. Это может происходить по нескольким причинам: добавление избыточных ненужных функций, плохой код, нежелание программистов дорабатывать программы и плохой менеджмент или частая смена команды.
Закон Паркинсона: программное обеспечение увеличивается в размерах до тех пор, пока не заполнит всю доступную на данный момент память.
Пользователи, как правило, относятся к раздутому программному обеспечению отрицательно.
Но что самое характерное, хотят и просят получать обновления как можно скорее и быстрее.
По мнению Джоэла Спольски, они это делают зря, по следующим причинам:
С прогрессом микроэлектроники аппаратное обеспечение, на котором новая версия способна работать, часто оказывается даже дешевле. Например, Excel 1.0 потреблял 36 долл. дискового пространства по ценам 1993 года, Excel 2000 — 1,03 долл. по ценам 2000 года.
Оптимизация экономически оправдана только в ключевых точках программы. Вовремя вышедшая программа важнее хорошо оптимизированной (в крайнем случае можно выпустить патч).
Хотя типичный пользователь использует 20 % функций, у разных пользователей эти 20 % разные. Поэтому, если написать облегчённую программу, в которой реализованы только 20 % функций, есть риск сильно сузить круг её пользователей.
Подгонка старых программ под новые машины обычно означает такие изменения, при которых новые машины работают как старые. Алан Перлис
Acrobat Reader
Internet Explorer
Microsoft Outlook.
Я б еще добавил туда Nero, Winamp, MSOffice, превратившиеся из вполне нормальных продуктов в монстров с практически одним и тем же функционалом, либо обрастая ненужными возможностями.
Никто не знает, зачем резалке компакт-дисков нужен встроенный фотошоп и аудиоредактор, когда для этого есть другие специализированные программы, но большинство с удовольствием пользуются.
Если уж так захотелось, то лучше разделить эти возможности на отдельные составляющие продукты, например, как это делает Sysinternals и Яндекс.
Но если у Sysinternals средства и утилиты для управления, диагностики, устранения неполадок и мониторинга весят две-три сотни килобайт и честно выполняют то, для чего они задуманы, то Яндекс это какой-то феерический пиздец:
Во времена шествия наладонных компьютеров - КПК, были Яндекс-карты, дистрибутив которых меньше 2х мегабайт! И ещё меньше пяти лет назад многие пользовались этой замечательной штукой.
Эти карты умели в навигатор, в карты, в маршруты, в камеры, в пробки, в трекинг, в скидывание треков в личный яндекс-кабинет, где можно потом с компьютера посмотреть, в разговорчики и многое другое.
Сейчас же, все эти функции разбиты на отдельные приложения, весят ни меньше 20мб каждая и чтобы иметь функциональность, приходится ставить всё одним скопом.
Смартфон начинает еле ворочаться и ругаться на нехватку памяти.
Ещё больший пиздец, это когда у каждой из этой практически одинаковой программы разный кэш карт!
Огромная компания не в состоянии следить за тем, что выпускает.
Яндекс.Электрички, версия: 2.31 от 27 октября 2014 г. - ( 2,08 МБ )
Оно работало и нормально работало.
Следующая версия у них вышла такая:
Яндекс.Электрички, версия: 3.05 от 16 мая 2016 г. - ( 17,19 МБ )
Что нового
Мы переделали дизайн и добавили новые функции:
Виджет показывает расписание прямо на домашнем экране.
Если есть временные изменения или отмены, приложение выводит заметное предупреждение в красной рамочке.
Нахрена, а главное как можно ТАК раздуть программу этими никому ненужными "новшествами"?
Сразу после установки весит в системе 55 метров. Ну вы поняли.
Промолчу про Windows, ламероориентированные Linux- дистрибутивы. Большой привет как минимум Ubuntu с Unity, новым кедам и гномам. Там совсем задница.
И если многих монстров со своими свистелками и перделками ещё можно заменить на что-то адекватное, то у некоторых пользователей просто не остается выбора. Здравствуй Apple.
MenuetOS и русский форк KolibriOS - результаты титанической работы на ассемблере.
Да, это пока ещё некая игрушка, влезающая на дискету и можно только посмеяться, разворачивая свой последний 3DsMax на виртуальной машине, но возможностей у неё - можно и обзавидоваться в узком кругу людей.
Раньше я на нетбуке спокойно сёрфил инет и видео в 720 без тормозов шло, сейчас открыл его, попробовал поюзать - треш-угар-содомия!
Видео в 320 даже хуже, чем слайд-шоу.
Теперь фильмы смотреть только с карточки оффлайн.
Многие программы перестали поддерживать одну из лучших операционных систем Windows XP. А ведь многие до сих пор из принципа сидят на ней.
Первый секрет кроется в самом инсталляторе программы.
Если свежую версию извлечь тем же UniExtract-ом, то программа почему то запускается либо сразу и не выёживается, работая, как надо. Либо там находится ещё один установщик, который теперь позволяет установить эту программу.
У программистов какая-то больная тема, потому что ставят скорость разработки в ущерб производительности. Время - деньги. А жмут их маркетолухи и эффективные менеджеры, которым продукт нужен ещё вчера.
У программистов уже не остается времени делать комментарии, после смены разработчика проще накатить костыль, нарастить новый карман проще, чем разбираться в раннее написанном коде и так по нарастающей.
При этом большинство программистов признают, что если не гнаться за деньгами, как поп за дешевизной, то делать будут с удовольствием и качественно.
И это заметно, редкий некоммерческий продукт будет похож на говно.
Если его, конечно, не школьник набросал в окошках с помощью фреймворков и скачанных скриптов, не забыв добавить всевозможной рекламы, чтобы хватило раз в неделю сходить в макдак.
Таким образом мы получаем фонарик для андроида, весом в 15 мегабайт, запрашивающий кучу разрешений. И не важно, что на вашем смартфоне фонарика отродясь не было - будем светить дисплеем на полную яркость и показывать рекламу в пол-экрана, ломясь в интернет через все щели, а после выключения фонарика, вернуть яркость в прежнее состояние мы, конечно же, забудем.
Недавно было повальное использование такого продукта, как Pokemon Go.
Это пример такого монструозного, глючного софтверного решения вывалили на рынок так рано, что любому адекватному программисту было бы чертовски стыдно такое показывать людям.
Снаружи эта игра выглядела расчленёнкой с кишками наружу и попытками скрепить всё это малярным скотчем и каждые два дня выдавать пользователям еще по рулону, дабы всё это не успело развалиться и хоть как-то дышало.
Ёжики плакали, но продолжали жевать кактус.
Плохие программисты очень хотят денег, поэтому они открывают курсы обучения программированию. В следствии чего, появляется категория программистов без понимания каких-то базовых вещей.
Особенно улыбают курсы, например, для веб-разработчиков, где учат устанавливать и настраивать Wordpress. Да чего уж, на ютубе таких видео-уроков превеликое множество.
Интернет превратился в помойку бесполезной информации, где найти крупицу смысла очень тяжело.
Хочешь освоить какую-то новую штуку, например пагинацию. Заходишь в ютуб, ищешь ролики и думаешь, вот сейчас какой-нибудь умный парень на примере все объяснит, по какому принципу пишется, и почему так, а не иначе.
Но находишь видео с гундосым школьником, который за 10 минут объясняет как зайти в настройки очередной CMS и скачать плагин.
Сейчас и программистом-то быть необязательно, чтобы наклепать какую-нибудь быдло-софтину. А вирусы? Раньше это были шедевры, вспомнить хотя бы CIH, а сейчас что? Черви написанные на макросах? Блокировщики-шифровщики на delphi. Сейчас даже PHP, javascript называют языками программирования, а тех кто может написать на них hello world - программистами.
Господи, да сейчас и вирусов то уже никто не пишет, всем лень!
А раньше вирусописательство было целой олимпиадой мирового масштаба и мерянием пиписками с хакерами, крякерами, кодерами и производителями антивирусов!
Код был безумно красив, весил мало, а искусство прятать вирус так, чтобы его никто не смог заподозрить лишь повышало ЧСВ.
Не, ну наверняка современный интернет-червь выглядит так:
ууу: троянский слон
Создатели кейгенов вкладывали в свои кряки столько души, сколько мало какой современный производитель монстрограммы вкладывает в развитие своего продукта.
Для каждого кейгена даже музыку отдельно сочиняли.
Когда производители антивирусов приуныли от скукоты, под шум авторских прав и лицензий они срочно стали добавлять в свои базы не только безвредные кейгены, но и всё, что может поспособствовать созданию вирусов и кейгенов - сплиттеры всякие и архиваторы.
Вставляешь флешку в комп с антивирусом, лезешь в папку с программой, чтобы установить что-нибудь условно-бесплатное. В папке установщик программы и крякер к ней.
Устанавливаешь программу, херась - а крякера и след простыл.
Долго чешешь репу и в итоге находишь этот крякер в карантинной зоне антивируса.
Эта падла даже не удосужилась уведомить, что обнаружила не очень полезное приложение и молча стёрла его с флешки.
Какого хрена эта пакость распоряжается чужими файлами без спроса?
Вообще, сейчас не человек управляет компьютером, а компьютер человеком.
Закон Вирта — это полушутливое высказывание, популяризированное Никлаусом Виртом в 1995 году . Звучит оно так:
« Программы становятся медленнее более стремительно, чем компьютеры становятся быстрее».
Вирт указал, что выражение впервые было сформировано Мартином Райзером , который в предисловии к его книге об операционной системе Оберон написал: «Есть мнение, что прогресс в аппаратной части излечит все недостатки программ, однако внимательный наблюдатель может заметить, что программы перерастают компьютеры в размерах и медлительности» ( The hope is that the progress in hardware will cure all software ills . However, a critical observer may observe that software manages to outgrow hardware in size and sluggishness. ).
Скорость работы компьютеров становится выше в соответствии с законом Мура . Закон Вирта утверждает, что увеличение производительности аппаратной части ещё не означает ускорения работы как таковой.
Закон также иногда называется Законом Пейджа, в честь Ларри Пейджа , основателя Google , который упомянул его в своём выступлении. Впервые о нём упомянул Сергей Брин на конференции Google I/O в 2009 году .
Закон Гейтса
Программы становятся в два раза медленнее каждые полтора года.
Закон Гейтса — это вариант закона Вирта, названный в честь основателя Microsoft Билла Гейтса . Это шутливое наблюдение, утверждающее, что скорость программного обеспечения уменьшается на половину каждые полтора года, что сводит на нет все преимущества закона Мура. Это может происходить по нескольким причинам: добавление избыточных ненужных функций, плохой код, нежелание программистов дорабатывать программы и плохой менеджмент или частая смена команды.
Читайте также: