Обычно всё-таки в код заходят не поглазеть что он делает, а исправить конкретную проблему. И если это действительно конкретная проблема и код хорошо структурирован, вы можете не разбираться в нём от и до, а найти конкретную ветку, исправить конкретный частный случай, запустить тесты чтобы убедиться что вы ничего не сломали и закрыть задачу
А вот если у вас весь текст одной простыней, то так не получится, надо будет разбираться во всех ветках и всех случаях, пока вы наконец не найдёте свой
Я согласен, что пример может быть не очень удачный, но удачный пример тут составить трудно, потому что он должен быть большим и сложным, и читатель просто запутается (ведь проблема плохого кода именно в том, что в нём легко запутаться)
Если я ношу в сумке полотенце - я ношу лишний груз. Если я пришел на пляж и там нет полотенец - мне нечем будет вытереться. Но если я принёс на пляж, где нет полотенец, полотенце в сумке - все будет хорошо
Сочетание двух зависимых событий - это не их простая сумма, а новое третье событие. Это знание уровня здравого смысла, а не какая-то сложная математическая теория
Про вред автокомплишена может поверить только тот, кто никогда автокомплишеном не пользовался или наоборот пользовался им всегда. Любой человек, у которого его сначала не было, а потом он появился, моментально почувствовал, насколько он повышает продуктивность. Ну если конечно вы не 10 функций используете, тогда конечно вы все их по именам помните, вопросов нет
Как можно честно оцифровать скорость разработки? Мы понятия не имеем, когда в следующий раз понадобится менять вот этот конкретный кусок кода. Может быть завтра, а может быть никогда. Это не от нас зависит зачастую. Не говоря уж о том, что мы не знаем, как его надо будет менять, может весь этот красивый рефакторинг придётся выкинуть и переписать очень сильно под новые требования. Мы же не идею "надо рефакторить код" продаём, а рефакторинг вот этого конкретного места
Все эти чистые коды и правильные дизайны, не в упрёк им - это просто эмпирическая идея, что вот так код писать обычно хорошо, а вот так - обычно плохо. Но насколько хорошо, а насколько плохо - это всё на малых масштабах крайне непредсказуемо всегда
Все эти цифры про проценты, частоту инцидентов и прочие понятные метрики в случае техдолга обычно берутся с потолка. И получается, что мы не продаем задачи, а впариваем, обещая какие-то бедствия, в которых сами точно не уверены. Далеко не все инженеры готовы таким заниматься, это всё-таки отдельный скилл больше для людей с гуманитарным складом ума
Описанные оптимизации могут превратить чтение 15 миллионов строк в 8 тысяч только в одном случае - если из 15 миллионов заказов имеют статус Completed всего 8 тысяч. Это мягко говоря странная структура данных, обычно не характерная для реальной production-системы
Всё, что угодно, надо использовать только там, где оно действительно необходимо, а не везде где попало. Вы так можете написать целый цикл статей или даже книгу - Используйте циклы только там, где они действительно необходимы - Используйте протокол HTTP только там, где он действительно необходим - Используйте микросервисы только там, где они действительно необходимы и так далее
Проблема обычно не в том, чтобы такое общее утверждение выдать, а в том, чтобы понимать, когда оно действительно необходимо, а когда нет
PS. Ловить неспецифичный exception в контроллерах - тупейшее занятие. Для этого придумали миддлвары. В этом проблема кода "было", а не в том, что в программе внутри exception выбрасывались
Но философия - не наука, и философское рассуждение не строится научными методами. Именно поэтому она и может как-то заниматься трансцедентным. Как только мы пытаемся сделать вид, что философия - наука, трансцедентное тут же исчезает и начинается жёсткий позитивизм - о том, о чём невозможно говорить, следует молчать, да и всё :)
Трансцендентное невозможно "изучать" в том смысле, который обычно вкладывают в это слово. По определению. Для этого нет ни приборов, ни инструментов, ни в конце концов подходящих слов чтобы описать результаты изучения. Это предмет исключительно личного опыта
Кто читает этот текст - очевидно, сознание человека, воспринимаемое как личность.Вы не можете исследовать ничью чужую личность непосредственно, только косвенными способами.Поэтому исследовать ответ на этот вопрос можно только на себе самом. Поэтому это исследование не может быть научными - любые результаты непроверяемы, вы исследовали свою личность, я исследовал свою, у нас получились разные результаты - это кто-то из нас ошибся или у нас разные личности? Неизвестно, и всегда будет неизвестно
Вопрос же "что такое сознание" исследовать можно, потому что тут личности нет, когда говорят о сознании - подразумевают некие феномены, которые объективному исследованию поддаются хотя бы чисто статистически
Поэтому вокруг второго вопроса более-менее существует какая-то наука, пусть довольно убогая пока. А вокруг второго существует масса спекуляций, и в этом ничего страшного, пока этим спекуляциям не пытаются придать наукообразную форму
Вопрос "что такое сознание" и "кто читает этот текст" - это один и тот же вопрос , точнее второй вопрос это частный случай первого, обращённый внутрь себя (потому что ответить на него за другого человека вы заведомо не можете). Просто первый вопрос научный, и отсутствие ответа на него очевидно. А второй - нет, потому что научными методами найти на него ответ невозможно, и поэтому вокруг него можно накрутить 100 слоев пустых слов и сделать вид, что так и надо
Я в 2000 году устраивался в компанию, ориентированную на работу на американском рынке
Вместо собеседования было тестовое задание, нацеленное на проверку определённой СУБД. Мой опыт работы с этой СУБД был на тот момент полгода, причём не с той версией, на которой надо было делать тестовое задание. Я это испытание блестяще прошёл, потому что оно было элементарным, любой нынешний выпускник курсов его пройдёт
На ту работу, на которой я работал до этого, меня взяли вообще с нулём знаний по объявлению, соответственно (отсюда и полгода опыта работы с СУБД). Правда, был опыт работы с другим стеком, но абсолютно непроверяемый, я мог его просто выдумать
Не надо тут сказки рассказывать про собеседования 20 лет назад в IT как на космонавтов. Тогда реально программистов было мало, и человеку без опыта было устроиться легко, точно легче, чем сейчас. Правда зарплаты конечно тоже были соответствующие :)
Ну так и раньше у специй себестоимость была копейки, а продавали их по цене золота, и зарабатывали на этом больше всех купцы, которые их везли. Чем глобальнее торговля, тем выше в конечной стоимости доля транспортировки и хранения
Да уже сейчас 95% кода, который реально выполняется, написано не людьми, а компиляторами. И если мы его увидим - мы даже не поймём, что там написано. Мы даём инструкцию верхнего уровня, а в исполняемый код его превращает программа, безо всякой эвристики и обучения
Так что действительно принципиально ничего не изменится, мы просто добавим ещё один уровень абстракции в переводе от человеческого языка к машинному. И программировать смогут те, кто сейчас этого не могут (как сейчас могут программировать те, у кого в 80-е годы научиться писать что-то внятное на ассемблере не хватило бы не столько ума, сколько терпения). Но по-прежнему и близко не 100%, потому что огромное количество людей внятно сформулировать более-менее сложную мысль на человеческом языке-то не в состоянии, клещами из них надо вытаскивать, что они имеют в виду
Если вы будете писать для каждой задачи в разных парадигмах, у вас получится каша, которую потом будет невозможно потом поддерживать. Да и написано будет плохо, потому что если вы постоянно в разных парадигмах будете писать, вы или гений программирования, или вы ни одну как следует чувствовать не будете, чтобы на уровне автоматизма хорошее решение выбирать. Если конечно "задача" - это не система уровня энтерпрайз на человеко-десятилетия работы. Но зачем вам тогда самому писать на чём попало, у вас будет команда со специализацией, кто-то будет писать с классами, а кто-то без :)
Практически любой язык имеет какую-то свою парадигму, и практически всегда он элементы других парадигм тоже в себя включает, потому что если бы была одна самая лучшая на свете парадигма - уже все языки бы в ней были сделаны и других бы парадигм не было нужно, конец истории бы наступил
Выберите что вам нравится и пишите на этом. Но не пытайтесь доказать, что вам выбор самый правильный и самый лучший, вы никому ничего не докажете. По крайней мере, пока не будет у вас авторитета уровня Страуструпа - да даже и тогда все с вами точно не согласятся, найдутся задачи, области и направления, где ваш любимый самый лучший язык никуда не годится, скорее всего :)
Да я в курсе. Тот комментарий был призывом к автору подумать, что наверное даже исходя из его предпосылок были какие-то причины придумать ООП изначально, и возможно эти причины никуда не делись
Может, чего надумает и более серьёзное сравнение сделает, а не на уровне "да в ФП есть полиморфизм, смотрите как красиво и понятно" и дальше отвратительная борода, проблемы которой прекрасно известны уже лет 50 как минимум
Если ФП и ПП это одно и то же (что довольно спорно), то получается ФП появилось раньше ООП. И раз ООП всё-таки придумали - значит, были в ФП какие-то проблемы, которые требовали новых подходов. То, что вы этих проблем не видите - ну может быть это в вас дело, а не в отсутствии проблем
Если у вас точка в ТЦ приносит в день выручки 20 тысяч - это точно что-то не так либо с вами, либо с ТЦ. В любом случае прекратите мучаться и не занимайте площадь, пусть там кто-то другой торгует
Применительно к настольным играм это значит, что вы продаете где-то 5-8 игр в день. При графике в 10-12 часов - это одну в 2-3 часа. Это не бизнес
Обычно всё-таки в код заходят не поглазеть что он делает, а исправить конкретную проблему. И если это действительно конкретная проблема и код хорошо структурирован, вы можете не разбираться в нём от и до, а найти конкретную ветку, исправить конкретный частный случай, запустить тесты чтобы убедиться что вы ничего не сломали и закрыть задачу
А вот если у вас весь текст одной простыней, то так не получится, надо будет разбираться во всех ветках и всех случаях, пока вы наконец не найдёте свой
Я согласен, что пример может быть не очень удачный, но удачный пример тут составить трудно, потому что он должен быть большим и сложным, и читатель просто запутается (ведь проблема плохого кода именно в том, что в нём легко запутаться)
А в чём заключается парадокс?
Если я ношу в сумке полотенце - я ношу лишний груз. Если я пришел на пляж и там нет полотенец - мне нечем будет вытереться. Но если я принёс на пляж, где нет полотенец, полотенце в сумке - все будет хорошо
Сочетание двух зависимых событий - это не их простая сумма, а новое третье событие. Это знание уровня здравого смысла, а не какая-то сложная математическая теория
Про вред автокомплишена может поверить только тот, кто никогда автокомплишеном не пользовался или наоборот пользовался им всегда. Любой человек, у которого его сначала не было, а потом он появился, моментально почувствовал, насколько он повышает продуктивность. Ну если конечно вы не 10 функций используете, тогда конечно вы все их по именам помните, вопросов нет
Как можно честно оцифровать скорость разработки? Мы понятия не имеем, когда в следующий раз понадобится менять вот этот конкретный кусок кода. Может быть завтра, а может быть никогда. Это не от нас зависит зачастую. Не говоря уж о том, что мы не знаем, как его надо будет менять, может весь этот красивый рефакторинг придётся выкинуть и переписать очень сильно под новые требования. Мы же не идею "надо рефакторить код" продаём, а рефакторинг вот этого конкретного места
Все эти чистые коды и правильные дизайны, не в упрёк им - это просто эмпирическая идея, что вот так код писать обычно хорошо, а вот так - обычно плохо. Но насколько хорошо, а насколько плохо - это всё на малых масштабах крайне непредсказуемо всегда
Все эти цифры про проценты, частоту инцидентов и прочие понятные метрики в случае техдолга обычно берутся с потолка. И получается, что мы не продаем задачи, а впариваем, обещая какие-то бедствия, в которых сами точно не уверены. Далеко не все инженеры готовы таким заниматься, это всё-таки отдельный скилл больше для людей с гуманитарным складом ума
Описанные оптимизации могут превратить чтение 15 миллионов строк в 8 тысяч только в одном случае - если из 15 миллионов заказов имеют статус Completed всего 8 тысяч. Это мягко говоря странная структура данных, обычно не характерная для реальной production-системы
Всё, что угодно, надо использовать только там, где оно действительно необходимо, а не везде где попало. Вы так можете написать целый цикл статей или даже книгу
- Используйте циклы только там, где они действительно необходимы
- Используйте протокол HTTP только там, где он действительно необходим
- Используйте микросервисы только там, где они действительно необходимы
и так далее
Проблема обычно не в том, чтобы такое общее утверждение выдать, а в том, чтобы понимать, когда оно действительно необходимо, а когда нет
PS. Ловить неспецифичный exception в контроллерах - тупейшее занятие. Для этого придумали миддлвары. В этом проблема кода "было", а не в том, что в программе внутри exception выбрасывались
Но философия - не наука, и философское рассуждение не строится научными методами. Именно поэтому она и может как-то заниматься трансцедентным. Как только мы пытаемся сделать вид, что философия - наука, трансцедентное тут же исчезает и начинается жёсткий позитивизм - о том, о чём невозможно говорить, следует молчать, да и всё :)
Трансцендентное невозможно "изучать" в том смысле, который обычно вкладывают в это слово. По определению. Для этого нет ни приборов, ни инструментов, ни в конце концов подходящих слов чтобы описать результаты изучения. Это предмет исключительно личного опыта
Ну смотрите.
Кто читает этот текст - очевидно, сознание человека, воспринимаемое как личность.Вы не можете исследовать ничью чужую личность непосредственно, только косвенными способами.Поэтому исследовать ответ на этот вопрос можно только на себе самом. Поэтому это исследование не может быть научными - любые результаты непроверяемы, вы исследовали свою личность, я исследовал свою, у нас получились разные результаты - это кто-то из нас ошибся или у нас разные личности? Неизвестно, и всегда будет неизвестно
Вопрос же "что такое сознание" исследовать можно, потому что тут личности нет, когда говорят о сознании - подразумевают некие феномены, которые объективному исследованию поддаются хотя бы чисто статистически
Поэтому вокруг второго вопроса более-менее существует какая-то наука, пусть довольно убогая пока. А вокруг второго существует масса спекуляций, и в этом ничего страшного, пока этим спекуляциям не пытаются придать наукообразную форму
Вопрос "что такое сознание" и "кто читает этот текст" - это один и тот же вопрос , точнее второй вопрос это частный случай первого, обращённый внутрь себя (потому что ответить на него за другого человека вы заведомо не можете). Просто первый вопрос научный, и отсутствие ответа на него очевидно. А второй - нет, потому что научными методами найти на него ответ невозможно, и поэтому вокруг него можно накрутить 100 слоев пустых слов и сделать вид, что так и надо
Потому что статьи на английском читает множество не носителей английского языка. С русским языком такой проблемы нет
Там, где нашествие не носителей не ожидается или никого не волнует, пишут на таком английском, что мама не горюй, со словарём будете сидеть читать
Я в 2000 году устраивался в компанию, ориентированную на работу на американском рынке
Вместо собеседования было тестовое задание, нацеленное на проверку определённой СУБД. Мой опыт работы с этой СУБД был на тот момент полгода, причём не с той версией, на которой надо было делать тестовое задание. Я это испытание блестяще прошёл, потому что оно было элементарным, любой нынешний выпускник курсов его пройдёт
На ту работу, на которой я работал до этого, меня взяли вообще с нулём знаний по объявлению, соответственно (отсюда и полгода опыта работы с СУБД). Правда, был опыт работы с другим стеком, но абсолютно непроверяемый, я мог его просто выдумать
Не надо тут сказки рассказывать про собеседования 20 лет назад в IT как на космонавтов. Тогда реально программистов было мало, и человеку без опыта было устроиться легко, точно легче, чем сейчас. Правда зарплаты конечно тоже были соответствующие :)
Ну так и раньше у специй себестоимость была копейки, а продавали их по цене золота, и зарабатывали на этом больше всех купцы, которые их везли. Чем глобальнее торговля, тем выше в конечной стоимости доля транспортировки и хранения
Да уже сейчас 95% кода, который реально выполняется, написано не людьми, а компиляторами. И если мы его увидим - мы даже не поймём, что там написано. Мы даём инструкцию верхнего уровня, а в исполняемый код его превращает программа, безо всякой эвристики и обучения
Так что действительно принципиально ничего не изменится, мы просто добавим ещё один уровень абстракции в переводе от человеческого языка к машинному. И программировать смогут те, кто сейчас этого не могут (как сейчас могут программировать те, у кого в 80-е годы научиться писать что-то внятное на ассемблере не хватило бы не столько ума, сколько терпения). Но по-прежнему и близко не 100%, потому что огромное количество людей внятно сформулировать более-менее сложную мысль на человеческом языке-то не в состоянии, клещами из них надо вытаскивать, что они имеют в виду
Если вы будете писать для каждой задачи в разных парадигмах, у вас получится каша, которую потом будет невозможно потом поддерживать. Да и написано будет плохо, потому что если вы постоянно в разных парадигмах будете писать, вы или гений программирования, или вы ни одну как следует чувствовать не будете, чтобы на уровне автоматизма хорошее решение выбирать. Если конечно "задача" - это не система уровня энтерпрайз на человеко-десятилетия работы. Но зачем вам тогда самому писать на чём попало, у вас будет команда со специализацией, кто-то будет писать с классами, а кто-то без :)
Практически любой язык имеет какую-то свою парадигму, и практически всегда он элементы других парадигм тоже в себя включает, потому что если бы была одна самая лучшая на свете парадигма - уже все языки бы в ней были сделаны и других бы парадигм не было нужно, конец истории бы наступил
Выберите что вам нравится и пишите на этом. Но не пытайтесь доказать, что вам выбор самый правильный и самый лучший, вы никому ничего не докажете. По крайней мере, пока не будет у вас авторитета уровня Страуструпа - да даже и тогда все с вами точно не согласятся, найдутся задачи, области и направления, где ваш любимый самый лучший язык никуда не годится, скорее всего :)
Да я в курсе. Тот комментарий был призывом к автору подумать, что наверное даже исходя из его предпосылок были какие-то причины придумать ООП изначально, и возможно эти причины никуда не делись
Может, чего надумает и более серьёзное сравнение сделает, а не на уровне "да в ФП есть полиморфизм, смотрите как красиво и понятно" и дальше отвратительная борода, проблемы которой прекрасно известны уже лет 50 как минимум
Если ФП и ПП это одно и то же (что довольно спорно), то получается ФП появилось раньше ООП. И раз ООП всё-таки придумали - значит, были в ФП какие-то проблемы, которые требовали новых подходов. То, что вы этих проблем не видите - ну может быть это в вас дело, а не в отсутствии проблем
Если у вас точка в ТЦ приносит в день выручки 20 тысяч - это точно что-то не так либо с вами, либо с ТЦ. В любом случае прекратите мучаться и не занимайте площадь, пусть там кто-то другой торгует
Применительно к настольным играм это значит, что вы продаете где-то 5-8 игр в день. При графике в 10-12 часов - это одну в 2-3 часа. Это не бизнес
Держать 4 сотрудников при выручке 20 тысяч в день это не бизнес, а благотворительность какая-то