А зачем бороться с тем, что Go ругают? Многим не нравятся языки, которые вводят искусственные ограничения. И это вполне нормально, особенно с учётом того, что есть отличные альтернативы, например: Elixir и Nim.
пока сумма налога не превысила сумму взносов — всех-всех налогов по 4 тысячи в квартал (на УСН 6 %)
А откуда взялась цифра 4 тыс. в квартал? Минимальные страховые взносы в этом году чуть больше 23 тыс. рублей, ну или 5788 за квартал. Или это о чём-то другом?
Любопытнее, что 72% (а особенно первые 16%) велосипедят для разработки несложных проектов. Готовые движки вполне позволяют подстраивание под конкретный проект. Они для этого и написаны и в их разработку вложены тысячи человеко-часов. И тут Вы либо собираете команду и вкладываете эти тысячи часов (что недопустимо для несложных проектов), либо кое-как кодите на коленке нечто одному Вам понятное…
Строго говоря, для набора текста вероятности гораздо сложнее… в частности, обезьяна вероятнее будет лупить некоторое время в одну область клавиатуры, а не распределять нажатия равномерно по всей её поверхности. Так что задачу надо про роботов формулировать, а не про обезьян, чтобы удобнее считать было.
Тут можно ещё добавить, что без понимания происходящего программист скатывается на метод «научного тыка». Начиная с олд-скульного +1, -1 к счётчику циклов и до наиболее популярного сейчас увидел ошибку, погуглил, попробовал применить то, что нагуглил, если помогло — обрадовался и забыл про эту ошибку. В какой-то степени такой подход тоже работает, но строго говоря является полной противоположностью программированию. К тому же, Вы не можете быть уверены, что найденное решение полностью исправляет ошибку и не имеет побочных эффектов, до тех пор пока не поняли первопричину ошибки.
Кстати, метод «научного тыка» красочно описан в статье:
Первые 2 флага нужны потому, что я тупо не в курсе, какой из них реально отключает web-security(скорее всего, все-таки первый).
а 4 — для игнорирования левых сертификатов(вот он, вроде как, не нужен, пытался исправить баг, связанный с тем, что провтыкал другой баг). Собственно, 2 и 4 переключатели можно и удалить.
Справедливости ради, все мы иногда применяем метод «научного тыка», главное осознавать что в такие моменты мы бесконечно далеки от программирования :-)
К сожалению, в этой шутке доля правды зашкаливает )))
Ну и я не говорю, что jQuery плох сам по себе. Но то, что он, как и любой другой слой абстракции, ведёт к деградации среднего уровня JS-программистов — это, в принципе, факт. Хотя в этом нет ничего катастрофичного, C++ — это тоже в каком-то смысле деградация по сравнению с ассемблером, ну или любой ORM — это деградация по сравнению с SQL :-D
Искусство в том, чтобы соблюдать баланс между скоростью разработки и пониманием что происходит под завесой абстракций. И тем самым осознавать границы применимости конкретной абстракции.
На тему деградации при помощи jQuery, Вы видимо не в курсе мема
Not enough jQuery
В принципе, любая абстракция призвана снижать порог входа, и любая абстракция протекает. Но не всем пользователям абстракций охота разбираться с более низкими уровнями абстракций. Как следствие, появляется определённый процент людей, которые что-то делают при помощи высокоуровневых абстракций, но не понимают как оно вообще работает.
В том то и парадокс… получается, что производительность ПО падает быстрее, чем растёт вычислительная мощность.
По идее уже пора начинать новый виток развития отрасли с упором на производительность.
Тут скорее дело привычки, по сути и XAML и HTML — диалекты XML для разметки. Только на HTML Вы сразу знаете как какую-то задачу выполнить, а на XAML — надо сначала в документацию заглянуть.
IDEA на Java, она тоже жрёт дохрена, когда я её года 3-4 назад (в варианте Redmine) пробовал на своих проектах, она вообще тупо висла и даже тюнинг настроек JVM не особо помогал. Но это хотя бы IDE, а Atom по задумке должен быть легковесным редактором, если я ничего не путаю. Поэтому и потребление памяти у него должно быть на порядок меньше.
Я лично не могу сказать, может ли он обогнать IDEA по расходу ОЗУ. Но это как-то странно выбирать из двух прожорливых самого прожорливого. Я помню ещё времена Delphi 7 и Visual Studio 2005 и как-то ж блин всё отлично работало на компе с 768 Mb ОЗУ, прям летало )))
А вообще, накакокодить можно на любом языке, было бы желание.
Безусловно, но бэкенд уже по-моему у всех под постоянным мониторингом, даже на staging, поэтому там это редко доходит до production. Ну а если доходит, то сразу алерты приходят. На фронте же отслеживать производительность — пока редкость.
Если говорить про разработку классических desktop-приложений, то для них подразумевается QA-отдел, который в том числе проверяет, чтобы ничего не тормозило на всех target-платформах(версиях ОС и т.д.).
Т.е. можно снять часть ответственности с программистов на JS, сказав, что проблема в незрелости JS-платформы, но с другой стороны кто если не они, должен осознать необходимость использовать инструменты и способы контроля, которые в других областях уже используются по умолчанию.
Другими словами, надо уже осознать, что JS из языка для простеньких скриптиков превратился в язык для написания фронтенд-приложений и относится к разработке на нём так же серьёзно, как к разработке на языках, используемых для server-side и desktop.
само приложение отъедает ее только если есть какие-либо ресурсозатратные процессы, либо руки из жопы растут
ну так, бессмысленная и беспощадная растрата ресурсов — это не такая уж редкость в JS-мире… или вам не попадались сайты, которые из-за какой-нибудь тупой анимации отжирали на 100% целое ядро процессора, или простейшие странички, которые из-за какого-то текущего скрипта фоном отжирали память?
Так что не мог совсем не упомянуть, всё-таки поразительно много людей программируют на JS не задумываясь ни про ОЗУ, ни про CPU. Хотя само собой, это относится не ко всем JS-программистам. Так что, если Вы пользуетесь упомянутым отладчиком CPU/памяти или хоть как-то задумываетесь над ресурсоёмкостью написанного кода, то извините за обобщение ;-)
А пока из консоли браузера выполните
дабы не видеть это безобразие xD
Кстати, метод «научного тыка» красочно описан в статье:
Справедливости ради, все мы иногда применяем метод «научного тыка», главное осознавать что в такие моменты мы бесконечно далеки от программирования :-)
Ну и я не говорю, что jQuery плох сам по себе. Но то, что он, как и любой другой слой абстракции, ведёт к деградации среднего уровня JS-программистов — это, в принципе, факт. Хотя в этом нет ничего катастрофичного, C++ — это тоже в каком-то смысле деградация по сравнению с ассемблером, ну или любой ORM — это деградация по сравнению с SQL :-D
Искусство в том, чтобы соблюдать баланс между скоростью разработки и пониманием что происходит под завесой абстракций. И тем самым осознавать границы применимости конкретной абстракции.
В принципе, любая абстракция призвана снижать порог входа, и любая абстракция протекает. Но не всем пользователям абстракций охота разбираться с более низкими уровнями абстракций. Как следствие, появляется определённый процент людей, которые что-то делают при помощи высокоуровневых абстракций, но не понимают как оно вообще работает.
По идее уже пора начинать новый виток развития отрасли с упором на производительность.
Я лично не могу сказать, может ли он обогнать IDEA по расходу ОЗУ. Но это как-то странно выбирать из двух прожорливых самого прожорливого. Я помню ещё времена Delphi 7 и Visual Studio 2005 и как-то ж блин всё отлично работало на компе с 768 Mb ОЗУ, прям летало )))
Но в целом да, поскромнее атома.
Если говорить про разработку классических desktop-приложений, то для них подразумевается QA-отдел, который в том числе проверяет, чтобы ничего не тормозило на всех target-платформах(версиях ОС и т.д.).
Т.е. можно снять часть ответственности с программистов на JS, сказав, что проблема в незрелости JS-платформы, но с другой стороны кто если не они, должен осознать необходимость использовать инструменты и способы контроля, которые в других областях уже используются по умолчанию.
Другими словами, надо уже осознать, что JS из языка для простеньких скриптиков превратился в язык для написания фронтенд-приложений и относится к разработке на нём так же серьёзно, как к разработке на языках, используемых для server-side и desktop.
Так что не мог совсем не упомянуть, всё-таки поразительно много людей программируют на JS не задумываясь ни про ОЗУ, ни про CPU. Хотя само собой, это относится не ко всем JS-программистам. Так что, если Вы пользуетесь упомянутым отладчиком CPU/памяти или хоть как-то задумываетесь над ресурсоёмкостью написанного кода, то извините за обобщение ;-)