Спасибо очень хорошая статья. При прочтении она кажется очевидной. При этом 99% тех кто начинает делать свой продукт и потом его закрывает, недостаточно глубоко продумывают эти фундаментальные моменты.
Ещё хотел сказать что для того что бы в достаточной мере оценить ценность статьи и её обобщающую значимость — нужно самому это пройти, создать продукт долго думать как привлеч пользоватей или продать, самому дойти до написанного в том или ином виде.
MS как положено по традиции хоронит очередной крутой проект который купила.)
Что может и хорошо т.к. помогает другим компаниям, что в конечном счете увеличивает конкуренцию.
Кто тут ещё совок — вы видимо рассматриваете удобство как переусложнение. На мой взгляд это конкретно решает задачу удобства — это важно.
Если использовать как аналогию тему машин, переусложнением будет установка второго двигателя — если один сломается будет работать второй, или можно включить второй для большей тяги. Наверное где то такое решение имеет смысл. В большинстве случаем будет переусложнением и окажется намного дороже в производстве и эксплуатации чем решение с одним двигателем.
Вообще тема физического производства хороша для примера, там стараются не переусложнять, потому что каждый новый элемент это удорожание сборки и дополнительные материалы.
Проектирование, чем по сути является разработка ПО, не имеет таких проблем с воспроизводством — копирование почти бесплатно, можно лепить что угодно в проект, пока он не перестанет быть поддерживаемым.)
Вы путайте простоту и примитивизм.)
p.s.
Технически простота это комбинаторная сложность. Чем меньше комбинаций тем проще система.
А вот примитивная система обладает худшими свойствами, хотя может решать ту же задачу. Напримерем средневековая система подъемных блоков, может решить ту же задачу что и современный кран. Но обладает худшими характеристиками, кол-вом трудозатрат, поднимаемым весом, временем жизни и т.д.
Таким образом если вы сравниваете схожие решения, с одинаковыми рабочими харрактеристикам две системы побьемных блоков например, то если одна система для той же подьемной силы использует меньше блоков и веревок чем вторая — первая более простая, и точки зрения простоты она лучше.
Если у вас два программных кода, решающие бизнес задачу с одинаковыми характеристиками — лучше тот вариант у которого сложность(кол-во элементов) меньше.)
Ещё есть такое понятие как легкость/трудность восприятия, но это очень субъективно. Простота это объективный критерий, его можно даже подсчитать, по кол-ву элементов в коде.
При достижении любого из перечисленного вами ИЛИ, а так любых комбинаций — можно стараться найти наиболее простое решение которое удовлетворяет конечной цели. Главное поставить себе такую цель.
простым для программиста какого уровня подготовки?
Чем менее подготовленному будет понятно ваше решение тем лучше. Задача решена и решена простым понятным образом — очевидно лучше чем, решена так что это трудно понять.
Не понял последний пункт.
Я постоянно участвую в разработке множеством задача/сервисов/проектов — и приходится анализировать много чужого кода — меня жутно напрягает когда вижу как очередная тривиальная штука обернута во множество самописных прослоек или готовых элементов без которых можно обойтись, т.к. это трати мое время которое можно провести с пользой. На самом деле это тратит и время разработчика который изначально писал код — но ему кажется что так код становиться профессиольнее или обретает другие полезные черты, хотя по факту он просто обрастает элементами которые не нужны для решения задачи.
У вас есть прикладная задача — которую вы решаете в коде. Написанный вами код для решения этой задачи и должен быть максимально простым. Не предполагалось переписывать весь стэк. Обеспечить соединение по сети это уже не ваша задача в данном случае.
Что то вас не туда занесло.)
— Зачем ты мудришь?! Сделай, чтобы просто работало!
На мой взгляд пункт раскрыт не в ту сторону. Не отрицая написанного, просто далее о другом.
Сколько кода чужого не читаю, уже работал над множеством проектов, везде один и тот же подход. Разработчики начинают наворачивать абстракций или иных обобщений в языке потому что так обобщение/круче/продуманнее — каждый себе придумывает причину самостоятельно. По итогу получает переусложненный код который со временем становиться вообще мусором который непонятно зачем нужен но бояться трогать что бы не сломать или просто из-за не хватки времение.
А тем временем максимально простое решение — означает что новый разработчик легко его поймет, значит легко внесет изменения, меньше шанса допустить баг опять же потому что понимаешь как работает.
S = 1 / ('a' + (1 — 'a') / p). В законе доля паралельных операций (1- 'a') делиться на кол-во процессоров p которое ограничено — (1- 'a') / p. Если у вас 8 процесоров то ускорения от увеличения кол-ва параллельных операций вы не получите т.к. p будет постоянным а (1 — 'a') будет расти. Но с ростом кол-ва потоков будет расти 'a' — это управление тредами операционной системой, что автор и получил.
Вы уперлись в закон Амдала.)
Вообще когда вы параллелите операции ввода-вывода, http запрос например, то получаете ускорение за счет того что процессор переключает своей выпонение на полезную нагрузку, во время ожидания ответа от переферии. Когда вы выполняете алгоритм состоящий из последовательных операций на процессоре, то вы упираете в закон Амдала. Эти два вида операций имеют сильно разный прирост от параллелизма.
Отличная статья. Пролог действительно интересен. Как кто то уже выше писал — проблема в том что не все типы запросов можно выполнить за разумное время. Вероятно с ростом мощности желена и новыми алгоритмами мы получим большие возможности для декларативных языков в том числе и Prolog — ведь один уже смог взойти на пьедестал, это SQL.)
p.s.
Сам буквально недавно думал над возможностью применить систему работающую с Datalog, искал решения.
Исходя из этого пункта не понятно зачем нужно, т.к. есть много более популярных языков.
C# — мощный язык с кучей возможностей
Если вам скучно можете найти в языке ещё одно специальное решение для особого случая, что бы ваши коллеги/наследники, подольше разбиралить. А что вы хотели программирование — это не просто, знали куда шли.)
А вы много продали? Можете привести примеры удачных продуктов которые продали?)
Или пока вы только так думаете — что продать легко, не то что кода написать или генерировать идеи.
p.s.
Так вот раскрою вам секрет написание софта — если у вас не какой то крайне инновационный алгоритм, то это уже решенная задача, с огромным множеством примеров как сделать тут или иную функцию.
А продажи это то где вы не сможете открыть мануал и получить из него все ответы. Вам придется использовать свой личный опыт и интуицию. И никто вам никогда точно не сможет описать алгоритм продаж — потом что его нет. Во вторых если есть какой то более менее понятный подход по продажам того или иного вида продукта, с вами этим никто в мануале не поделиться потом что это ключевая коммерческая тайна.
Развитие функций продукта тоже на напрямую связано с продажами, потому что должны быть тем что нужно людям и что они готовы купить, а не то что вы считаете — интересным.)
Написать новый google намного проще чем его продать — т.е. найти клиентов которые готовы им пользоваться. Тому подтверждение, неудачные попытоки множества компаний сделать это — microsoft не смог и бесчисленное кол-во других компаний тоже.
Тут выбор простой. Или платный сервис или реклама, пора давно понять.)
Не стоит винить компании в желании максимизировать прибыль через сбор данных, у меня в первую очередь вопрос к пользователям которые не хотять ни платить ни делиться данными.
Типичная проблема роста и развития отрасли.
Хотя IT это и не стройка но пример будет думаю актуальным.
На стройке серьезных объектов работают разные по своим способностям люди, а разрыв между разнорабочим и главным инженером оценить сложно. Все это связано с разделением труда и тем фактом что для разных работ необходим разный уровень квалификации.
Точно такая же ситуация в IT, для разных задач и проектов нужна разная квалификация. Сегодня средства разработки позволяют писать код проще без наличия глубинных знаний.
Катится на дно к сожалению. Особенно мобильный браузер, уже несколько обновлений UI, с мягко говоря сомнительными изменениями интерфейса, при это баги фиксятся слабо, а актуальный функционал не добавляется.
Если выразиться емко — scala геморройный язык.
Собственно это мой практический опыт, хотя изначально у меня были большие ожидания. Но работа на проектах со Scala за год, все поставило на места. Процесс разработки перерастает в борьбу с типами.
Получается что каких то реальных плюсов язык не дает — кол-во ошибок не меньше, скорость разработки не увеличилась, зато сильно усложняет код за счет множества сложных связей между типами.
Думаю это основная причина почему его перестали использовать.
Спасибо очень хорошая статья. При прочтении она кажется очевидной. При этом 99% тех кто начинает делать свой продукт и потом его закрывает, недостаточно глубоко продумывают эти фундаментальные моменты.
Ещё хотел сказать что для того что бы в достаточной мере оценить ценность статьи и её обобщающую значимость — нужно самому это пройти, создать продукт долго думать как привлеч пользоватей или продать, самому дойти до написанного в том или ином виде.
MS как положено по традиции хоронит очередной крутой проект который купила.)
Что может и хорошо т.к. помогает другим компаниям, что в конечном счете увеличивает конкуренцию.
Кто тут ещё совок — вы видимо рассматриваете удобство как переусложнение. На мой взгляд это конкретно решает задачу удобства — это важно.
Если использовать как аналогию тему машин, переусложнением будет установка второго двигателя — если один сломается будет работать второй, или можно включить второй для большей тяги. Наверное где то такое решение имеет смысл. В большинстве случаем будет переусложнением и окажется намного дороже в производстве и эксплуатации чем решение с одним двигателем.
Вообще тема физического производства хороша для примера, там стараются не переусложнять, потому что каждый новый элемент это удорожание сборки и дополнительные материалы.
Проектирование, чем по сути является разработка ПО, не имеет таких проблем с воспроизводством — копирование почти бесплатно, можно лепить что угодно в проект, пока он не перестанет быть поддерживаемым.)
Вы путайте простоту и примитивизм.)
p.s.
Технически простота это комбинаторная сложность. Чем меньше комбинаций тем проще система.
А вот примитивная система обладает худшими свойствами, хотя может решать ту же задачу. Напримерем средневековая система подъемных блоков, может решить ту же задачу что и современный кран. Но обладает худшими характеристиками, кол-вом трудозатрат, поднимаемым весом, временем жизни и т.д.
Таким образом если вы сравниваете схожие решения, с одинаковыми рабочими харрактеристикам две системы побьемных блоков например, то если одна система для той же подьемной силы использует меньше блоков и веревок чем вторая — первая более простая, и точки зрения простоты она лучше.
Если у вас два программных кода, решающие бизнес задачу с одинаковыми характеристиками — лучше тот вариант у которого сложность(кол-во элементов) меньше.)
Ещё есть такое понятие как легкость/трудность восприятия, но это очень субъективно. Простота это объективный критерий, его можно даже подсчитать, по кол-ву элементов в коде.
При достижении любого из перечисленного вами ИЛИ, а так любых комбинаций — можно стараться найти наиболее простое решение которое удовлетворяет конечной цели. Главное поставить себе такую цель.
Чем менее подготовленному будет понятно ваше решение тем лучше. Задача решена и решена простым понятным образом — очевидно лучше чем, решена так что это трудно понять.
Не понял последний пункт.
Я постоянно участвую в разработке множеством задача/сервисов/проектов — и приходится анализировать много чужого кода — меня жутно напрягает когда вижу как очередная тривиальная штука обернута во множество самописных прослоек или готовых элементов без которых можно обойтись, т.к. это трати мое время которое можно провести с пользой. На самом деле это тратит и время разработчика который изначально писал код — но ему кажется что так код становиться профессиольнее или обретает другие полезные черты, хотя по факту он просто обрастает элементами которые не нужны для решения задачи.
У вас есть прикладная задача — которую вы решаете в коде. Написанный вами код для решения этой задачи и должен быть максимально простым. Не предполагалось переписывать весь стэк. Обеспечить соединение по сети это уже не ваша задача в данном случае.
Что то вас не туда занесло.)
На мой взгляд пункт раскрыт не в ту сторону. Не отрицая написанного, просто далее о другом.
Сколько кода чужого не читаю, уже работал над множеством проектов, везде один и тот же подход. Разработчики начинают наворачивать абстракций или иных обобщений в языке потому что так обобщение/круче/продуманнее — каждый себе придумывает причину самостоятельно. По итогу получает переусложненный код который со временем становиться вообще мусором который непонятно зачем нужен но бояться трогать что бы не сломать или просто из-за не хватки времение.
А тем временем максимально простое решение — означает что новый разработчик легко его поймет, значит легко внесет изменения, меньше шанса допустить баг опять же потому что понимаешь как работает.
S = 1 / ('a' + (1 — 'a') / p). В законе доля паралельных операций (1- 'a') делиться на кол-во процессоров p которое ограничено — (1- 'a') / p. Если у вас 8 процесоров то ускорения от увеличения кол-ва параллельных операций вы не получите т.к. p будет постоянным а (1 — 'a') будет расти. Но с ростом кол-ва потоков будет расти 'a' — это управление тредами операционной системой, что автор и получил.
Вы уперлись в закон Амдала.)
Вообще когда вы параллелите операции ввода-вывода, http запрос например, то получаете ускорение за счет того что процессор переключает своей выпонение на полезную нагрузку, во время ожидания ответа от переферии. Когда вы выполняете алгоритм состоящий из последовательных операций на процессоре, то вы упираете в закон Амдала. Эти два вида операций имеют сильно разный прирост от параллелизма.
Отличная статья. Пролог действительно интересен. Как кто то уже выше писал — проблема в том что не все типы запросов можно выполнить за разумное время. Вероятно с ростом мощности желена и новыми алгоритмами мы получим большие возможности для декларативных языков в том числе и Prolog — ведь один уже смог взойти на пьедестал, это SQL.)
p.s.
Сам буквально недавно думал над возможностью применить систему работающую с Datalog, искал решения.
Либертарианцы — сторонники диктатуры!) Вот это уровень статьи…
Мне ещё рассказывали что бывают — ночные дни и сухие реки.)
Исходя из этого пункта не понятно зачем нужно, т.к. есть много более популярных языков.
Если вам скучно можете найти в языке ещё одно специальное решение для особого случая, что бы ваши коллеги/наследники, подольше разбиралить. А что вы хотели программирование — это не просто, знали куда шли.)
Описали почти любой ЯП общего назначения.
На теплых полках с монографиями их изобретателей.)
А вы много продали? Можете привести примеры удачных продуктов которые продали?)
Или пока вы только так думаете — что продать легко, не то что кода написать или генерировать идеи.
p.s.
Так вот раскрою вам секрет написание софта — если у вас не какой то крайне инновационный алгоритм, то это уже решенная задача, с огромным множеством примеров как сделать тут или иную функцию.
А продажи это то где вы не сможете открыть мануал и получить из него все ответы. Вам придется использовать свой личный опыт и интуицию. И никто вам никогда точно не сможет описать алгоритм продаж — потом что его нет. Во вторых если есть какой то более менее понятный подход по продажам того или иного вида продукта, с вами этим никто в мануале не поделиться потом что это ключевая коммерческая тайна.
Развитие функций продукта тоже на напрямую связано с продажами, потому что должны быть тем что нужно людям и что они готовы купить, а не то что вы считаете — интересным.)
Написать новый google намного проще чем его продать — т.е. найти клиентов которые готовы им пользоваться. Тому подтверждение, неудачные попытоки множества компаний сделать это — microsoft не смог и бесчисленное кол-во других компаний тоже.
Самое сложное, как ни странно на первый взгляд это — продать.)
Борьба с терроризмом через террор, как всегда по Оруэллу.)))
Тут выбор простой. Или платный сервис или реклама, пора давно понять.)
Не стоит винить компании в желании максимизировать прибыль через сбор данных, у меня в первую очередь вопрос к пользователям которые не хотять ни платить ни делиться данными.
Безопасность — через дыру, далее по списку мир — это война, свобода — это рабство...))
Типичная проблема роста и развития отрасли.
Хотя IT это и не стройка но пример будет думаю актуальным.
На стройке серьезных объектов работают разные по своим способностям люди, а разрыв между разнорабочим и главным инженером оценить сложно. Все это связано с разделением труда и тем фактом что для разных работ необходим разный уровень квалификации.
Точно такая же ситуация в IT, для разных задач и проектов нужна разная квалификация. Сегодня средства разработки позволяют писать код проще без наличия глубинных знаний.
Катится на дно к сожалению. Особенно мобильный браузер, уже несколько обновлений UI, с мягко говоря сомнительными изменениями интерфейса, при это баги фиксятся слабо, а актуальный функционал не добавляется.
Если выразиться емко — scala геморройный язык.
Собственно это мой практический опыт, хотя изначально у меня были большие ожидания. Но работа на проектах со Scala за год, все поставило на места. Процесс разработки перерастает в борьбу с типами.
Получается что каких то реальных плюсов язык не дает — кол-во ошибок не меньше, скорость разработки не увеличилась, зато сильно усложняет код за счет множества сложных связей между типами.
Думаю это основная причина почему его перестали использовать.